Minősített elektronikus aláírás - információs rendszerek OID-jeinek problémái. Rossz aláírás Az aláírás ellenőrzése sikertelen Hiányzó objektumazonosító OID Oid visszafejtés

Amikor belép személyes fiókjába QEP kéréséhez, megjelenik egy üzenet « A számítógép nincs konfigurálva . A folytatáshoz lépjen a számítógép beállítási oldalára, és kövesse a javasolt lépéseket » . Miután felkereste a beállításokat, és telepítette az összes szükséges összetevőt személyes fiók megjelenik az üzenet, hogy a számítógép nincs újra konfigurálva.

A hiba kijavításához a következőket kell tennie:

1. Adja hozzá személyes fiókja címét https://i.kontur-ca.ru a megbízható csomópontokhoz. Ezért:

Válassza a "Start" > "Vezérlőpult" > "Internetbeállítások" menüt;
Lépjen a "Biztonság" fülre, válassza ki a "Megbízható helyek" (vagy "Megbízható helyek") elemet, és kattintson a "Csomópontok" gombra;
Adja meg a következő csomópontcímet: https://i.kontur-ca.ru a Hozzáadás a zónához mezőben, majd kattintson a Hozzáadás gombra.

Ha ez a cím már szerepel a megbízható webhelyek listájában, folytassa a következő lépéssel.

2. Ellenőrizze, hogy a személyes fiók címe https://i.kontur-ca.ru megbízható-e:

Ha az Internet Explorer 8-as verzióját használja, akkor az engedélyezési oldalon ellenőriznie kell, hogy a Megbízható helyek jelölőnégyzet szerepel-e az oldal alján. Ha nincs jelölőnégyzet, de van felirat « Internet”, akkor a https://i.kontur-ca.ru címet nem adták hozzá a megbízható webhelyekhez.

Ha az Internet Explorer 9-es vagy újabb verzióját használja, akkor az engedélyezési oldalon kattintson a jobb gombbal az oldal tetszőleges pontjára, és válassza a "Tulajdonságok" lehetőséget. A megnyíló ablakban a "Zóna" sornak tartalmaznia kell a "Megbízható helyek" feliratot. Ellenkező esetben a https://i.kontur-ca.ru címet nem adták hozzá a megbízható webhelyekhez.

Ha a személyes fiók címe nincs megbízhatóként definiálva, akkor lépjen kapcsolatba a rendszergazdával azzal a kéréssel, hogy adja hozzá a https://i.kontur-ca.ru címet a megbízható csomópontokhoz.

3. Ellenőrizze, hogy be tud-e jelentkezni személyes fiókjába. Ha a hiba ismétlődik, futtassa a RegOids segédprogramot a hivatkozásról. Ez a segédprogram automatikusan konfigurálja az OID-beállításokat a számítógép beállításjegyzékében. A rendszerleíró adatbázis egyik ágát manuálisan is importálhatja, a telepített operációs rendszer bitességétől függően:

4. Ellenőrizze, hogy a számítógép rendszergazdai jogokkal rendelkezik-e (az ellenőrzéshez lépjen a következő helyre: Start - Vezérlőpult - Felhasználói fiókok és családbiztonság - Felhasználói fiókok). Ha a jogosultságok nem elegendőek, teljes jogokat kell adni a felhasználónak, ehhez forduljon a rendszergazdához.

5. A 3. lépés befejezése után újra kell indítani a számítógépet, és ellenőrizni kell a Személyes fiók bejáratát.

Ha egyik utasítás sem segített, vegye fel a kapcsolatot technikai támogatás a cím szerint [e-mail védett] A levélben fel kell tüntetni:

1. Diagnózis száma.

Ehhez fel kell lépnie a diagnosztikai portálra a címenhttps://help.kontur.ru , nyomja meg a gombot " Diagnosztika indítása » . Az ellenőrzési folyamat befejezése után a diagnosztikai szám megjelenik a képernyőn. Adja meg a hozzárendelt hivatkozási számot a levélben.

2. Képernyőkép a hibát tartalmazó ablakról (az Internet Explorer 9-es és újabb verzióinak használatakor csatolnia kell a "Tulajdonságok" ablak képernyőképét is – lásd a 2. pontot).

3. Exportálja és csatolja a következő nyilvántartási ágakat:

32 bites: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64 bites: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo

Általános rendelkezések.
Az egyes adatok megjelenítési módjának és a tanúsítványmezők összetételére vonatkozó további korlátozásoknak a megválasztása a következő elveken alapul:
Nemzetközi ajánlások. Ez a dokumentum a nemzetközi ajánlások figyelembevételével készült:
- RFC 3280 (frissíti az RFC 2459-et) Internet X.509 nyilvános kulcsú infrastruktúra. Tanúsítvány és tanúsítvány visszavonási lista (CRL) profil.
- RFC 3039 Internet X.509 nyilvános kulcsú infrastruktúra. Minősített tanúsítványprofil – Ez az RFC javasolt Általános követelmények tanúsítványok szintaxisára (összetételére), amelyek használata jogilag jelentős.

A tanúsítványmezők összetétele és célja.

Ez a szakasz egy olyan nyilvános kulcsú tanúsítvány főbb mezőinek leírását tartalmazza, amelyek megfelelnek az "Elektronikus digitális aláírásról" szóló, 2002.01.10-i törvénynek.

Az ebben a részben használt fogalmak, jelölések és terminológia az RFC 3280 és az RFC 3039 szabványokon alapulnak, amelyek viszont az ITU-T X.509 ajánlás 3. verzióján alapulnak. A szakasz tartalma nem másolja ezeknek a dokumentumoknak a tartalmát , hanem csak a mezőtanúsítványok használatának különbségeit és jellemzőit jelzi, amelyek megvalósítják az EDS-törvény 6. cikkében az EDS-tanúsítvány összetételére vonatkozó követelményeket.

Minden olyan tanúsítványmező esetében, amely orosz nyelvű karakterlánc-értékeket igényel, célszerű az univerzális UTF-8 kódolást (UTF8String típus) használni.

Ennek a szakasznak az a célja, hogy meghatározza a tanúsítványmezők összetételét és célját anélkül, hogy figyelembe venné egy adott tanúsító hatóság követelményeit. A hitelesítés-szolgáltató működését szabályozó dokumentumok korlátozhatják a tanúsítványmezők összetételét, valamint a CA és a tanúsítványtulajdonosok azonosítására használt attribútumkészletet. aláírási kulcsok.

változat
Minden kiállított tanúsítvány kell 3-as verziója van.

Sorozatszám
SerialNumber mező kell tartalmaznia kell "...az aláírási kulcs tanúsítványának egyedi regisztrációs számát" (6. cikk, 1. pont, 1. bekezdés). A tanúsítvány számának egyediségét egy adott hitelesítési hatóságon (CA) belül tiszteletben kell tartani.

Érvényesség
Érvényességi mező kell tartalmazza „... a hitelesítő központ nyilvántartásában található aláírási kulcs tanúsítvány érvényességi idejének kezdetének és lejáratának dátumát” (6. cikk, 1. pont, 1. bekezdés).

SubjectPublicKeyInfo
tárgyPublicKeyInfo mezőben kell tartalmazza „...az elektronikus digitális aláírás nyilvános kulcsát” (6. cikk, 1. pont, 3. bekezdés).

Kibocsátó
Az "EDS-ről" szóló szövetségi törvény csak magánszemélyek számára feltételezi a tanúsítványok kiadását, ez a rendelkezés vonatkozik magukra a CA-k tanúsítványaira és az erőforrások tanúsítványaira is. A szövetségi törvény formai követelményeinek való megfelelés érdekében javasolt a CA és az erőforrástanúsítványok attribútumaiban feltüntetni a szervezet valós adatait, tekintettel arra, hogy az ilyen tanúsítványt a CA vagy az erőforrás felhatalmazott személye számára állítják ki, és a megadott információkat az álnév tanúsítványaként kell értelmezni és regisztrálni, amelyet az „EDS-ről” szóló szövetségi törvény lehetővé tesz.
Kibocsátó mező kell egyedileg azonosítja a tanúsítványt kiállító szervezetet, és tartalmazza a szervezet hivatalosan bejegyzett nevét.
Az azonosításhoz a következő attribútumok használhatók:

ország neve	(id-at 6)
stateOrProvinceName	(id-at 8)
helységNév	(id-at 7)
Szervezet neve	(id-at 10)
OrganizationalUnitName	(id-at 11)
postázási cím	(id-at 16)
sorozatszám	(id-at 5)

Kibocsátó mező kell feltétlenül szerepeltessen olyan attribútumokat, amelyek leírják „az aláírási kulcs tanúsítványt kiállító hitelesítés-szolgáltató nevét és helyét” (6. cikk, 1. szakasz, 5. bekezdés).

Név kell a szervezetnév attribútumban megadott. A szervezetnév attribútum használatakor talán

CA helye talán meg kell adni a countryName, stateOrProvinceName, localityName attribútumok készletével (amelyek mindegyike nem kötelező), vagy egyetlen postalAddress attribútum használatával. A fenti módszerek bármelyikével a CA helye jelen kell lennie a tanúsítványban.

kell tartalmazza a hitelesítő hatóság jogi címét. Határolóként szóközt ("0x20" karakter) kell használni.

mező attribútum tárgy serialNumber kell névütközésekben használható.

tantárgy
A tanúsítvány tulajdonosának megkülönböztetett nevének (DN-jének) képviselete lehet a következő attribútumok használatosak:

ország neve	(id-at 6)
stateOrProvinceName	(id-at 8)
helységNév	(id-at 7)
Szervezet neve	(id-at 10)
OrganizationalUnitName	(id-at 11)
cím	(id-at 12)
gyakori név	(id-at 3)
álnév	(id-at 65)
sorozatszám	(id-at 5)
postázási cím	(id-at 16)

A szövetségi törvény formai követelményeinek való megfelelés érdekében javasolt a CA és az erőforrástanúsítványok attribútumaiban feltüntetni a szervezet valós adatait, tekintettel arra, hogy az ilyen tanúsítványt a CA vagy az erőforrás felhatalmazott személye számára állítják ki, és a megadott információkat az álnév tanúsítványaként kell értelmezni és regisztrálni, amelyet az „EDS-ről” szóló szövetségi törvény lehetővé tesz.

tárgymező kell a következő adatokat kötelező feltüntetni: "az aláírási kulcs tanúsítvány tulajdonosának vezetékneve, keresztneve és családneve vagy a tulajdonos álneve" (6. cikk, 1. pont, 2. bekezdés).

A tulajdonos vezetékneve, neve és családneve kell szerepelnie kell a commonName attribútumban, és meg kell egyeznie az útlevélben megadottakkal. Határolóként szóközt ("0x20" karakter) kell használni.

Tulajdonos álnév kell az alias attribútum tartalmazza.

Ezen attribútumok egyikének használata kizárja a másik használatát.

A többi attribútum nem kötelező.

„Szükség esetén az aláírási kulcs tanúsítványa az igazoló okiratok alapján feltünteti a beosztást (a beosztást létrehozó szervezet nevével és székhelyével)...” (6. cikk 2. pont).

A tanúsítvány birtokosának címe kell a title attribútumban megadva. Attribútum értéke kell megfelel a bizonyítvány birtokosa számára megállapított pozíciót igazoló dokumentumokban szereplő bejegyzésnek.

A cím attribútuma az RFC 3039 szerint, kell szerepeljen a subjectDirectoryAttributes kiterjesztésben. Ez a dokumentum (és az RFC 3280) azonban lehetővé teszi, hogy a tárgy mezőben szerepeljen.

A title attribútum használatakor kötelező kell tartalmazzon attribútumokat, amelyek leírják annak a szervezetnek a nevét és helyét, amelyben a pozíciót létrehozták.

Cégnév kell a szervezetnév attribútumban megadott. Attribútum értéke kell egybeesik a szervezet alapító okiratában vagy más azzal egyenértékű dokumentumban szereplő nevével. A szervezetnév attribútum használatakor talán a organizationalUnitName attribútumot is használják.

A szervezet helye talán meg kell adni a countryName, stateOrProvinceName, localityName attribútumok készletével (amelyek mindegyike nem kötelező), vagy egyetlen postalAddress attribútum használatával.

a postalAddress attribútum, ha van, kell tartalmazza a szervezet jogi címét vagy az aláírási kulcs tanúsítvány tulajdonosának lakcímét (magánszemély esetében).

Ha a OrganisationName attribútum jelen van, akkor az countryName, stateOrProvinceName, localityName és postalAddress attribútumok kell a szervezet helyeként kell értelmezni.

A tárgymező opcionális attribútumai (országNév, állam vagy tartománynév, településnév, szervezetnév, szervezeti egységnév, cím, postacím) lehet szerepeljen, ha azt a CA előírásai meghatározzák, a tárgymező helyett a subjectDirectoryAttributes kiterjesztésben (lásd 3.8.1. pont). Ebben az esetben ők nem kellene szerepeljen a tárgyban és nem tud használható az aláíró kulcstanúsítványok tulajdonosainak megkülönböztetésére.

serialNumber attribútum kell névütközés esetén szerepeljen az igazolás tárgy rovatában. Ő is talán szerepel, ha azt a tanúsító központ előírásai meghatározzák.

serialNumber attribútum talán:

önkényes legyen (maga a tanúsító hatóság jelöli ki);
tartalmaznak egy állami (vagy más) szervezet által hozzárendelt azonosítót (számot) (például TIN-t, útlevél-sorozatot és -számot, személyi igazolványszámot stb.).

Szükséges bővítmények
kell tartalmazza a következő kiterjesztéseket:
- KeyUsage (id-ce 15)
- Tanúsítványszabályzat (id-ce 32)
1. KeyUsage
  Ahhoz, hogy egy tanúsítványt digitális aláírás ellenőrzésére használhasson, a keyUsage bővítményben kell a digitalSignature(0) és nonRepuduation(1) biteket be kell állítani.
  Tanúsítványpolitika
  A certificatePolicies kiterjesztés célja egy tanúsítvány jogilag releváns alkalmazási körének meghatározása.
  "... azon EDS-eszközök neve, amelyekkel ezt a nyilvános kulcsot használják..." (6. cikk, 1. pont, 4. bekezdés), "... információ arról a kapcsolatról, amelynek megvalósítása során egy elektronikus dokumentumot egy elektronikus digitális aláírás jogi jelentőséggel bír... "(6. cikk, 1. pont, (6) bekezdés) és az aláírási kulcs tanúsítványok megszerzésének és felhasználásának eljárását szabályozó egyéb adatok, lehet elérhető a jelen bővítményben meghatározott CPSuri (Certificate Practice Statement URI) címen.

Választható bővítmények
Az aláíró kulcs tanúsítványának részeként lehet tartalmazzon bármilyen más kiterjesztést. Az EDS-kulcstanúsítvány kiterjesztésének beillesztésekor biztosítani kell a tanúsítványban szereplő információk következetességét és egyértelműségét.
Ez a dokumentum nem határozza meg a tárgyDirectoryAttributes (id-ce 9) kiterjesztéstől eltérő kiterjesztések használatát.

SubjectDirectoryAttributes
tárgyDirectoryAttributes kiterjesztés talán olyan attribútumokat tartalmaznak, amelyek kiegészítik a tárgymezőben megadott információkat.
Az RFC 3039-ben felsorolt attribútumokon kívül a következő attribútumok támogatása javasolt a subjectDirectoryAttributes bővítményben:

képesítés	{-}
ország neve	(id-at 6)
stateOrProvinceName	(id-at 8)
helységNév	(id-at 7)
Szervezet neve	(id-at 10)
OrganizationalUnitName	(id-at 11)
cím	(id-at 12)
postázási cím	(id-at 16)

„Szükség esetén az aláírási kulcs tanúsítványa az igazoló dokumentumok alapján feltünteti... az aláírási kulcs tanúsítvány tulajdonosának végzettségét” (6. cikk 2. pont).

Adatok az EDS kulcstanúsítvány tulajdonosának minősítéséről kell a minősítési attribútumban meghatározott. Ez az attribútum nincs meghatározva a nemzetközi ajánlásokban (lásd a 2. szakaszt), és regisztrációhoz kötött.

Ha a countryName, stateOrProvinceName, localityName, organisationName, OrganisationalUnitName, title, postalAddress attribútumok szerepelnek a tárgyDirectoryAttributes kiterjesztésben, akkor nem kellene szerepeljen a tárgy mezőben.

Az aláírási kulcs tanúsítvány tulajdonosára vonatkozó egyéb információk tárolására lehet olyan egyéb (már regisztrált vagy regisztrációhoz kötött) attribútumokat használjon, amelyek nem mondanak ellent a CertificatePolicies kiterjesztés és a CA munkáját szabályozó egyéb dokumentumok által előírt korlátozásoknak.

ASN1 alkalmazás

id-at: OID érték: 2.5.4
OID leírás: X.500 attribútumtípusok.
id-ce: OID érték: 2.5.29
OID leírás: Objektumazonosító a 3-as verzió tanúsítványkiterjesztéseihez.

2.5.4.5 id-at-serialNumber serialNumber ATTRIBUTE::= ( SZINTAXISVAL PrintableString(SIZE (1..64)) EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID id-at-serialNumber )

(RFC 3039)
A serialNumber attribútumtípust, ha jelen van, KELL használni az olyan nevek megkülönböztetésére, ahol a tárgymező egyébként azonos lenne. Ennek az attribútumnak nincs meghatározott szemantikája azon túl, hogy biztosítja az alanynevek egyediségét. Tartalmazhat a CA által hozzárendelt számot vagy kódot, vagy egy kormány vagy polgári hatóság által hozzárendelt azonosítót. A CA felelőssége annak biztosítása, hogy a sorozatszám elegendő legyen a tárgynév-ütközések feloldásához.

2.5.4.3 - id-at-commonName

OID érték: 2.5.4.3

OID leírás: A közös név attribútumtípus egy objektum azonosítóját határozza meg. A közönséges név nem könyvtárnév; ez egy (esetleg félreérthető) név, amelyen az objektumot bizonyos korlátozott terjedelemben (például egy szervezetben) általánosan ismerik, és amely megfelel annak az országnak vagy kultúrának, amelyhez kapcsolódik.

CommonName ATTRIBUTE::= ( A név ALTÍPUSA SZINTAXISVAL DirectoryString (ub-common-name) ID (id-at-commonName) )

(RFC 3039: Minősített tanúsítvány profil)
OID érték: 2.5.4.65

álnév ATTRIBUTE::= ( A név ALTÍPUSA SZINTAXISVAL DirectoryString ID (id-at-pszeudonim) )

OID érték: 2.5.29.17

OID leírás: id-ce-subjectAltName Ez a kiterjesztés egy vagy több alternatív nevet tartalmaz a különböző névformák bármelyikét használva a hitelesítésszolgáltató által a hitelesített nyilvános kulcshoz kötött entitáshoz.

SubjectAltName EXTENSION::= ( SZINTAXIS Az id-ce-subjectAltName ÁLTAL AZONOSÍTOTT általános nevek ) GeneralNames::= AZ GeneralName általános neve SEKVENCEMÉRETE (1..MAX) *) x400Address ORAddress, directoryName Név, ediPartyName EDIPartyName, uniformResourceIdentifier IA5String, IPAddress OCTET STRING, registerID OBJECT IDENTIFIER ) (*) – tetszőleges karakterlánc. EGYÉB-NÉV::= SEQUENCE (típusazonosító OBJEKTAZONOSÍTÓ érték, KIFEJEZZE BÁRMELYET, amelyet típusazonosító definiál)

OID érték: 2.5.4.16

OID leírás: A Postacím attribútumtípus a postai üzenetek postai hatóság által a megnevezett objektumhoz történő fizikai kézbesítéséhez szükséges címinformációkat adja meg. A Postacím attribútumértéke jellemzően a CCITT Rec F.401 szerinti MHS formázatlan postai kiküldési cím 1. verziójának kiválasztott attribútumaiból áll, és legfeljebb 6 sor, egyenként 30 karakter hosszú, beleértve a postai ország nevét is. Általában az ilyen címekben található információ tartalmazhatja a címzett nevét, utcacímét, városát, államát vagy tartományát, irányítószámát és esetleg egy postafiók számát, a megnevezett objektum speciális követelményeitől függően.

Postacím ATTRIBUTE::= ( SZINTAXISVAL PostalAddress EQUALITY MATCHING RULE caseIgnoreListMatch SUBSTRINGS MATCHING RULE caseIgnoreListSubstringsMatch ID id-at-postalAddress ) Postacím::= SEQUENCE SIZE (1.ub)-postal-Stragia

OID érték: 2.5.4.12

OID leírás: A Title attribútumtípus az objektum kijelölt pozícióját vagy funkcióját határozza meg a szervezeten belül. A Title attribútum értéke string.

Title ATTRIBUTE::= ( A név ALTÍPUSA SZINTAXISVAL DirectoryString (ub-title) ID id-at-title ) id-ce-certificatePolicies OBJECT IDENTIFIER::= ( id-ce 32 ) certificatePolicies::= SEKVENCIA MÉRETE (1. MAX) OF PolicyInformation PolicyInformation::= SEQUENCE ( policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPCIONÁLIS ) CertPolicyId::= AiffiualINYD OBJECT IDENTIFIER (policyQualINYD) PolicyQualiQierQualiQierpolicyQualifierInfo::d az internetes irányelvek minősítőihez id-qt OBJECT DENTIFIER::= ( id-pkix 2 ) id-qt-cps OBJECT IDENTIFIER::= ( id-qt 1 ) id-qt-unotice OBJECT IDENTIFIER::= ( id-qt 2 ) PolicyQualifierId::= OBJECT AZONOSÍTÓ (id-qt-cps | id-qt-unotice) Minősítő::= VÁLASZTÁS ( cPSuri CPSuri, userNotice UserNotice ) CPSuri::= IA5String UserNotice::= SEQUENCE ( noticeReficeT NoticeALOPTIONTEXplicitt. NoticeReference::= SEQUENCE ( organi zation DisplayText, noticeNumbers EGÉSZ SZÁM SEQUENCE ) DisplayText::= VÁLASZTÁS ( láthatóString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) )

Vadim Malykh
02.10.2013

Nemrég a Facebook Forum Rus csoportjában vita volt a használatáról információs rendszerek ah hatóságok (a vita nem volt témában, ezt a lenti megjegyzésekben láthatjátok). A vita lényege, hogy az információs rendszerek OID-jei (objektumazonosító - objektumazonosító) miatt, amelyeket a tisztviselők minősített elektronikus aláírási tanúsítványaiban (ES) kell regisztrálni, ugyanazokat az ES-eket még gyakrabban kell megváltoztatni, mint egy alkalommal. évre (amit a biztonsági követelmények szabnak meg), és ez további bonyolultságokhoz és költségekhez vezet, mivel a legtöbb hatóság úgy dolgozik együtt kereskedelmi hitelesítésszolgáltatókkal, hogy nincs sajátjuk. A problémát súlyosbítja, hogy nincs közös értelmezés arról, hogy mik is pontosan ezek. Az OID-k megadják, és mennyire szükségesek és/vagy kötelezőek.

A vita során ellenfelem figyelmeztetett, hogy a témakör egyes alapjainak ismeretének hiánya miatt a jövőben bizonyos jogi problémákba ütközhetek. Nem hagyhattam figyelmen kívül egy kollégám ilyen figyelmeztetését, ezért úgy döntöttem, hogy alaposan áttanulmányozom ezt a témát, és megbizonyosodok arról, hogy mindent megértek, és jól csinálom. Az alábbiakban bemutatjuk ennek a kirándulásnak az eredményeit tárgykörben. Talán valakit érdekelni fog.

Az alapfogalmaktól kezdve az elektronikus aláírás aszimmetrikus titkosítási algoritmusokon alapul. Ezen algoritmusok fő jellemzője, hogy két különböző kulcsot használnak az üzenet titkosításához és visszafejtéséhez. A nagyközönség jobban ismeri a szimmetrikus algoritmusokat, amikor ugyanazzal a kulccsal (vagy jelszóval) titkosítunk és dekódolunk egy üzenetet, például jelszóval archiválunk egy fájlt, vagy védünk egy MS Word dokumentumot.

Sok minden aszimmetrikus titkosítási algoritmuson alapul, bár az a tény, hogy a titkosításhoz és a visszafejtéshez különböző kulcsokat használnak, még nem teszi lehetővé ezen algoritmusok hasznos alkalmazását. Ehhez további tulajdonságokkal kell rendelkezniük. Először is, a kulcsok nem lehetnek kiszámíthatóak, vagyis ha ismeri az egyik kulcsot, nem tudja kiszámítani a másodikat. Az is nagyon fontos, hogy a különböző titkosítási kulcsok különböző dekódoló kulcsoknak feleljenek meg, és fordítva – csak egy titkosítási kulcs felel meg egy visszafejtési kulcsnak.

Mi a valódi aláírás? Hiszen aláírnunk kell a dokumentumot, nem pedig titkosítanunk. Először is meg kell értenie, mi az aláírás, és miért van rá szükség. Ha saját kezű aláírását egy papírdokumentumra helyezi, ezzel biztosíthatja, hogy Ön (és nem valaki más) látta (és elfogadja) ezt a dokumentumot (és nem mást). A legfontosabb tulajdonság aláírások – letagadhatatlanság. Ez azt jelenti, hogy miután aláírta a dokumentumot, később nem mondhat le erről a tényről. Papír aláírás esetén a kézírási szakértelem, elektronikus esetén az aszimmetrikus titkosítási algoritmusokon alapuló matematikai módszereket fogja meggyőzni.

Hogyan működik az egész, dióhéjban. Vegyünk egy aszimmetrikus titkosítási algoritmust, generálunk egy kulcspárt (titkosításhoz és visszafejtéshez). A titkosítási kulcsot annak a személynek adjuk át, aki aláírja a dokumentumokat. Mindig magánál kell tartania, és nem kell odaadnia senkinek. Ezért ezt "privát" kulcsnak nevezik. Mindenkinek egy másik kulcsot (dekódolást) adunk, így az „nyitva van”. A dokumentum aláírásakor egy személynek titkosítania kell azt a privát kulcsával. Valójában nem maga a dokumentum van titkosítva, mivel elég nagy is lehet, és valójában nem kell titkosítanunk. Ezért a dokumentumhoz hash-t kapunk - ez egy bizonyos numerikus sorozat, amelynek nagy valószínűsége a különböző dokumentumok esetében eltérő, például a dokumentum „ujjlenyomata”. Az aláíró privát kulcsával titkosítva van. Ez a titkosított hash az Elektronikus aláírás dokumentum. Most, hogy rendelkezik egy dokumentummal, egy aláírással és egy nyilvános kulccsal, bárki könnyen ellenőrizheti, hogy az adott dokumentumot ezzel a titkos kulccsal írták-e alá. Ehhez ismét megkapjuk a dokumentum hash-jét, dekódoljuk az aláírást a nyilvános kulccsal, és összehasonlítjuk. Két azonos numerikus sorozatot kell kapnia.

Mindez nagyszerű, de eddig elértük a titkos kulcs aláírásának visszautasítását, vagyis bebizonyítottuk, hogy a dokumentumot egy adott kulccsal írják alá. Bizonyítanunk kell, hogy egy konkrét személy írta alá. Ehhez vannak hitelesítési központok és digitális tanúsítványok. A legfontosabb, amit a hitelesítésszolgáltató tesz, hogy igazolja, hogy a privát kulcs egy adott személyhez tartozik. Ennek garantálására a hitelesítési központ generálja a kulcspárokat, és személyesen adja ki a tulajdonosoknak (proxyval, távolról van lehetőség, de ezek csak részletek). A kulcsokkal együtt digitális tanúsítvány jön létre - ez egy elektronikus dokumentum (néha annak papíralapú ábrázolása), amely információkat tartalmaz a kulcs tulajdonosáról, magáról a kulcsról, a hitelesítési hatóságról és néhány egyéb információról. A tulajdonos általában ezt a jót egy biztonságos adathordozón (okoskártya, ru-token stb.) kapja meg, amely egy privát kulcsot és egy beágyazott nyilvános kulccsal rendelkező tanúsítványt tartalmaz. Magát a szolgáltatót mindig magánál kell tartani, és az abból másolt nyilvános kulcsú tanúsítványt mindenki megkapja, hogy ellenőrizhesse az Ön elektronikus aláírását.

Tehát az aláírás privát kulccsal, az aláírás ellenőrzése pedig nyilvános kulccsal történik. Ezért a „dokumentumot az OID-k halmaza írja alá” kifejezés (hangzott a fenti vitában) értelmetlen. Csak két kulcs vesz részt az aláírási és ellenőrzési eljárásban, a 63-FZ-ben ennek megfelelően vannak elnevezve - az aláírási kulcs és az aláírás-ellenőrző kulcs.

És mik ezek a hírhedt OID-k? Az X.509 digitális tanúsítványformátum lehetővé teszi kiterjesztések tárolását benne. Ezek néhány opcionális attribútum, amelyek további információk tárolására használhatók. Minden ilyen attribútum egy objektum, amelyet a hierarchikus könyvtárból származó azonosító határoz meg. Ezért az OID - Object Identifier. Nincs értelme elmélyedni maguknak az OID-k természetében. Valójában ez néhány további információ, amely szerepelhet a tanúsítványban.

Ezek a további attribútumok különféle célokra használhatók. További információkat adhatnak a tulajdonosról, a kulcsokról, a CA-ról, vagy további információkat hordozhatnak az ezt a tanúsítványt használó alkalmazásokhoz és szolgáltatásokhoz. Leggyakrabban szerepalapú hozzáférés-vezérlésre használják. Például fel lehet tüntetni a tanúsítványban, hogy a kulcs tulajdonosa a szervezet vezetője, és ez lehetőséget ad neki, hogy azonnal hozzáférjen a szükséges funkciókhoz és információkhoz minden IS-ben anélkül, hogy fel kellene vennie a kapcsolatot az egyes IS-ek adminisztrátoraival. IS, és módosítsa a hozzáférési beállításokat. Mindez persze feltéve, hogy ezek az IS-ek mindegyike a felhasználó tanúsítványát használja az engedélyezéshez, és ugyanazt az attribútumot elemzi ugyanúgy (ezért az attribútumok a könyvtárból kerülnek kiválasztásra, nem pedig önkényesen beállítva).

Az eltérő jelentkezések miatt két, egymástól teljesen eltérő jellegű tanúsítványt kapunk. Az egyik – igazolja, hogy én vagyok, és ez mindig így van. Végtére is, életében egyszer vagy többször is kiadható, például útlevél. A meglévő kriptográfiai algoritmusok tökéletlensége miatt azonban biztonsági okokból ezeket a tanúsítványokat minden évben újra ki kell adni. A második típusú tanúsítvány további információkat kezel, és sokkal gyakrabban változhat, mint akár évente egyszer. Ezzel össze lehet hasonlítani hívókártya. pozíció megváltozott, Email, telefon - új névjegykártyákat kell készítenie.

A világon ezt a két típusú tanúsítványt nyilvános kulcsú tanúsítványnak (PKC) és attribútum tanúsítványnak (vagy engedélyezési tanúsítványnak – AC) nevezik. A második típusú tanúsítványt sokkal gyakrabban állíthatja ki egy másik szervezet, mint az elsőt, és könnyebben hozzáférhetőnek és könnyebben beszerezhetőnek kell lennie, mint egy személyes „nyilvános kulcsú” tanúsítvány. Mindenesetre ezt javasolja az RFC 3281, amelyet az ilyen típusú tanúsítványokhoz ajánlanak. A második típusú tanúsítványnak csak a nyilvános kulcsú tanúsítványra mutató hivatkozást kell tartalmaznia, hogy az azt a felhasználó felhatalmazására használó rendszer először azonosítani tudja a PKC-t használó személyt.

Most lépjünk közelebb a valóságunkhoz. Jogalkotási szinten az elektronikus aláírás használatával kapcsolatos kérdések ben Orosz Föderáció, két fő dokumentum szabályozza - az Orosz Föderáció 2011. június 4-i 63-FZ „Az elektronikus aláírásról” törvénye és az Orosz Föderáció Szövetségi Biztonsági Szolgálatának 2011. 12. 27-i rendelete. 795 „Az elektronikus aláírás-ellenőrző kulcs minősített tanúsítványa nyomtatványára vonatkozó követelmények jóváhagyásáról”. A minősített tanúsítvány összetételét a 795. számú végzés írja le (II. rész "A minősített tanúsítvány mezőkészletére vonatkozó követelmények"), és nem tartalmaz követelményeket azokra az attribútumokra, amelyek egyetlen információs rendszerben sem szabályozzák a jogosultságot. További kötelező attribútumokként csak olyan információk szerepelnek, amelyek lehetővé teszik egy természetes vagy jogi személy azonosítását az Orosz Föderációban (TIN, SNILS stb.). Bár sem a törvény, sem az FSZB végzése nem tiltja, hogy a minősített tanúsítványban más információ szerepeljen.

Mint látható, semmilyen jogszabályi norma nem írja elő a minősített tanúsítványban a jogosultsággal kapcsolatos attribútumok kötelező jelenlétét semmilyen információs rendszerben. Honnan származnak ezek a követelmények? És a fejlesztőktől (vagy "tulajdonosoktól") származnak. konkrét rendszerek. Vegyük például az SMEV technológiai portálon közzétett „Útmutató az elektronikus aláírás használatához a hivatalok közötti elektronikus interakciókban (4.3-as verzió)”. Valójában ennek a dokumentumnak a 6. pontjában ezt olvashatjuk: „Az EP-SP tanúsítvány megalkotásához szükséges információk előkészítésekor meg kell határozni, hogy szükséges-e információt kérni a Rosreestrtől (kivonat az USRR-ből). Ha ilyen kérésre van szükség, az OID-t fel kell tüntetni az ES-SP tanúsítvány „Javított kulcs” mezőjében (OID=2.5.29.37) a Rosreestr. követelményei szerint. Vagyis a Rosreestr információs rendszer ezt az attribútumot használja a tanúsítvány tulajdonosának kiadható információk meghatározására. Ugyanez a dokumentum azonban tartalmaz egy fontos megjegyzést, nevezetesen ez a követelmény az ESIA (egyetlen engedélyezési szolgáltatás állami rendszerekben) teljes indulásáig és a Rosreestr rendszer ehhez való csatlakoztatásáig érvényes. Ez egy fontos megjegyzés, tartsa szem előtt.

Az államban használt egyéb IP-kkel nem foglalkozom. szervek. Gyanítom, hogy hasonló a helyzet. A közbeszerzési portál, az elektronikus kereskedési platformok, a különféle számviteli és pénzügyi alkalmazások is megkövetelhetik bizonyos további OID-k meglétét a felhasználói tanúsítványban. Ugyanakkor téves az az állítás, hogy az információs rendszer OID-jének a tanúsítványba írásával valahogy a hitelesítési központra ruházom a felelősséget, finoman szólva is. A CA ezeket az adatokat a kérelmem szerint beírja a tanúsítványba. Ha megváltozott a beosztásom, és elfelejtettem kérvényezni a régi visszavonását és új tanúsítvány kiállítását, a CA nem tehető felelőssé a feledékenységemért. Ezenkívül a 63-FZ törvény közvetlenül a tanúsítvány tulajdonosára ruházza a felelősséget a nem megfelelő használatért. A 17. cikk (6) bekezdésében a következőket olvashatjuk:
A minősített tanúsítvány birtokosának:
1) ne használja az elektronikus aláírási kulcsot, és azonnal lépjen kapcsolatba a minősített tanúsítványt kibocsátó akkreditált tanúsító központtal a tanúsítvány megszüntetése érdekében, ha okkal feltételezhető, hogy az elektronikus aláírási kulcs titkosságát megsértették;
2) minősített elektronikus aláírást használjon a minősített tanúsítványban foglalt korlátozásoknak megfelelően (ha ilyen korlátozások megállapításra kerültek).

Az, hogy a tanúsítványban tárolni kell a felhasználó szerepére és hozzáférésére vonatkozó információkat meghatározott információs rendszerekben, olyan problémához vezet, amely vitát váltott ki a Facebookon, nevezetesen, hogy a tanúsítványt sokkal gyakrabban kell újra kiadni, mint azt a személyes elektronikus aláírás biztonsági követelményei megkövetelik. . A pozíció megváltozott - újra kiállítjuk az igazolást. Megjelent egy új IS - újra kiadjuk a tanúsítványt. Egy új szervezet IS-jétől (Rosreestr) kellett információkat kérni - a tanúsítványt újra kiadjuk.

100%-os sikert aratott a világban Attribute Certificate (vagy Authorization Certificate) elnevezésű koncepció, amelyről fentebb már szó esett, és melyben a tanúsítványok más hitelesítő hatóság (Attribute Autority, ellentétben a Certificate Authority-vel) történő kibocsátását javasolják. minősített ES-tanúsítványokat kiállító rendes CA) és egyszerűsített módon. Ez a tanúsítvány maga nem tartalmazhat elektronikus aláírási kulcsot és információkat a tulajdonosról. Ehelyett a tulajdonos nyilvános kulcsú tanúsítványára mutató hivatkozást tartalmaz, ahonnan az adott személyre vonatkozó többi szükséges információhoz hozzájuthat.

Meg kell jegyezni, hogy ennek a rendszernek az alkalmazása is nagyon korlátozott, és nem old meg minden problémát. Mi van akkor, ha a következő információs rendszer úgy dönt, hogy ugyanazt az „Improved key” (OID=2.5.29.37) tanúsítványmezőt használja, amelyet a Rosreestr érték már foglalt? Két különböző érték beírása egy mezőbe nem működik. Ezért egy újabb AC-t kell kiadnunk! Egy másik probléma a PKC rövid élettartamával (egy év) kapcsolatos. Ha több AC-nk van (amelyek tartalmazzák a személyes tanúsítványra mutató hivatkozást), akkor a PKC lejárta után mindegyiket újra ki kell adni. Az AC hatékony használatához minden információs rendszerben egyetlen felhasználó jogosultsági központra van szükség, és minden alkalmazásnak következetesen és egységesen kell használnia a tanúsítvány attribútumokat.

Ilyen egyetlen engedélyezési központ az állam számára. hatóságok már léteznek – ez az ESIA. Emlékezzünk vissza a Rosreestr OID-jaival kapcsolatos megjegyzésre. A jövőben ezeket felváltják az ESIA-tól származó információk. Más információs rendszereknek is, amelyekben köztisztviselők dolgoznak, ugyanígy kell eljárni. Ahelyett, hogy AC-t használnánk az engedélyezéshez, integrálni kell az ESIA-val és onnan megkapja a szükséges információkat az ESIA-nak képesnek kell lennie minősített ES-tanúsítványt egy fiókhoz kötni, így az információs rendszerek képesek lesznek személyes kulcs segítségével hitelesíteni a felhasználót, és az ESIA-n keresztül engedélyezni (az alkalmazáshoz való hozzáférést). Egy ilyen rendszer univerzálisabbnak és megbízhatóbbnak tűnik, mint a tanúsítványmezők használata, és a jövőben automatizálni fogja a hozzáférés-kezelést. Ha létrejön a közalkalmazottak személyi nyilvántartásának egységes rendszere, az ESIA képes lesz információgyűjtésre egy személy jogosítványai közvetlenül onnan.Egy másik pozícióba áthelyezett személy – automatikusan elvesztette a hozzáférést az egyik rendszerhez, és megszerezte a másikat. továbbra is az ES kulcsát használja a dokumentumok aláírására, semmit sem kell újra kiadni.

Az Oroszországi Bank által jóváhagyott, a CJSC AEI PRIME értékpapírokra és egyéb pénzügyi eszközökre vonatkozó információk közzétételére vonatkozó technikai feltételekkel összhangban (), elektronikus dokumentumokat közérdekű adatot tartalmazó információkat az adatközlés alanyának fokozottan minősített elektronikus aláírással kell aláírnia (lásd a Műszaki Feltételek 1.7. pontját). Ez a követelmény 2017. február 1-től hatályos.

Jelenleg megkezdődött az elektronikus aláírás alkalmazásának tesztidőszaka a PRIME közzétételi szerveren, amely 2017. január 31-ig tart.

A működés tesztelésére a PRIME ügyfelek használhatják bármely korábban ehhez a jogi személyhez kapott ES-kulcs tanúsítvány.

A Felhasználó elektronikus aláírás-ellenőrző kulcsának minősített tanúsítványának 2017. február 1-től a Műszaki Feltételek kérésére (lásd 1.7. és 9.6. pont) meg kell felelnie a minősített tanúsítvány formájára vonatkozó, a Kbt. Oroszország Szövetségi Biztonsági Szolgálata, 2011. december 27-i 795. sz. „Az elektronikus aláírás-ellenőrző kulcs minősített tanúsítványának formájára vonatkozó jóváhagyási követelményekről. Továbbfejlesztett kulcsfelhasználói tanúsítvány kiterjesztés ( objektumazonosító 2.5.29.37) tartalmaznia kell a közzétételi objektum azonosítóját PRIME - OID 1.2.643.6.42.5.5.5

A "PRIME" adatközlés felhasználójának személyes fiókjába való bejelentkezés az ügyfél által korábban kapott BEJELENTKEZÉS és JELSZÓ használatával történik.

Az ügyfélnek az információs hírfolyamban üzenetek közzétételére, dokumentumok internetes oldalon történő közzétételére, a kibocsátó regisztrációs kártyáján az információs rendszerben történő módosítására irányuló tevékenységét elektronikus aláírással kell megerősíteni.

Az ES használatához a PRIME információközlési kiszolgálón az ügyfélnek először telepítenie kell a beépülő modult (a telepítés ingyenes a felhasználók számára, és nem vesz igénybe sok időt). Lásd alább a bővítmény telepítési útmutatóját.

Az adatfelhasználó személyes fiókjában, a bővítmény ügyfél telepítése után, az információs hírfolyamban üzenet közzétételére vagy dokumentum internetes elhelyezésére szolgáló űrlapok kitöltésekor, valamint a regisztrációs kártya adatainak megváltoztatásakor, további „Dokumentum elektronikus aláírása” mezők jelennek meg, ahol ki kell választani a megfelelő szolgáltatásmező aláíró kulcs tanúsítványában megjelenő mezőt, és rá kell kattintani az „Aláírás” gombra. Ily módon az ügyfél megerősíti az információ nyilvánosságra hozatala vagy a regisztrációs kártya módosítása érdekében tett intézkedéseit.

Az üzenet elektronikus aláírással történő aláírása után az ügyfélnek a „Közzététel” gombra kell kattintania
A dokumentum elektronikus aláírással történő aláírása után az ügyfélnek a „Dokumentum hozzáadása” gombra kell kattintania.
A regisztrációs kártyán történt változások elektronikus aláírással történő aláírását követően az ügyfélnek az „Azonosító lap elküldése” gombra kell kattintania.

Felhívjuk figyelmét, hogy az ügyfelek által a személyes fiókjukon keresztül a „Tesztbejelentkezés (munkavégzés ES-vel)” felhatalmazáson keresztül küldött összes üzenet az információs hírfolyamban munkamódban megjelenik. Az ügyfelek által a személyes fiókjukon keresztül a „Tesztbelépés (munkavégzés ES-vel)” felhatalmazáson keresztül elhelyezett összes dokumentum munkamódban automatikusan felkerül a kibocsátók oldalára.

Ellenkező esetben a kibocsátó eljárása a PRIME információközlési szerveren lévő személyes fiókban nem változik.