Kvalificirani elektronički potpis - problemi OID-a informacijskih sustava. Loš potpis Potpis nije uspio provjera Nedostaje identifikator objekta OID Oid dešifriranje

Kada unesete svoj osobni račun kako biste zatražili QEP, prikazuje se poruka « Računalo nije konfigurirano . Za nastavak idite na stranicu postavki računala i slijedite predložene korake » . Nakon što odete na stranicu s postavkama i instalirate sve potrebne komponente osobni račun pojavljuje se poruka da računalo nije ponovno konfigurirano.

Da biste ispravili pogrešku, morate:

1. Dodajte adresu svog osobnog računa https://i.kontur-ca.ru na pouzdane stranice. Za ovo:

Odaberite izbornik "Start" > "Upravljačka ploča" > "Internetske mogućnosti";
Idite na karticu "Sigurnost", odaberite element "Pouzdana mjesta" (ili "Pouzdana mjesta") i kliknite na gumb "Čvorovi";
Navedite sljedeću adresu čvora https://i.kontur-ca.ru u polju Dodaj u zonu i kliknite gumb Dodaj.

Ako se ova adresa već nalazi na popisu pouzdanih web-mjesta, prijeđite na sljedeći korak.

2. Provjerite je li adresa osobnog računa https://i.kontur-ca.ru definirana kao pouzdana:

Ako se koristi Internet Explorer inačica 8, tada, kada ste na stranici za autorizaciju, trebate provjeriti nalazi li se potvrdni okvir Pouzdana mjesta na dnu stranice. Ako nema potvrdnog okvira, ali postoji natpis « Internet”, tada adresa https://i.kontur-ca.ru nije dodana pouzdanim stranicama.

Ako se koristi Internet Explorer verzija 9 i novija, tada, na stranici za autorizaciju, trebate kliknuti desnom tipkom bilo gdje na stranici, odabrati "Svojstva". U prozoru koji se otvori, redak "Zona" trebao bi sadržavati natpis "Pouzdana mjesta". Inače, adresa https://i.kontur-ca.ru nije dodana pouzdanim stranicama.

Ako adresa osobnog računa nije definirana kao pouzdana, trebali biste kontaktirati administratora sustava sa zahtjevom za dodavanje adrese https://i.kontur-ca.ru u pouzdane čvorove.

3. Provjerite možete li se prijaviti na svoj osobni račun. Ako se pogreška ponovi, trebali biste pokrenuti uslužni program RegOids s veze. Ovaj uslužni program automatski će konfigurirati OID postavke u registru računala. Također možete ručno uvesti jednu od grana registra, ovisno o bitnosti instaliranog operativnog sustava:

4. Provjerite koristi li računalo administratorska prava (za provjeru idite na Start - Upravljačka ploča - Korisnički računi i obiteljska sigurnost - Korisnički računi). Ako prava nisu dovoljna, korisniku morate dati puna prava, za to se obratite svom administratoru.

5. Nakon dovršetka 3. koraka potrebno je ponovno pokrenuti računalo i provjeriti ulaz na Osobni račun.

Ako nijedna od uputa nije pomogla, obratite se tehnička podrška po adresi [e-mail zaštićen] U pismu mora biti navedeno:

1. Broj dijagnoze.

Da biste to učinili, morate otići na dijagnostički portal nahttps://help.kontur.ru , pritisni gumb " Pokreni dijagnostiku » . Nakon dovršetka postupka provjere, na zaslonu će se prikazati dijagnostički broj. Navedite dodijeljeni poziv na broj u pismu.

2. Snimka zaslona prozora s greškom (kada koristite Internet Explorer verzije 9 i novije, morate priložiti i snimku zaslona prozora "Svojstva" - vidi točku 2).

3. Izvezite i priložite sljedeće grane registra:

32-bit: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64-bitni: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo

Opće odredbe.
Odabir načina prikaza određenih podataka i dodatnih ograničenja na sastav polja certifikata temelji se na sljedećim načelima:
Međunarodne preporuke. Ovaj dokument je razvijen uzimajući u obzir međunarodne preporuke:
- RFC 3280 (ažuriranje RFC 2459) Internet X.509 Infrastruktura javnog ključa. Profil certifikata i popisa opoziva certifikata (CRL).
- RFC 3039 Internet X.509 Infrastruktura javnog ključa. Profil kvalificiranog certifikata - ovaj RFC predlaže Opći zahtjevi na sintaksu (sastav) certifikata, čija je upotreba pravno značajna.

Sastav i svrha polja certifikata.

Ovaj odjeljak daje opis glavnih polja certifikata javnog ključa koji je u skladu sa Zakonom "O elektroničkom digitalnom potpisu" od 10.01.2002.

Koncepti, oznake i terminologija korišteni u ovom odjeljku temelje se na RFC 3280 i RFC 3039, koji se pak temelje na ITU-T X.509 Preporuci verzija 3. Sadržaj odjeljka ne kopira sadržaj ovih dokumenata , već samo ukazuje na razlike i značajke uporabe potvrda polja kojima se provode zahtjevi za sastav EDS potvrde propisani člankom 6. Zakona o EDS-u.

Za sva polja certifikata koja zahtijevaju vrijednosti niza na ruskom jeziku, poželjno je koristiti univerzalno UTF-8 kodiranje (tip UTF8String).

Svrha ovog odjeljka je definirati sastav i svrhu polja certifikata bez uzimanja u obzir zahtjeva određenog tijela za certificiranje. Dokumenti koji reguliraju rad certifikacijskog tijela mogu ograničiti sastav polja certifikata i skup atributa koji se koriste za identifikaciju CA i nositelja certifikata ključevi za potpis.

verzija
Sve izdane potvrde mora imaju verziju 3.

Serijski broj
Polje serijskog broja mora sadrže "...jedinstveni registarski broj certifikata ključa potpisa" (članak 6. stavak 1. stavak 1.). Jedinstvenost broja certifikata mora se poštovati unutar danog certifikacijskog tijela (CA).

Valjanost
Polje valjanosti mora sadrže "... datume početka i isteka roka valjanosti certifikata ključa potpisa koji se nalazi u registru centra za ovjeru" (članak 6. stavak 1. stavak 1.).

SubjectPublicKeyInfo
SubjectPublicKeyInfo polje mora sadrže "...javni ključ elektroničkog digitalnog potpisa" (članak 6. stavak 1. stavak 3.).

Izdavatelj
Savezni zakon "O EDS-u" pretpostavlja izdavanje certifikata samo pojedincima, ova odredba se također odnosi na certifikate samih CA i potvrde o resursima. Kako bi se ispunili formalni zahtjevi Federalnog zakona, predlaže se da se u atributima CA i potvrdama resursa naznače stvarne informacije organizacije, s obzirom da se takva potvrda izdaje ovlaštenoj osobi CA ili Resursa i navedene podatke treba tumačiti i registrirati kao potvrdu za pseudonim, što je dopušteno Saveznim zakonom "O EDS-u".
Polje izdavatelja mora jedinstveno identificirati organizaciju koja je izdala certifikat i sadržavati službeno registrirani naziv organizacije.
Za identifikaciju se mogu koristiti sljedeći atributi:

ime države	(id-na 6)
naziv države ili pokrajine	(id-na 8)
naziv lokaliteta	(id-na 7)
Naziv organizacije	(id-na 10)
naziv organizacijske jedinice	(id-na 11)
poštanska adresa	(id-u 16)
serijski broj	(id-na 5)

Polje izdavatelja mora svakako uključite atribute koji opisuju "naziv i mjesto certifikacijskog tijela koje je izdalo certifikat ključa potpisa" (članak 6. stavak 1. stavak 5.).

Ime mora navedeno u atributu OrganizationName. Kada koristite atribut OrganizationName može biti

CA lokacija može biti biti specificiran pomoću skupa atributa countryName, stateOrProvinceName, localityName (od kojih je svaki neobavezan) ili pomoću jednog atributa poštanske adrese. Bilo kojom od gore navedenih metoda, mjesto CA mora biti prisutan u certifikatu.

mora sadržavati pravnu adresu certifikacijskog tijela. Razmak (znak "0x20") mora se koristiti kao graničnik.

atribut polja subjekt serijski broj mora koristiti u kolizijama imena.

predmet
Za predstavljanje DN-a (Distinguished Name) vlasnika certifikata svibanj koriste se sljedeći atributi:

ime države	(id-na 6)
naziv države ili pokrajine	(id-na 8)
naziv lokaliteta	(id-na 7)
Naziv organizacije	(id-na 10)
naziv organizacijske jedinice	(id-na 11)
titula	(id-na 12)
uobičajeno ime	(id-na 3)
pseudonim	(id-na 65)
serijski broj	(id-na 5)
poštanska adresa	(id-u 16)

Kako bi se ispunili formalni zahtjevi Federalnog zakona, predlaže se da se u atributima CA i potvrdama resursa naznače stvarne informacije organizacije, s obzirom da se takva potvrda izdaje ovlaštenoj osobi CA ili Resursa i navedene podatke treba tumačiti i registrirati kao potvrdu za pseudonim, što je dopušteno Saveznim zakonom "O EDS-u".

predmetno polje mora obvezno je sadržavati sljedeće podatke: "prezime, ime i patronimiju vlasnika certifikata ključa potpisa ili pseudonima vlasnika" (članak 6. točka 1. stavak 2.).

Prezime, ime i patronimik vlasnika mora biti sadržani u atributu commonName i podudarati se s onima navedenima u putovnici. Razmak (znak "0x20") mora se koristiti kao graničnik.

Vlasnički pseudonim mora sadržane u atributu alias.

Korištenje jednog od ovih atributa isključuje korištenje drugog.

Ostali atributi su izborni.

"Po potrebi, u certifikatu ključa potpisa, na temelju popratnih dokumenata, naznačeno je radno mjesto (s nazivom i sjedištem organizacije u kojoj je to radno mjesto) ..." (članak 6. točka 2.).

Naziv nositelja certifikata mora navedeno u atributu title. Vrijednost atributa mora odgovaraju upisu u dokumente koji potvrđuju poziciju utvrđenu za nositelja certifikata.

Atribut title, prema RFC 3039, mora biti uključeni u proširenje subjectDirectoryAttributes. Međutim, ovaj dokument (i RFC 3280) dopušta da bude uključen u predmetno polje.

Obavezno kada koristite atribut title mora uključuju atribute koji opisuju naziv i mjesto organizacije u kojoj je radno mjesto osnovano.

Ime kompanije mora navedeno u atributu OrganizationName. Vrijednost atributa mora podudaraju s nazivom organizacije u osnivačkim ili drugim istovrijednim dokumentima. Kada koristite atribut OrganizationName može biti također se koristi atribut OrganizationalUnitName.

Mjesto organizacije može biti biti specificiran pomoću skupa atributa countryName, stateOrProvinceName, localityName (od kojih je svaki neobavezan) ili pomoću jednog atributa poštanske adrese.

Atribut postaAddress, ako se koristi, mora sadrže pravnu adresu organizacije ili adresu prebivališta vlasnika certifikata ključa potpisa (za pojedinca).

Ako je prisutan atribut OrganizationName, atributi countryName, stateOrProvinceName, localityName i poštanskaAddress mora tumačiti kao lokaciju organizacije.

Neobavezni atributi polja predmeta (countryName, stateOrProvinceName, localityName, OrganizationName, OrganizationalUnitName, title, poštanska adresa) svibanj biti uključen, ako je to određeno propisima CA, umjesto polja subjekta u produžetku subjectDirectoryAttributes (vidi točku 3.8.1). U ovom slučaju oni ne bi trebao biti uključeni u predmet i Ne možeš koristiti za razlikovanje vlasnika certifikata ključeva za potpisivanje.

atribut serijskog broja mora biti uključeni u predmetno polje certifikata u slučaju kolizije imena. On također može biti biti uključeni ako je to utvrđeno propisima centra za certifikaciju.

atribut serijskog broja može biti:

biti proizvoljan (dodijeljen od strane samog certifikacijskog tijela);
sadrže identifikator (broj) koji je dodijelila državna (ili druga) organizacija (na primjer, TIN, serija i broj putovnice, broj osobne iskaznice itd.).

Potrebna proširenja
mora uključiti sljedeća proširenja:
- Upotreba ključa (id-ce 15)
- CertificatePolicies (id-ce 32)
1. Upotreba ključa
  Kako bi se certifikat koristio za provjeru digitalnog potpisa, u proširenju keyUsage mora bitovi digitalSignature(0) i nonRepuduation(1) moraju biti postavljeni.
  CertificatePolicies
  Proširenje certificatePolicies namijenjeno je definiranju opsega pravno relevantne primjene certifikata.
  "... naziv EDS alata s kojima se koristi ovaj javni ključ ..." (članak 6. stavka 1. stavak 4.), "... podatke o odnosu u čijoj implementaciji elektronički dokument s elektronička digitalni potpis imat će pravni značaj..." (članak 6. stavak 1. stavak 6.) i druge podatke kojima se uređuje postupak pribavljanja i korištenja certifikata ključa potpisa, Može biti dostupno na CPSuri-u (Certificate Practice Statement URI) navedenom u ovom proširenju.

Dodatna proširenja
Kao dio certifikata ključa za potpisivanje svibanj uključiti sve druge ekstenzije. Prilikom uključivanja proširenja u certifikat ključa EDS, potrebno je osigurati dosljednost i nedvosmislenost podataka prikazanih u certifikatu.
Ovaj dokument ne navodi upotrebu proširenja osim proširenja subjectDirectoryAttributes (id-ce 9).

SubjectDirectoryAttributes
proširenje subjectDirectoryAttributes može biti sadrže atribute koji nadopunjuju informacije navedene u polju za predmet.
Osim atributa navedenih u RFC 3039, preporučuje se da se u proširenju subjectDirectoryAttributes podrže sljedeći atributi:

kvalifikacija	{-}
ime države	(id-na 6)
naziv države ili pokrajine	(id-na 8)
naziv lokaliteta	(id-na 7)
Naziv organizacije	(id-na 10)
naziv organizacijske jedinice	(id-na 11)
titula	(id-na 12)
poštanska adresa	(id-u 16)

"Po potrebi, certifikat ključa potpisa, na temelju popratnih dokumenata, pokazuje ... kvalifikacije vlasnika certifikata ključa potpisa" (članak 6. točka 2.).

Podaci o kvalifikaciji vlasnika certifikata ključa EDS mora navedeno u atributu kvalifikacije. Ovaj atribut nije definiran u međunarodnim preporukama (vidi klauzulu 2) i podliježe registraciji.

Ako su atributi countryName, stateOrProvinceName, localityName, OrganizationName, OrganizationalUnitName, title, postAddress uključeni u proširenje subjectDirectoryAttributes, oni ne bi trebao biti uključeni u predmetno polje.

Za pohranu drugih podataka o vlasniku certifikata ključa potpisa svibanj koristiti druge (već registrirane ili podložne registraciji) atribute koji nisu u suprotnosti s ograničenjima nametnutim proširenjem certifikata i drugim dokumentima koji reguliraju rad CA.

Aplikacija ASN1

id-at: OID vrijednost: 2.5.4
OID opis: X.500 vrste atributa.
id-ce: OID vrijednost: 2.5.29
OID opis: Identifikator objekta za proširenja certifikata verzije 3.

2.5.4.5 id-at-serijski broj serialNumber ATTRIBUTE::= ( SA SINTAKSOM Ispisni niz(VELIČINA (1..64)) PRAVILO USPOREĐIVANJA JEDNAKOSTI caseIgnoreMatch PODNIZOVI PODARĐIVANJA PRAVILO caseIgnoreSubstringsMatch ID id-at-serijski broj)

(RFC 3039)
Tip atributa serialNumber TREBA, kada je prisutan, koristiti za razlikovanje između imena gdje bi polje predmeta inače bilo identično. Ovaj atribut nema definiranu semantiku osim osiguravanja jedinstvenosti naziva subjekata. MOŽE sadržavati broj ili kod koji je dodijelio CA ili identifikator koji je dodijelilo državno ili civilno tijelo. Odgovornost CA je osigurati da je serijski broj dovoljan za rješavanje bilo kakvih kolizija naziva subjekta.

2.5.4.3 - id-at-commonName

OID vrijednost: 2.5.4.3

OID opis: Tip atributa zajedničkog imena specificira identifikator objekta. Uobičajeno ime nije ime imenika; to je (možda dvosmisleno) ime pod kojim je objekt općenito poznat u nekom ograničenom opsegu (kao što je organizacija) i u skladu je s konvencijama imenovanja zemlje ili kulture s kojom je povezan.

CommonName ATTRIBUTE::= ( PODVRSTA imena SA SINTAKSOM String direktorija (ub-zajedničko-naziv) ID (id-at-commonName) )

(RFC 3039: profil kvalificiranog certifikata)
OID vrijednost: 2.5.4.65

pseudonim ATTRIBUTE::= ( PODVRSTA imena SA SINTAKSOM ID niza imenika (id-at-pseudonim))

OID vrijednost: 2.5.29.17

OID opis: id-ce-subjectAltName Ovo proširenje sadrži jedno ili više alternativnih imena, koristeći bilo koji od različitih oblika imena, za entitet koji je CA vezan za certificirani javni ključ.

PROŠIRENJE SubjectAltName::= ( SINTAKSA Generalnames IDENTIFIED BY id-ce-subjectAltName ) GeneralNames::= VELIČINA SEQUENCE (1..MAX) OF GeneralName GeneralName::= CHOICE ( otherName INSTANCE OF OTHER-NAME, rfcIAStringNa, rfcIAStringName5 *) x400Address ORAaddress, directoryName Name, ediPartyName EDIPartyName, uniformResourceIdentifier IA5String, IPAddress OCTET STRING, registeredID OBJECT IDENTIFIER ) (*) – proizvoljni niz. OTHER-NAME::= SEQUENCE ( type-id OBJEKT IDENTIFIER vrijednost EXPLICIT ANY DEFINED BY type-id )

OID vrijednost: 2.5.4.16

OID opis: Tip atributa Poštanska adresa specificira informacije o adresi za fizičku dostavu poštanskih poruka od strane poštanskog tijela imenovanom objektu. Vrijednost atributa za poštansku adresu obično će se sastojati od odabranih atributa iz MHS neformatirane poštanske O/R adrese verzije 1 prema CCITT Rec F.401 i ograničena na 6 redaka od 30 znakova svaki, uključujući naziv poštanske zemlje. Obično informacije sadržane u takvoj adresi mogu uključivati ime primatelja, adresu ulice, grad, državu ili pokrajinu, poštanski broj i eventualno broj poštanskog pretinca ovisno o specifičnim zahtjevima imenovanog objekta.

PoštanskaAddress ATTRIBUTE::= ( SA SINTAKSOM PRAVILO USPOREĐIVANJA EQUALITY PostalAddress caseIgnoreListMatch PODNIZOVI PODNIZOVI UPOTREBE caseIgnoreListSubstringsMatch ID id-at-postalAddress ) PoštanskiAddress::= SEQUENCEdressub-string-Strubstalad (1.

OID vrijednost: 2.5.4.12

OID opis: Tip atributa Title specificira naznačeni položaj ili funkciju objekta unutar organizacije. Vrijednost atributa za naslov je string.

Title ATTRIBUTE::= ( PODVRSTA imena SA SINTAKSOM Niz direktorija (ub-title) ID id-at-title ) id-ce-certificatePolicies IDENTIFIKATOR OBJEKTA::= ( id-ce 32 ) CertificatePolicies::= VELIČINA SEKVENCA (1. Max) OF političkim informacijama o politici :: = slijed (PolicyIdentifier certpolicyid, PoliticsQualifiers Veličina sekvence (1..max) PolicyQualifierInfo nije obavezno) certpolicyid :: = identifikator identifikatora objekta PolicyQualifierInfo :: = sekvence (PolicyQualifierIDIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIFIJALO) za kvalifikatore internetske politike id-qt IDENTIFIKATOR OBJEKTA::= ( id-pkix 2 ) id-qt-cps IDENTIFIKATOR OBJEKTA::= ( id-qt 1 ) id-qt-unotice IDENTIFIKATOR OBJEKTA::= ( id-qt 2 ) PolicyQualifierId::= IDENTIFIKATOR OBJEKTA (id-qt-cps | id-qt-unotice) Kvalifikator::= CHOICE ( cPSuri CPSuri, korisnička obavijest ) CPSuri::= IA5String Korisnička obavijest::= SEQUENCE ( noticeRef Noticetexplicitt Display) Referenca obavijesti::= SEQUENCE ( organi zation DisplayText, noteNumbers SEQUEENCE OF INTEGER ) DisplayText::= IZBOR ( visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE) (1..)200.

Vadim Malikh
02.10.2013

Prije nekog vremena u grupi Forum Rus na Facebooku vodila se rasprava o korištenju informacijski sustavi ah vlasti (rasprava je bila izvan teme, možete to vidjeti u komentarima ispod). Suština spora je da se zbog OID-a (object identifier - object identifier) informacijskih sustava koji moraju biti registrirani u certifikatima kvalificiranog elektroničkog potpisa (ES) službenih osoba, ti isti ES moraju mijenjati čak i češće nego jednom. godine (što je diktirano sigurnosnim zahtjevima) , a to zauzvrat dovodi do dodatnih složenosti i troškova, budući da većina tijela radi s komercijalnim CA-ima bez vlastitih. Problem se pogoršava nedostatkom zajedničkog razumijevanja o tome što su to OID-ovi pružaju i koliko su potrebni i/ili obvezni.

Tijekom rasprave protukandidat me upozorio da bih zbog nepoznavanja nekih od temelja predmetnog područja u budućnosti mogao doći u određene probleme sa zakonom. Nisam mogao zanemariti takvo upozorenje kolege, pa sam odlučio ponovno pažljivo proučiti ovu temu i uvjeriti se da sam sve razumio i učinio kako treba. U nastavku donosimo neke od rezultata ovog izleta u predmetno područje. Možda će netko biti zainteresiran.

Počevši od osnovnih pojmova, elektroničko potpisivanje temelji se na asimetričnim algoritmima šifriranja. Glavna značajka ovih algoritama je da se dva različita ključa koriste za šifriranje i dešifriranje poruke. Široj javnosti su poznatiji simetrični algoritmi, kada šifriramo i dešifriramo poruku istim ključem (ili lozinkom), na primjer, arhiviramo datoteku lozinkom ili štitimo MS Word dokument.

Mnoge se stvari temelje na asimetričnim algoritmima za šifriranje, iako sama činjenica da se različiti ključevi koriste za enkripciju i dešifriranje još ne bi omogućila bilo kakvu korisnu primjenu ovih algoritama. Da bi to učinili, moraju imati neka dodatna svojstva. Prvo, ključevi ne smiju biti izračunljivi, odnosno ako znate jedan ključ, ne možete izračunati drugi. Također je vrlo važno da različiti ključevi za šifriranje odgovaraju različitim ključevima za dešifriranje i obrnuto – samo jedan ključ za šifriranje odgovara jednom ključu za dešifriranje.

Koji je stvarni potpis? Uostalom, dokument trebamo potpisati, a ne šifrirati ga. Prvo morate razumjeti što je potpis i zašto je potreban. Kada stavite svojeručni potpis na papirnati dokument, time uvjeravate da ste vi (a ne netko drugi) vidjeli (i pristali na) ovaj dokument (a ne neki drugi). Najvažnija imovina potpisi - nepovratnost. To znači da nakon što potpišete dokument, ne možete se kasnije odreći te činjenice. U slučaju papirnatog potpisa, vještačenje rukopisa osudit će vas, u slučaju elektroničkog, matematičke metode temeljene na asimetričnim algoritmima enkripcije.

Kako to sve funkcionira, ukratko. Uzimamo asimetrični algoritam šifriranja, generiramo par ključeva (za šifriranje i dešifriranje). Ključ za šifriranje dajemo osobi koja će potpisati dokumente. Mora ga uvijek držati kod sebe i nikome ga ne dati. Stoga se naziva "privatni" ključ. Svima dajemo još jedan ključ (dešifriranje), pa je “otvoreno”. Prilikom potpisivanja dokumenta, osoba ga mora šifrirati svojim privatnim ključem. Nije sam dokument taj koji je zapravo šifriran, budući da može biti prilično velik i zapravo ga ne trebamo šifrirati. Stoga se za dokument dobiva hash - to je određeni numerički niz s visokim stupnjem vjerojatnosti različit za različite dokumente, poput "otiska prsta" dokumenta. Šifriran je privatnim ključem potpisnika. Ovaj šifrirani hash je Elektronički potpis dokument. Sada, imajući dokument, potpis i javni ključ, svatko može lako provjeriti je li ovaj dokument potpisan ovim posebnim privatnim ključem. Da bismo to učinili, ponovno dobivamo hash dokumenta, dešifriramo potpis javnim ključem i uspoređujemo. Trebali bi dobiti dva identična brojčana niza.

Sve je to super, ali do sada smo dobili nepobijanje potpisa za privatni ključ, odnosno dokazali da je dokument potpisan određenim ključem. Moramo dokazati da ga je potpisala određena osoba. Da biste to učinili, postoje certifikacijski centri i digitalni certifikati. Najvažnija stvar koju certifikacijsko tijelo radi jest da potvrđuje da privatni ključ pripada određenoj osobi. Kako bi se to zajamčilo, certifikacijski centar generira parove ključeva i osobno ih izdaje vlasnicima (postoje opcije putem proxyja, daljinski, ali to su detalji). Zajedno s ključevima generira se digitalni certifikat - to je elektronički dokument (ponekad njegov papirnati prikaz), koji sadrži podatke o vlasniku ključa, samom ključu, tijelu za izdavanje certifikata i neke druge podatke. Vlasnik, u pravilu, sve te dobrote prima na sigurnom mediju (smart card, ru-token i tako dalje), koji sadrži privatni ključ i certifikat s ugrađenim javnim ključem. Sam prijevoznik uvijek morate imati kod sebe, a certifikat javnog ključa koji je kopiran s njega možete dati svima kako bi mogli provjeriti vaš elektronički potpis.

Dakle, potpisivanje se vrši privatnim ključem, a provjera potpisa javnim ključem. Stoga je izraz "dokument potpisan skupom OID-ova" (zvučan u gornjem sporu) besmislen. U postupku potpisivanja i provjere uključena su samo dva ključa, a u 63-FZ su imenovani u skladu s tim - ključ za potpis i ključ za provjeru potpisa.

A koji su to zloglasni OID-i? Format digitalnog certifikata X.509 omogućuje pohranjivanje ekstenzija u njega. Ovo su neki izborni atributi koji se mogu koristiti za pohranjivanje dodatnih informacija. Svaki takav atribut je objekt koji je specificiran identifikatorom iz hijerarhijskog direktorija. Stoga OID - identifikator objekta. Nema smisla ulaziti u prirodu samih OID-a. Zapravo, ovo su neke dodatne informacije koje mogu biti prisutne u certifikatu.

Ovi dodatni atributi mogu se koristiti u različite svrhe. Oni mogu pružiti dodatne informacije o vlasniku, ključevima, CA-u ili sadržavati neke dodatne informacije za aplikacije i usluge koje koriste ovaj certifikat. Najčešća upotreba je za kontrolu pristupa na temelju uloga. Na primjer, u certifikatu se može navesti da je vlasnik ključa čelnik organizacije, a to će mu dati priliku da odmah pristupi potrebnim funkcijama i informacijama u svim IS-ovima, bez potrebe da kontaktira administratore svakog od njih. IS i promijeniti postavke pristupa. Sve to, naravno, pod uvjetom da svi ti IS-ovi koriste korisnički certifikat za autorizaciju i na isti način analiziraju isti atribut (zbog toga se atributi biraju iz imenika, a ne postavljaju proizvoljno).

Zbog različitih prijava dobivamo dva certifikata koji su potpuno različite prirode. Jedan - potvrđuje da sam ja, a to je uvijek tako. Za dobro, može se izdati jednom ili više puta u životu, poput putovnice. Međutim, zbog nesavršenosti postojećih kriptografskih algoritama, iz sigurnosnih razloga, te je potvrde sada potrebno ponovno izdavati svake godine. Druga vrsta certifikata upravlja dodatnim informacijama i može se mijenjati mnogo češće nego jednom godišnje. Može se usporediti sa posjetnica. promijenjena pozicija, E-mail, telefon - trebate izraditi nove posjetnice.

U svijetu se ove dvije vrste certifikata nazivaju, odnosno Potvrda javnog ključa (PKC) i Certifikat atributa (ili Potvrda autorizacije - AC). Certifikat druge vrste može se izdavati puno češće nego prvi, od strane druge organizacije, a trebao bi biti pristupačniji i lakši za dobivanje od osobnog certifikata "javnog ključa". U svakom slučaju, to je ono što preporučuje RFC 3281, posvećen ovoj vrsti certifikata. Certifikat druge vrste trebao bi sadržavati samo vezu na certifikat javnog ključa kako bi sustav koji ga koristi za autorizaciju korisnika mogao prvo identificirati osobu koja koristi PKC.

Sada se približimo našoj stvarnosti. Na zakonodavnoj razini rješavaju se pitanja vezana uz korištenje elektroničkih potpisa u Ruska Federacija, regulirana su dvama glavnim dokumentima - Zakonom Ruske Federacije od 06.04.2011. br. 63-FZ "O elektroničkom potpisu" i Naredbom Federalne službe sigurnosti Ruske Federacije od 27.12.2011. 795 "O odobravanju uvjeta za obrazac kvalificirane potvrde ključa za provjeru elektroničkog potpisa". Sastav kvalificirane potvrde opisan je u 795. redu (II. dio "Zahtjevi za skup polja kvalificirane potvrde") i ne sadrži zahtjeve za atribute koji kontroliraju autorizaciju u bilo kojem informacijskom sustavu. Kao dodatni obvezni atributi navedeni su samo podaci koji vam omogućuju identifikaciju fizičke ili pravne osobe u Ruskoj Federaciji (TIN, SNILS, itd.). Iako ni zakon ni nalog FSB-a ne zabranjuju uključivanje drugih podataka u kvalificirani certifikat.

Kao što možete vidjeti, nikakve zakonodavne norme ne nalažu obveznu prisutnost u kvalificiranom certifikatu atributa povezanih s autorizacijom u bilo kojem informacijskom sustavu. Odakle dolaze ti zahtjevi? I dolaze od programera (ili "vlasnika") specifični sustavi. Uzmimo za primjer "Smjernice za korištenje elektroničkog potpisa u međuresornoj elektroničkoj interakciji (verzija 4.3)", objavljene na tehnološkom portalu SMEV. Doista, u stavku 6. ovog dokumenta čitamo: „Prilikom pripreme informacija za formiranje potvrde EP-SP, potrebno je utvrditi potrebu za traženjem informacija od Rosreestra (izvadak iz USRR). Ako je takav zahtjev neophodan, OID mora biti naveden u polju "Poboljšani ključ" (OID=2.5.29.37) u ES-SP certifikatu prema zahtjevima Rosreestr.". Odnosno, informacijski sustav Rosreestr koristi ovaj atribut za određivanje informacija koje se mogu izdati vlasniku certifikata. Međutim, isti dokument sadrži važnu napomenu, naime, ovaj zahtjev vrijedi do potpunog pokretanja ESIA (jedinstvene usluge autorizacije u državnim sustavima) i povezivanja sustava Rosreestr na njega. Ovo je važna napomena, imajte je na umu.

Neću se baviti drugim IP-ovima koji se koriste u državi. organima. Pretpostavljam da je situacija slična. Portal javne nabave, platforme za elektroničko trgovanje, razne računovodstvene i financijske aplikacije također mogu zahtijevati prisutnost određenih dodatnih OID-ova u korisničkom certifikatu. Pritom je netočna tvrdnja da upisivanjem OID-a informacijskog sustava u certifikat nekako delegiram odgovornost na certifikacijski centar, blago rečeno. CA unosi te podatke u certifikat prema mojoj prijavi. Ako se moj položaj promijenio, a zaboravio sam podnijeti zahtjev za opoziv stare i izdavanje nove potvrde, CA ne može biti odgovoran za moj zaborav. Osim toga, zakon 63-FZ izravno dodjeljuje odgovornost za netočnu upotrebu certifikata njegovom vlasniku. U stavku 6. članka 17. čitamo:
Nositelj kvalificiranog certifikata mora:
1) ne koristiti ključ za elektronički potpis i odmah se obratiti akreditiranom certifikacijskom centru koji je izdao kvalificirani certifikat radi ukidanja ovog certifikata ako postoji razlog za vjerovanje da je povjerljivost ključa elektroničkog potpisa povrijeđena;
2) koristiti kvalificirani elektronički potpis u skladu s ograničenjima sadržanim u kvalificiranom certifikatu (ako su takva ograničenja utvrđena).

Potreba za pohranjivanjem informacija o ulogama i pristupima korisnika u određenim informacijskim sustavima u certifikatu dovodi do problema koji je izazvao spor na Facebooku, naime, certifikat se mora reizdati puno češće od sigurnosnih zahtjeva za osobni elektronički potpis diktira. Pozicija se promijenila - ponovno izdajemo certifikat. Pojavio se novi IS - ponovno izdajemo certifikat. Bilo je potrebno zatražiti informacije od IS-a nove organizacije (Rosreestr) - ponovno izdajemo certifikat.

Postoji 100% pogodak u konceptu koji se zove svjetski Attribute Certificate (ili Authorization Certificate), koji je gore spomenut i u kojem se preporučuje izdavanje ovih certifikata od strane drugog certifikacijskog tijela (Attribute Autority, za razliku od Certificate Authority - redoviti CA koji izdaje kvalificirane ES certifikate) i to na pojednostavljen način. Sam certifikat ne bi trebao sadržavati ključ elektroničkog potpisa i podatke o vlasniku. Umjesto toga, sadrži poveznicu na vlasnički certifikat javnog ključa iz kojeg možete dobiti ostale potrebne informacije o osobi.

Treba napomenuti da ova shema također ima vrlo ograničenu primjenu i ne rješava sve probleme. Što ako sljedeći informacijski sustav odluči koristiti isto polje certifikata "Poboljšani ključ" (OID=2.5.29.37), koje je već zauzeto vrijednosti Rosreestr, za svoje potrebe? Unos dvije različite vrijednosti u jedno polje neće raditi. Stoga ćemo morati izdati još jedan AC! Drugi problem je vezan za kratki vijek trajanja PKC-a (jedna godina). Ako imamo nekoliko AC-ova (koji sadrže poveznicu na osobni certifikat), svi će se morati ponovno izdati nakon isteka PKC-a. Za učinkovito korištenje AC-a potreban je jedan centar za autorizaciju korisnika u svim informacijskim sustavima, a sve aplikacije moraju koristiti atribute certifikata na dosljedan i ujednačen način.

Takav jedinstveni autorizacijski centar za državu. vlasti već postoje - ovo je ESIA. Podsjetimo napomenu o Rosreestrovim OID-ovima. U budućnosti će ih zamijeniti informacije iz ESIA-e. To bi trebali učiniti i drugi informacijski sustavi u kojima rade državni službenici. Umjesto korištenja AC-a za autorizaciju, potrebno je integrirati se s ESIA-om i odatle primati potrebne informacije ESIA bi trebala biti u mogućnosti vezati kvalificirani ES certifikat na račun, tako da će informacijski sustavi moći autentificirati korisnika pomoću osobnog ključa i ovlastiti ga (pružajući pristup aplikaciji) putem ESIA-e. Čini se da je takav sustav univerzalniji i pouzdaniji od korištenja polja certifikata, a u budućnosti će automatizirati upravljanje pristupom. Ako se stvori jedinstveni sustav kadrovske evidencije državnih službenika, ESIA će moći uzimati informacije o ovlasti osobe izravno odatle. Osoba premještena na drugu poziciju - automatski je izgubila pristup jednom sustavu i dobila drugi. nastavlja koristiti svoj ES ključ za potpisivanje dokumenata, ništa ne treba ponovno izdavati.

U skladu s Tehničkim uvjetima za CJSC AEI PRIME za otkrivanje informacija o vrijednosnim papirima i drugim financijskim instrumentima koje je odobrila Banka Rusije (), elektronički dokumenti koji sadrže javne informacije mora biti potpisan od strane subjekta objavljivanja podataka pojačanim kvalificiranim elektroničkim potpisom (vidi točku 1.7. Tehničkih uvjeta). Ovaj uvjet je na snazi od 1. veljače 2017.

Trenutno je počelo probno razdoblje za primjenu elektroničkog potpisa na PRIME serveru za otkrivanje podataka koje će trajati do zaključno 31. siječnja 2017. godine.

Za testiranje funkcionalnosti korisnici PRIME-a mogu koristiti bilo koji certifikat ES ključa prethodno primljen za ovu pravnu osobu.

Od 1. veljače 2017. godine, na zahtjev Tehničkih uvjeta (vidi točke 1.7. i 9.6.), kvalificirani certifikat ključa za provjeru elektroničkog potpisa korisnika mora ispunjavati uvjete za oblik kvalificirane potvrde utvrđene Naredbom Federalna služba sigurnosti Rusije od 27. prosinca 2011. br. 795 „O zahtjevima za odobrenje obrasca kvalificirane potvrde ključa za provjeru elektroničkog potpisa. Poboljšano proširenje korisničkog certifikata ključa ( identifikator objekta 2.5.29.37) mora sadržavati identifikator objekta otkrivanja PRIME - OID 1.2.643.6.42.5.5.5

Prijava na osobni račun korisnika otkrivanja informacija "PRIME" izvršit će se korištenjem LOGIN-a i LOZINKE koje je klijent prethodno primio.

Klijentove radnje za objavljivanje poruka u feedu za otkrivanje informacija, postavljanje dokumenata na stranicu na Internetu, unošenje izmjena na registracijskoj kartici izdavatelja u sustavu za otkrivanje informacija moraju biti potvrđene elektroničkim potpisom.

Za korištenje ES-a na PRIME poslužitelju za otkrivanje informacija, klijent prvo mora instalirati dodatak (instalacija je besplatna za korisnike i ne oduzima puno vremena). Pogledajte upute za instalaciju dodatka u nastavku.

Na osobnom računu korisnika za otkrivanje podataka, nakon što klijent instalira dodatak, prilikom ispunjavanja obrazaca za objavu poruke u feedu za otkrivanje podataka ili postavljanja dokumenta na Internet, kao i prilikom promjene podataka registracijske kartice, Pojavit će se dodatna polja “Elektronski potpis dokumenta” gdje će biti potrebno odabrati ono koje se prikazuje u odgovarajućem servisnom polju certifikat ključa za potpisivanje i kliknuti gumb “Potpiši”. Na taj način klijent će potvrditi svoje radnje za otkrivanje podataka ili izmjene svoje registracijske kartice.

Nakon potpisivanja poruke elektroničkim potpisom, klijent mora kliknuti gumb "Objavi".
Nakon potpisivanja dokumenta elektroničkim potpisom, klijent mora kliknuti gumb "Dodaj dokument".
Nakon potpisivanja promjena u registracijskoj kartici elektroničkim potpisom, klijent mora kliknuti na gumb "Pošalji identifikacijski obrazac".

Napominjemo da će sve poruke koje klijenti šalju putem svog osobnog računa putem autorizacije "Probna prijava (rad s ES)" biti objavljene u feedu za otkrivanje informacija u radnom načinu. Svi dokumenti koje klijenti postavljaju putem osobnog računa putem autorizacije "Probni unos (rad s ES)" automatski će biti objavljeni na stranicama izdavatelja u radnom načinu.

Inače, postupak izdavateljevih radnji na osobnom računu na PRIME poslužitelju za otkrivanje informacija se ne mijenja.