Sporovi sa susjedima 

Lissy soft root certifikat. Wiki odjeljci

Zahtjevi sustava

  • pristup internetu
  • Operativni sustav: Windows 8, 7, XP SP 3/2
  • Procesor: 1,6 GHz ili više
  • RAM: 512 MB
  • Dostupnost jednog od podržanih kripto pružatelja usluga: CryptoPro CSP 3.6 ili noviji, LISSI CSP, VIPNet CSP, Signal-COM CSP
  • Rezolucija zaslona: najmanje 800x600 px

Koristite certificiranog davatelja kriptovaluta

Za rad programa Ekey.Signature obvezna je prisutnost na radnom mjestu alata za zaštitu kriptografskih podataka (CIPF) koji šifrira dokumente u skladu s GOST algoritmima. Kao CIPF mogu se koristiti CryptoPro CSP sustavi ne niži od 3.6, LISSI CSP, VIPNet CSP, Signal-COM CSP.

Alati za zaštitu kriptografskih podataka kompatibilni su s Ekey.Signature, ali su međusobno nekompatibilni. Na jednom radnom mjestu može se instalirati samo jedan CIPF.

Koristite antivirusni program

Instalirajte popularni antivirusni program na svoje radno mjesto i redovito ga ažurirajte. Antivirusni program štiti od virusa, špijunskog softvera i sam eliminira većinu sigurnosnih prijetnji.

Zaštitite pristup svom elektroničkom potpisu i radnom mjestu lozinkom

Korištenjem Ekey.Signature i alata za kriptografsku zaštitu zaštitite svoje računalo od fizičkog pristupa nepoznatih osoba. Koristite pristup lozinkom.

Pristupiti Elektronički potpis, koristite složenu lozinku. Dobra lozinka je zajamčena sigurnost vaših podataka. Dobar način za pamćenje lozinke je stalno unošenje lozinke prilikom izvođenja operacija elektroničkog potpisa.

Sjajno mjesto za pohranu lozinke je vaša memorija. Nije preporučljivo nigdje zapisivati ​​lozinku. Nemojte spremati lozinku pored fizičkog nosača elektroničkog potpisa, nemojte pohranjivati ​​lozinku u sustav.

Koristite samo licencirane i ažurirane programe

Programi instalirani na vašem radnom mjestu povremeno se ažuriraju kako bi se poboljšala stabilnost i sigurnost vašeg rada.

Instalirajte ažuriranja softvera samo sa službenih stranica, prije instaliranja provjerite adrese web-mjesta i informacije o izdavaču programa.

Ekey instalacija.Potpis

1. Preuzmite

2. Za početak instaliranja programa pokrenite instalacijsku datoteku. Ako je UAC pokrenut, morate dopustiti promjene programa Ekey Transfer.

Priprema datoteka za Rosreestr

1. Odaberite vrstu operacije "Rosreestr" u glavnom prozoru programa ili u kontekstnom izborniku datoteke.


3. Dodajte izvješće pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku pomoću miša.
4. Kliknite gumb Generiraj.
6. Nakon dovršetka operacije, datoteka potpisa bit će spremljena u isti direktorij kao izvorna datoteka, odvojena datoteka potpisa je važeća samo ako je izvorna datoteka prisutna.

Priprema kontejnera za FFMS Rusije, Službu Banke Rusije, Središnje banke

1. Odaberite vrstu operacije "FFMS Rusije".

2. Odaberite osobni certifikat.

3. Dodajte izvješće s nastavkom xtdd ili smcl pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku mišem.

5. Ako je potrebno, unesite lozinku za spremnik privatnog ključa

7. Za dodavanje potpisa priložite prethodno generirani spremnik, odaberite potrebni certifikat i kliknite gumb Generiraj.

8. Za slanje izvješća na portal Službe Banke Rusije (FFMS), kliknite gumb dodaj, u izborniku koji se pojavi odaberite traženi spremnik s izvješćem i kliknite gumb Prenesi na portal.

FSIS TP Ministarstvo regionalnog razvoja Rusije

1. Odaberite vrstu operacije "FSIS TP".

2. Odaberite osobni certifikat.

3. Dodajte izvješće pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku pomoću miša.

4. Kliknite gumb Generiraj.

5. Ako je potrebno, unesite lozinku za spremnik privatnog ključa

6. U izborniku za spremanje koji se pojavi odaberite mjesto za spremanje rezultata operacije.

Registar Roskomnadzora (zapret-info.gov.ru)

1. Odaberite operaciju Registar Roskomnadzor

2. Odaberite osobni certifikat

3. Da biste saznali vrijeme zadnjeg ažuriranja registra, kliknite "Vrijeme zadnjeg ažuriranja iskrcavanja iz registra"

4. Za slanje zahtjeva kliknite na "pošalji zahtjev"

Ispunite polja kako biste generirali zahtjev.

5. Da biste dobili rezultat obrade zahtjeva, kliknite "Zahtjev za dobivanje rezultata"

Da biste automatski ispraznili registar, morate označiti okvir "Automatski isprazni", postaviti potrebno razdoblje za istovar i navesti imenik za spremanje rezultata iskrcavanja.

ISED

1. Odaberite vrstu operacije "ISED".

2. Dodajte izvješće pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku pomoću miša.

3. Odaberite certifikate primatelja

4. Kliknite gumb Generiraj.

5. U izborniku za spremanje koji se pojavi odaberite mjesto za spremanje rezultata operacije.

Potpis datoteke

1. Odaberite vrstu operacije "Ručno potpisivanje".

2. Odaberite osobni certifikat.

4. Odaberite željene opcije potpisa.

5. Kliknite gumb "Potpiši".

6. Ako je potrebno, unesite lozinku za spremnik privatnog ključa

Objašnjenja:

Spremite potpis u posebnu datoteku

Kada se zastavica postavi, stvorit će se nepovezani elektronički potpis Ako oznaka nije prisutna, potpis će biti dodan na kraj datoteke (u ovom slučaju dokument i elektronički potpis bit će pohranjeni zajedno)

Arhivske datoteke

Trebam li arhivirati datoteke nakon potpisivanja

Produžetak - Zadana ekstenzija datoteke potpisa je sig, također možete odrediti vlastitu ekstenziju

Kodiranje - Odaberite kodiranje koje vam je potrebno Der ili Base-64

Onemogući zaglavlja usluge- Ako je odabrano kodiranje Base-64 (zaglavlja se koriste za kompatibilnost s trećim stranama softver).

Šifriranje datoteke

1. Odaberite vrstu operacije "Ručno šifriranje".

2. Odaberite osobni certifikat.

3. Dodajte datoteku pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku pomoću miša.

4. Odaberite potrebne opcije šifriranja.

5. Dodajte ili odaberite između dostupnih certifikata primatelja (kome će datoteka biti šifrirana)

6. Kliknite gumb "Šifriraj".

7. Ako je potrebno, unesite lozinku za spremnik privatnog ključa

8. U izborniku za spremanje koji se pojavi odaberite mjesto za spremanje rezultata operacije. Objašnjenja:

Kodiranje

Odaberite Der ili Base-64 kodiranje koje vam je potrebno

Produžetak

Ekstenzija koju će konačna datoteka imati (enc prema zadanim postavkama), također možete odrediti vlastitu ekstenziju. Onemogući zaglavlja usluge - ako je odabrano kodiranje Base-64 (potrebno za kompatibilnost sa softverom treće strane).

Arhivirajte datoteke prije šifriranja

Ako trebate arhivirati datoteke prije šifriranja, označite odgovarajući okvir.

Ako dodate više datoteka, sve će datoteke biti upakirane u jednu arhivu.

Dešifriranje datoteke

1. Odaberite vrstu operacije "Dešifriranje".

2. Odaberite osobni certifikat.

3. Dodajte datoteku pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku pomoću miša.

4. Kliknite gumb "Dešifriraj".

5. Ako je potrebno, unesite lozinku za spremnik privatnog ključa

6. U izborniku za spremanje koji se pojavi odaberite mjesto za spremanje rezultata operacije.

Provjera potpisa

1. Za početak provjere potpisa upotrijebite način provjere koji vam odgovara.

  • Dvostrukim klikom na datoteku koja sadrži potpis.
  • Odaberite vrstu operacije "Provjeri potpis" u glavnom izborniku programa.
  • Kroz kontekstni izbornik datoteke koju treba provjeriti.

2. Dodajte datoteku pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku pomoću miša.

3. Kliknite gumb Provjeri.

Nakon klika na gumb "Provjeri", pojavljuje se prozor s rezultatom provjere potpisa. U njemu možete vidjeti stablo potpisa, ispisati rezultat provjere i otvoriti izvornu datoteku za pregled.

Također, tijekom skeniranja možete vidjeti sadržaj datoteka s ekstenzijom: doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif.

Objašnjenja:

Odjavite datoteke

Ako je priloženi potpis stvoren, ova opcija se može koristiti za dobivanje izvorne datoteke koja ne sadrži nikakve potpise.

Dodajte potpis

1. Odaberite vrstu operacije "Dodaj potpis".

2. Odaberite osobni certifikat.

4. Kliknite gumb "Potpiši".

5. Ako je potrebno, unesite lozinku za spremnik privatnog ključa

6. U izborniku za spremanje koji se pojavi odaberite mjesto za spremanje rezultata operacije.

Provjeri potpis

1. Odaberite vrstu operacije "Certify Signature".

2. Odaberite osobni certifikat.

3. Dodajte datoteku potpisa pomoću gumba "Priloži datoteku(e)" ili povucite i ispustite datoteku pomoću miša.

4. Kliknite gumb Potvrdi.

5. Ako je potrebno, unesite lozinku za spremnik privatnog ključa

6. U izborniku koji se pojavi odaberite potpis koji želite ovjeriti

7. U izborniku za spremanje koji se pojavi odaberite mjesto za spremanje rezultata operacije.

Automatsko ažuriranje

Kada ažuriranje postane dostupno, u gornjem desnom kutu pokrenute aplikacije Ekey Signature pojavljuje se odgovarajući natpis. Da biste pokrenuli ažuriranje, kliknite na njega lijevom tipkom miša.

Nakon što je proces ažuriranja dovršen, kliknite "U redu" na poruci da će neke promjene stupiti na snagu tek nakon ponovnog pokretanja. Kliknite gumb "Završi". Nakon toga preporuča se ponovno pokretanje računala. Prije svega je potrebno ponovno podizanje sustava kako bi ažuriranja vezana uz rad kontekstnog izbornika Windowsa stupila na snagu.

Automatska instalacija korijenskih certifikata

Ako u trgovini nema root certifikata, kada se pokrene aplikacija Ekey Signature, u korisničkom dnevniku se prikazuje odgovarajuća pogreška. U tom slučaju trebate potpisati datoteku s "problematičnim" osobnim certifikatom. Prilikom izvođenja operacije potpisivanja, prikazat će se dijaloški okvir u kojem se od vas traži da instalirate korijenski certifikat koji nedostaje. Kliknite Da da biste instalirali korijenski certifikat koji nedostaje.

Certifikacijsko tijelo CAFL63 nastala na temelju . SQLite3 DBMS se koristi za pohranu podataka (zahtjeva, certifikata, postavki itd.). Tijelo za izdavanje certifikata ima grafičko sučelje razvijeno u Tcl/Tk.

CAFL63 CA razvijen je uzimajući u obzir zahtjeve Saveznog zakona od 6. travnja 2011. br. br. 63-FZ "O elektroničkom potpisu", kao i "Zahtjevi za obrazac kvalificirani certifikat ključ za provjeru elektroničkog potpisa”, odobren naredbom Federalne službe sigurnosti Rusije od 27. prosinca 2011. br. 795.

CA uključuje Registracijski centar (CR), koji je odgovoran za primanje zahtjeva za potvrde građana. Danas se certifikati izdaju za pravne osobe, fizičke osobe i pojedinačne poduzetnike. Prijave se primaju u u elektroničkom formatu u formatu PKCS#10, CSR (Zahtjev za potpisivanje certifikata) ili SPKAC. Imajte na umu da je CSR format PKCS#10 PEM kodiran zahtjev sa zaglavljem -----BEGIN REQUEST CERTIFICATE-----.

Zahtjev je popunjeni upitnik, svrhe za koje je potreban certifikat, javni ključ korisnika, overen (potpisan) privatnim ključem korisnika. Nadalje, s paketom dokumenata koji potvrđuju, posebno, identitet podnositelja zahtjeva, te s elektroničkim medijem na kojem je zahtjev pohranjen (naglašavam da je zahtjev, bolje je privatni ključ pohraniti negdje drugdje), građanin dolazi u CR CA.

CR provjerava dokumente, zahtjev (ispunjene podatke, ispravnost elektroničkog potpisa i sl.), a ako je sve prošlo u redu, prihvaćaju zahtjev, odobravaju ga i prosljeđuju u Centar za certifikaciju (CA).

U slučaju da je podnositelj zahtjeva došao bez spremnog zahtjeva, tada on, zajedno sa zaposlenikom CR-a, odlazi u zaseban radno mjesto gdje se priprema zahtjev za potvrdu. Pripremljen zahtjev za elektronički mediji, kao što je već spomenuto, ulazi u CR. Što podnositelj zahtjeva ovdje treba zapamtiti? Prvo i najvažnije: podnositelj zahtjeva mora preuzeti medij s generiranim privatnim ključem!

Odobreni zahtjev na elektroničkom mediju prenosi se u CA, gdje se na temelju njega izdaje potvrda.

Ovo je osnovni dijagram rada UC-a. Detalji će postati jasni u nastavku. Jedna napomena, radi praktičnosti u demonstriranju uslužnog programa za pripremu zahtjeva, CR i CA su kombinirani u jedan demo kompleks. Ali nema problema s odvajanjem funkcionalnosti. Najjednostavnije rješenje je imati kopiju CAFL63 na svakom radnom mjestu i koristiti samo potrebnu funkcionalnost.

Kad je projekt bio u punom jeku, za oko mi je zapeo projekt SimpleCA. Studija ovog projekta bila je od velike pomoći u konačnoj implementaciji CAFL63 CA.

Preuzmite CAFL63 distribuciju za Win32/Win64, Linux_x86/Linux_x86_64 platforme.

Dakle, pokrećemo uslužni program CAFL63 - na ekranu se pojavljuje početna stranica CAFL63:

Počinjemo s radom pritiskom na gumb "Kreiraj DB". Baza podataka CA kreirana je pomoću SQLite3 višeplatformskog DBMS-a. Baza podataka CA sadrži nekoliko tablica. Glavna tablica - mainDB - sadrži samo jedan unos, koji pohranjuje root certifikat, privatni ključ šifriran lozinkom i CA postavke. Dvije su tablice povezane sa zahtjevima za certifikate: reqDB trenutni zahtjevi i reqDBArc arhiva zahtjeva. Za certifikate se kreiraju tri tablice: nova tablica certifikata certDBNew, tablica arhive certifikata CertDB i tablica opoziva certifikata CertDBRev. Sve tablice zahtjeva i certifikata koriste hash vrijednost (sha1) javnog ključa kao primarni ključ. To se pokazalo vrlo zgodnim, na primjer, kada tražite certifikat na zahtjev ili obrnuto. U bazi podataka postoji još jedna crlDB tablica koja pohranjuje popise opozvanih certifikata. I tako, kliknuli smo gumb "Kreiraj DB":

Izrada CA počinje odabirom direktorija u koji ćemo pohraniti bazu podataka i postavljanjem lozinke za pristup privatnom ključu CA. Pritiskom na tipku "Dalje" idemo na stranicu za odabir vrste i parametara para ključeva za CA:

Nakon što smo se odlučili za par ključeva za korijenski certifikat tijela za izdavanje certifikata koji se kreira, nastavljamo ispunjavati obrazac s podacima o vlasniku (prvu snimku zaslona smo preskočili):

Imajte na umu da uslužni program CAFL63 ima određenu "inteligenciju" i stoga kontrolira ne samo prisutnost podataka u poljima, već i ispravnost (crveno istaknuto - netočno) popunjavanja polja kao što su TIN, OGRN, SNILS, OGRNIP, adresa E-mail i tako dalje.

Nakon što ispunite polja s podacima o vlasniku CA, od vas će se tražiti da odlučite o sistemskim postavkama CA:

Ako ne namjeravate raditi s ruskom kriptografijom, onda možete koristiti uobičajeni OpenSSL. Za rad s ruskom kriptografijom morate navesti odgovarajuću verziju, modifikaciju OpenSSL-a. Pročitajte README.txt u preuzetoj distribuciji za više pojedinosti. Također, u skladu s FZ-63, predlaže se postavljanje informacija o certifikaciji samog CA i CIPF-u koji on koristi.

Nakon što ispravno popunite sva polja, od vas će se još jednom tražiti da provjerite njihovu valjanost i kliknete gumb "Završi":

Nakon klika na gumb "Završi" kreirat će se CA baza podataka u koju će se pohraniti: korijenski certifikat CA, privatni ključ, postavke sustava. I početna stranica uslužnog programa CAFL63 ponovno će se pojaviti na zaslonu. Sada kada smo kreirali bazu podataka novostvorenog CA, pritisnemo gumb "Otvori DB", izaberemo direktorij s bazom podataka i uđemo u glavni radni prozor CA:

Klikom na gumb "Prikaži CA CA" uvjeravamo se da je ovo naš korijenski certifikat.

Sljedeći korak je priprema predložaka/profila prijava za pravne osobe, fizičke osobe i pojedinačne poduzetnike ( Alati->Postavke->Vrste certifikata->Novo ):

Nakon postavljanja naziva novog profila, od vas će se tražiti da definirate njegov sastav:

Nakon pripreme profila, CA je spreman za primanje podnositelja zahtjeva i prijava od njih. Kao što je gore navedeno, podnositelj zahtjeva može doći sa ili bez ispunjenog zahtjeva za potvrdu.

Ako je podnositelj zahtjeva došao s popunjenom prijavom, tada se nakon provjere njegovih dokumenata prijava uvozi u bazu podataka CA. Da biste to učinili, u glavnom radnom prozoru odaberite karticu "Zahtjevi za certifikate", kliknite gumb "Zahtjev za uvoz / CSR" i odaberite datoteku sa zahtjevom. Nakon toga će se pojaviti prozor s informacijama o zahtjevu:

Nakon što pregledate zahtjev i uvjerite se da je ispravno popunjen, možete kliknuti gumb "Uvezi" kako biste ga unijeli u bazu podataka. Odmah napominjemo da će se, kada pokušate ponovno unijeti zahtjev u bazu podataka CA, prikazati poruka:

Zahtjevi u bazi podataka CA označeni su (stupac „Vrsta“) ili kao „Locale“, kreiran od strane CA, ili kao „Uvoz“, koji je kreirao sam podnositelj zahtjeva, a vrijeme prijema zahtjeva od strane CA je također zabilježeno. To može biti korisno u rješavanju konfliktnih situacija.

Ako je podnositelj zahtjeva došao bez prijave i traži da je izradi, tada je prije svega potrebno odlučiti ( Postavke->Vrste certifikata->Pojedinačno->Uredi ) s tipom para ključeva ( ->Par ključeva ), za koju svrhu ( ->Korištenje ključa ) potrebna potvrda:

Par ključeva može se stvoriti pomoću CIPF-a "LIRSSL-CSP" (gumb OpenSSL) i spremiti u datoteku ili na PKCS#11 tokenu (gumb PKCS#11). U potonjem slučaju, također morate navesti biblioteku za pristup tokenu (na primjer, rtpkcs11ecp za RuToken ECP token ili ls11cloud za ).

Nakon što ste se odlučili za profil i kliknuli gumb "Dalje", daljnji postupak se ne razlikuje puno od izdavanja root certifikata. Jedna važna napomena: zapamtite gdje pohranjujete privatni ključ i lozinku za pristup ključu. Ako se PKCS#11 token/pametna kartica koristi kao CIPF za generiranje para ključeva, tada mora biti spojen na računalo:

Stvorena ili uvezena aplikacija nalazi se u CA bazi podataka i prikazuje se u glavnom prozoru na kartici “Zahtjevi za certifikate”. Primljeni zahtjevi su pod "razmatranjem" (stupac "Status" na karticama "Zahtjevi za certifikate" i "Arhiva zahtjeva"). Za svaki novoprimljeni zahtjev mora se donijeti odluka (kontekstni izbornik kada desnom tipkom miša kliknete odabrani zahtjev):

Svaki zahtjev se može odbiti ili odobriti:


Ako je zahtjev odbijen, on se premješta iz tablice trenutnog zahtjeva reqDB u tablicu arhive zahtjeva reqDBArc i, sukladno tome, nestaje s kartice Zahtjevi za certifikate i ponovno se pojavljuje na kartici Arhiva zahtjeva.

Odobrena aplikacija ostaje u tablici reqDB i na kartici "Zahtjevi za certifikate" do izdavanja certifikata, a zatim također ulazi u arhivu.

Postupak izdavanja potvrde, stavka izbornika "Izdavanje potvrde") malo se razlikuje od postupka izrade aplikacije:

Izdana potvrda odmah se pojavljuje na kartici "Certifikati". U tom slučaju, sam certifikat ulazi u tablicu certDBNew CA baze podataka i ostaje tamo dok se ne objavi. Certifikat se smatra objavljenim nakon što je izvezen u SQL dump novih certifikata, koji se prenosi na javni servis. Objavljivanje certifikata premješta ga iz tablice certDBNew u tablicu certDB.

Ako pritisnete desnu tipku miša na odabranoj liniji na kartici "Certifikati", pojavit će se izbornik sa sljedećim funkcijama:

Ako je zahtjev kreiran u CA s ključem generiranim i spremljenim u datoteci, tada morate stvoriti PKCS # 12 spremnik i poslati ga podnositelju zahtjeva:

Obratite pažnju na "prijateljsko ime" - navodnici u njemu moraju biti pobjegnuti:

Nakon kreiranja sigurnog spremnika PKCS#12, datoteka privatnog ključa podnositelja zahtjeva se uništava.

Dakle, CA je započeo svoj život, izdao prvi certifikat. Jedan od zadataka CA je organiziranje slobodnog pristupa izdanim certifikatima. Objava certifikata u pravilu ide putem web servisa. CAFL63 također ima takvu uslugu:

Za objavljivanje certifikata i popisa opozvanih certifikata na javnoj usluzi, CA ili preliminarno učitava certifikate u datoteke (Certificates->Export Certificates) ili pravi SQL dump cijele tablice certifikata iz koje možete kreirati bazu podataka certifikata i u njega učitati popis certifikata, te nakon toga napraviti SQL dump novih certifikata iz kojeg će biti dodani u bazu podataka javnih usluga:

Temeljna funkcija CA-a je objava popisa opozvanih potvrda, slično kao što Ministarstvo unutarnjih poslova radi s putovnicama s isteklim rokom valjanosti. Certifikat se može opozvati na zahtjev vlasnika. Glavni razlog za opoziv je gubitak privatnog ključa ili gubitak povjerenja u njega.

Da biste opozvali certifikat, samo ga odaberite na kartici "Certifikati", kliknite desnom tipkom miša i odaberite stavku izbornika "Opoziv certifikata":

Postupak opoziva je isti kao i kod kreiranja zahtjeva ili izdavanja potvrde. Opozvana potvrda ulazi u tablicu cerDBRev CA baze podataka i pojavljuje se na kartici Opozvani certifikati.

Ostaje razmotriti posljednju funkciju CA - izdavanje CRL - popis opozvanih certifikata. CRL popis se generira na kartici "Opozvane potvrde" klikom na gumb "Stvori COS/CRL". Sve što je ovdje potrebno od administratora je da unese lozinku CA i potvrdi svoju namjeru izdavanja CRL-a:

Izdani CRL ide u crlDB tablicu baze podataka i prikazuje se na kartici CRL/COS. Za pregled CRL-a ili izvoz u svrhu objave na javnom servisu morate, kao i uvijek, odabrati željeni redak, pritisnuti desnu tipku miša i odabrati stavku izbornika:

Preuzmite CAFL63 distribuciju za platforme Win32/Win64, Linux_x86/Linux_x86_64 . Štoviše, sve to uspješno radi na Android platformi.

Čitatelji se pozivaju na istraživački rad, tijekom kojeg se identificiraju brojni problemi s korištenjem alata za digitalni potpis koji se javljaju kod Linux korisnika. Konkretno, otkrivene su sljedeće ne sasvim očite točke:

  • mogućnost dobivanja i korištenja certifikata osobnog digitalnog potpisa za pristup javnim uslugama trenutno pružaju samo uz naknadu komercijalne organizacije;
  • nositelji podataka elektroničkog potpisa koje krajnjim korisnicima izdaju različite ovlaštene organizacije mogu biti nekompatibilni međusobno i s portalima koji pružaju pristup uslugama, uključujući javne;
  • razina sigurnosti nositelja podataka elektroničkog potpisa, koji se masovno izdaju krajnjim korisnicima, u pravilu je značajno smanjena u odnosu na tehnološku razinu koja je danas dostupna;
  • za većinu korisnika OS-a iz Registra domaćeg softvera EDS mehanizmi na Jedinstvenom portalu javnih usluga nisu dostupni zbog nekompatibilnosti softvera EPGU i softvera ovlaštenih organizacija koje izdaju certifikate osobnog elektroničkog potpisa;
  • u nekim slučajevima programeri portala koji pružaju javne usluge preporučuju korištenje operativnih sustava koji nisu uključeni u Registar, kao i softverskih alata i konfiguracija koje svjesno smanjuju sigurnost korisničkih podataka.

Autori rada očekuju da će dobiveni rezultati biti korisni korisnicima rješenja koja koriste EDS mehanizme, integratorima koji implementiraju odgovarajuća rješenja, te da će ih uzeti u obzir i organizacije odgovorne za pružanje usluga javnog informiranja i implementaciju specifične mehanizme EDS infrastrukture, kao i programere odgovarajućeg softvera i hardvera.

O čemu se radi

Članak je posvećen podršci elektroničkog digitalnog potpisa (EDS) dokumenata u ALT OS-u, kao i specifičnostima korištenja EDS-a u Ruskoj Federaciji.

Glavni zadatak je razumjeti što "običan korisnik"™ treba učiniti - bez obzira radi li se o fizičkoj ili pravnoj osobi - djelujući na zajedničkoj osnovi, kako bi u potpunosti iskoristio mogućnosti elektroničkih trgovačkih platformi i portala javnih usluga dok rad u OS-u iz Registra domaćeg softvera. “Puno korištenje” znači, prije svega, mogućnost autentifikacije na odgovarajućoj stranici korištenjem certifikata postavljenog na poseban fizički medij, te mogućnost elektroničkog potpisivanja dokumenata generiranih u sučelju stranice.

Na ovu temu već su provedeni brojni istraživački radovi čiji je rezultat bio zaključak da u principu sve funkcionira. Ovdje je važno razumjeti da je većina studija kompatibilnosti s portalima javnih usluga Ruske Federacije modernih kriptografskih alata koji rade pod Linux OS-om provedena u laboratorijskim uvjetima. Na primjer, ako postoje posebni sporazumi između istraživača i certifikacijskog tijela koje izdaje certifikat. Nažalost, na temelju rezultata takvog rada teško je suditi o stvarnim sposobnostima osoba koje djeluju na zajedničkim osnovama.

Kako sve funkcionira

Da biste ušli na stranicu bez unosa prijave i lozinke, već jednostavno spajanjem hardverskog tokena na USB konektor, potrebno je da specijalizirani softverski stog ispravno radi u operativnom sustavu: podrška za fizičke uređaje, kriptografske algoritme, softverska sučelja , formate i komunikacijske protokole. Istodobno, kompatibilnost kriptografskih algoritama, formata i protokola mora se osigurati i izvan područja odgovornosti OS-a - u certifikacijskom tijelu koje izdaje certifikat i na stranici kojoj se mora omogućiti pristup.

A ako je riječ o web stranicama državnih agencija, također je potrebno da korištene kriptovalute budu certificirane za odgovarajuću upotrebu u Ruska Federacija.

Osnovni mehanizmi

EDS tehnologija, službeno korištena u Ruskoj Federaciji, temelji se na infrastrukturi javnih ključeva. Pogledajmo kako to funkcionira na primjeru.

Radi jasnoće, razmotrimo mehanizam djelovanja univerzalnih algoritama prikladnih i za elektronički potpis i za šifriranje. Takvi algoritmi, između ostalog, uključuju RSA Internet standard i ruski GOST R 34.10-94, koji je bio na snazi ​​u Ruskoj Federaciji kao standard elektroničkog potpisa do 2001. godine. Suvremeniji EDS algoritmi, koji uključuju, između ostalog, trenutni GOST R 34.10-2001 i GOST R 34.10-2012, u pravilu su specijalizirani. Namijenjeni su isključivo za potpisivanje dokumenata, a nisu prikladni za enkripciju. Tehnički, razlika između specijaliziranih algoritama je u tome što hash u njihovom slučaju nije šifriran. Umjesto šifriranja, na njemu se izvode i drugi izračuni pomoću privatnog ključa, čiji se rezultat pohranjuje kao potpis. Prilikom provjere potpisa, odgovarajući komplementarni izračuni se izvode pomoću javnog ključa. Gubitak univerzalnosti u ovom slučaju je plaćanje za veću kriptografsku snagu. Donji primjer s univerzalnim algoritmom je možda malo manje relevantan, ali vjerojatno razumljiviji nespremnom čitatelju.

Potpis dokumenta

Dakle, za formiranje elektroničkog potpisa u infrastrukturi javnog ključa koristi se asimetrična shema šifriranja, koju karakterizira korištenje para ključeva. Ono što je šifrirano jednim od ovih ključeva može se dešifrirati samo drugim ključem para. Jedan od ključeva para naziva se tajnim, odnosno privatnim, i čuva se što je više moguće tajno, drugi se naziva javnim, odnosno otvorenim, i slobodno se distribuira – u pravilu, kao dio certifikata. Certifikat elektroničkog potpisa osim ključa uključuje podatke o vlasniku certifikata, kao i potpis ključa, zajedno s podacima o vlasniku koje je izradila neka provjerena strana. Dakle, certifikat već sadrži elektronički potpis koji potvrđuje da podaci o vlasniku odgovaraju njegovom paru ključeva.

Organizacijski, ovaj potpis obavlja certifikacijsko tijelo (CA) - pravna osoba kojoj je delegirano ovlast utvrđivanja i potvrđivanja korespondencije vlasnika i ključa. Usklađenost se utvrđuje nakon predočenja papirnatih dokumenata, a potvrđuje se upravo elektroničkim potpisom, što je zgodno razmotriti samo na primjeru izrade certifikata.

Tijelo za certificiranje za potpisivanje klijentskih certifikata također ima par ključeva. Potvrđene informacije o vlasniku certifikata u obliku posebno dizajnirane tablice objedinjuju se u jedan dokument sa svojim javnim ključem. Ovaj dokument tada prolazi kroz dvije transformacije. Prvo, hash funkcija pretvara dokument u jedinstveni niz znakova fiksne duljine (hash). Zatim se rezultirajući hash šifrira privatnim ključem certifikacijskog tijela. Rezultat enkripcije je stvarni elektronički potpis. Prilaže se potpisanom dokumentu, u ovom slučaju podaci o korisniku i njegovom ključu, te se zajedno s njim distribuira. Sve to zajedno – dokument s podacima o korisniku i njegovom javnom ključu, kao i potpisom ovog dokumenta s javnim ključem CA, sastavlja se na poseban način i naziva se korisnički certifikat.

Kao iu slučaju korisničkih podataka kao dijela certifikata, izdaje se elektronički potpis bilo kojeg drugog dokumenta. Na primjer, datoteka s aplikacijom za uslugu. Datoteka se raspršuje, rezultirajući hash šifrira se tajnim ključem korisnika i prilaže dokumentu. Rezultat je potpisani dokument.

Provjera potpisa

Kao što je obično slučaj s asimetričnom enkripcijom, ono što je šifrirano jednim ključem može se dešifrirati samo drugim ključem para. Dakle, u slučaju certifikata, šifrirani hash dokumenta koji sadrži korisnikov javni ključ i provjerene podatke o korisniku može se dešifrirati pomoću javnog ključa certifikacijskog tijela koji se slobodno distribuira kao dio certifikata certifikacijskog tijela. Dakle, svatko tko dobije CA certifikat moći će dobiti dešifrirani hash iz korisničkog certifikata. Budući da hash funkcija daje jedinstven rezultat, primjenom na dokument koji sadrži korisnikov javni ključ i informacije o njemu, možete provjeriti podudaraju li se ova dva hasha. Ako jesu, onda imamo isti dokument koji je potpisao certifikacijski centar, a informacijama sadržanim u njemu može se vjerovati. Ako ne, onda potpis ne odgovara dokumentu i imamo lažni.

Situacija s provjerom CA certifikata je potpuno ista - on je također potpisan nekim ključem. Kao rezultat toga, lanac potpisanih certifikata završava s "korijenskim" certifikatom, koji je samopotpisan. Takav certifikat naziva se samopotpisani. Za službeno akreditirane certifikacijske centre Ruske Federacije, korijenski certifikat je certifikat Glavnog centra za certifikaciju Ministarstva telekomunikacija i masovnih komunikacija.

Osim informacija o korisniku i njegovom javnom ključu, certifikat sadrži i neke dodatne podatke – posebice razdoblje valjanosti certifikata. Ako je barem jedan certifikat u lancu istekao, potpis se smatra nevažećim.

Također, potpis će se smatrati nevažećim ako CA opozove certifikat klijenta. Mogućnost opoziva certifikata korisna je, na primjer, u situacijama kada je tajni ključ procurio. Prikladna je analogija s kontaktiranjem banke u slučaju gubitka bankovne kartice.

Usluge certifikacijskih centara

Dakle, certifikacijski centar svojim potpisom potvrđuje korespondenciju određenog javnog ključa s određenim skupom zapisa. Teoretski, troškovi CA za potpisivanje jednog certifikata su blizu nuli: sam potpis je dobro automatizirana, ne baš skupa računska operacija na modernoj opremi. Istovremeno se usluge UC-a plaćaju. No, za razliku od CA-ova koji izdaju certifikate za web-stranice, ovdje se novac ne stvara iz ničega.

Prva komponenta troška certifikata su režijski troškovi za servisiranje akreditiranog CA. To uključuje: trošak CA certifikata koji se također plaća, trošak licence za certificirani softver, trošak osiguravanja organizacijskih mjera za zaštitu osobnih podataka i tako dalje. Tako se utvrđuje trošak npr. osobne potvrde pojedinca. Što omogućuje potpisivanje lokalnih datoteka, dokumenata na web stranicama javnih usluga i e-mail poruka.

Druga komponenta troška certifikata pojavljuje se kada korisnik želi svoj certifikat koristiti, na primjer, za rad na platformama za elektroničko trgovanje. Prema važećim propisima, stranica platforme za elektroničko trgovanje autentificira klijenta ako su već ispunjena dva uvjeta: prvo, ako certifikat nije istekao, certifikat nije opozvan i valjan je njegov potpis. I drugo, ako certifikat jasno kaže da je dizajniran za rad na određenom mjestu. Unos za to izgleda kao običan unos u istoj tablici koja pohranjuje ostatak podataka certifikata. Za svaki takav unos u svakom korisničkom certifikatu certifikacijski centar daje određeni iznos. Koji se želi nadoknaditi na teret vlasnika certifikata. Stoga su certifikati koji omogućuju ulazak na elektroničke trgovačke platforme skuplji.

Prijetnje i napadi

Za razliku od enkripcije, u slučaju elektroničkog potpisa glavni zadatak napadača nije dobiti dešifrirani tekst, već moći krivotvoriti ili proizvesti elektronički potpis proizvoljnog dokumenta. To jest, relativno govoreći, ne na dešifriranje, nego na šifriranje. Uvjetno - jer moderni specijalizirani algoritmi digitalnog potpisa, kao što je gore spomenuto, ne šifriraju hash dokumenta, već na njemu izvode matematičke operacije slične po značenju, ali tehnički različite.

Prema standardima usvojenim u Ruskoj Federaciji, pri elektroničkom potpisivanju dokumenata koriste se kriptografski algoritmi koji odgovaraju Državni standard RF (GOST R). U vrijeme pisanja ovog teksta (druga polovica 2016.), ni za jedan od algoritama koji se odnose na EDS i koji imaju status standarda u Ruskoj Federaciji, nisu poznate metode napada koje se značajno razlikuju po intenzitetu rada od jednostavnog nabrajanja. U praksi to znači da je napadaču, čija je razina pristupa računalnim resursima niža od one velike države, lakše pokušati ukrasti ključ nego hakirati algoritam i krivotvoriti potpis.

Dakle, u slučaju elektroničkog potpisa, glavni vektori napada usmjereni su na dobivanje tajnog ključa od strane napadača. Ako je ključ pohranjen u datoteci na disku, može se ukrasti u bilo kojem trenutku dobivanjem odgovarajućeg pristupa za čitanje. Na primjer, uz pomoć virusa. Ako je ključ pohranjen u šifriranom obliku, može se dobiti u trenutku prijave – na primjer, kada je program koji obavlja elektronički potpis već dešifrirao ključ i njime obrađuje podatke. U ovom slučaju, zadatak postaje mnogo kompliciraniji - morate pronaći ranjivost u programu ili ćete morati sami dešifrirati ključ. Unatoč značajnoj kompliciranju zadatka, on i dalje ostaje sasvim stvaran. Za stručnjake u relevantnom području, spada u kategoriju rutinskih.

Zadatak dobivanja tajnog ključa od strane napadača moguće je još značajnije zakomplicirati postavljanjem tajnog ključa na poseban hardverski medij na način da ključ nikada ne napušta granice ovog fizičkog uređaja. U tom slučaju, napadač može dobiti pristup ključu samo krađom fizičkog uređaja. Gubitak uređaja bit će signal vlasniku da je ključ ukraden. U svakom drugom slučaju - a to je najvažnija nijansa - krađa ključa može proći nezapaženo, a vlasnik ključa neće na vrijeme saznati da je potrebno hitno kontaktirati CA i opozvati valjanost svog certifikata .

Ovdje opet analogija s bankovna kartica, koji je alat za provjeru autentičnosti za pristup bankovnom računu. Dok je ona s vlasnikom, on je miran. Ako je kartica izgubljena, morate je odmah blokirati. U ovom slučaju, zadatak napadača nije ukrasti karticu, već diskretno napraviti njezinu kopiju kako vlasnik ne bi blokirao pristup. Za moderne hardverske tokene, metode kloniranja trenutno su nepoznate.

Tokeni

U ovom trenutku, općeprihvaćeni izraz za pojedinačne fizičke uređaje koji se koriste za pohranu ključeva elektroničkog potpisa je token. Tokeni se mogu povezati s računalom putem USB-a, Bluetooth-a ili putem posebnih uređaja za čitanje. Većina modernih tokena koristi USB sučelje. Ali glavna razlika između vrsta tokena nije u sučelju veze. Tokeni se mogu podijeliti u dvije vrste – one koji se zapravo koriste samo kao pohrana ključeva, i one koji “mogu” samostalno obavljati kriptografske operacije.

Tokeni prve vrste razlikuju se od običnih flash pogona u biti samo po tome što se podaci s njih mogu čitati samo uz pomoć posebnog softvera. Inače se radi o normalnoj vanjskoj pohrani podataka, a ako u nju pohranimo tajni ključ, onda ga može ukrasti svatko tko dobije prava pristupa uređaju i zna čitati ključ s njega. Takvi se tokeni nazivaju softverskim tokenima i praktički ne daju nikakve prednosti u odnosu na pohranjivanje ključa na disk računala – vlasnik ključa također ne može biti siguran da zna sva mjesta na kojima je pohranjen njegov tajni ključ.

Tokeni druge vrste nazivaju se hardverskim tokenima, a njihova glavna razlika je u tome što je tajni ključ nepovratan – nikada ne napušta granice tokena. Da biste to učinili, na token se postavlja poseban set softvera koji se aktivira kada je token spojen na računalo. Zapravo, takav token je neovisni računalni uređaj s vlastitim procesorom, memorijom i aplikacijama koji komunicira s računalom.

Tajni ključ nikada ne napušta hardverski token jer se generira upravo na samom tokenu. Za potpisivanje dokumenta, hash dokumenta se učitava u token, izračuni se izvode izravno "na ploči" tokena pomoću tajnog ključa koji je tamo pohranjen, a gotovi potpis se učitava natrag. Dakle, znajući mjesto tokena, uvijek znamo mjesto tajnog ključa.

Jedna od glavnih karakteristika hardverskog tokena je skup podržanih kriptografskih algoritama. Na primjer, ako želimo koristiti hardverski token za autentifikaciju na našem kućnom računalu, bilo koji moderni token će učiniti. A ako se želimo autentifikovati na portalu državnih službi, onda nam je potreban token koji podržava kriptografske algoritme certificirane u Rusiji.

U nastavku su popisi podržanih kriptografskih mehanizama za eToken i JaCarta GOST tokene. Za traženje popisa mehanizama korišten je pkcs11-tool open utility s parametrom “-M” (od riječi “mechanism”), koji može djelovati kao klijentska aplikacija za bilo koju biblioteku koja implementira sučelje PKCS # 11 u svom smjer. libeToken.so i libjcPKCS11.so.1 koriste se kao PKCS#11 biblioteke za eToken odnosno JaCarta. Knjižnica za eToken distribuira se kao dio softvera SafeNet, biblioteka za JaCarta dostupna je za preuzimanje s web stranice Aladdina R.D.

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M Podržani mehanizmi: DES-MAC, keySize=(8,8), sign, verify DES-MAC-GENERAL, keySize=( 8,8), potpiši, provjeri DES3-MAC, veličina ključa=(24,24), potpiši, provjeri DES3-MAC-GENERAL, veličina ključa=(24,24), potpiši, provjeri AES-MAC, veličina ključa=(16,32 ), potpišite, provjerite AES-MAC-GENERAL, veličina ključa=(16,32), potpišite, provjerite RC4, veličina ključa=(8,2048), šifriranje, dešifriranje DES-ECB, veličina ključa=(8,8), šifriranje, dešifriranje , omotati, odmotati DES-CBC, veličina ključa=(8,8), šifriranje, dešifriranje, premotavanje, odmotavanje DES-CBC-PAD, veličina ključa=(8,8), šifriranje, dešifriranje, omotavanje, odmotavanje DES3-ECB, veličina ključa= (24,24), hw, encrypt, decrypt, wrap, unwrap DES3-CBC, keySize=(24,24), hw, encrypt, decrypt, wrap, unwrap DES3-CBC-PAD, keySize=(24,24), hw, encrypt, decrypt, wrap, unwrap AES-ECB, keySize=(16,32), encrypt, decrypt, wrap, unwrap AES-CBC, keySize=(16,32), encrypt, decrypt, wrap, unwrap AES-CBC -PAD, veličina ključa=(16,32), šifriranje, dešifriranje, omotavanje, odmotavanje mechtype-0x1086, veličina ključa=(16,32), šifriranje, dešifriranje, omotavanje, odmotavanje mec htype-0x1088, keySize=(16,32), encrypt, decrypt, wrap, unwrap RSA-PKCS-KEY-PAIR-GEN, keySize=(1024,2048), hw, generate_key_pair RSA-PKCS, keySize=(1024,2048) ), hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap RSA-PKCS-OAEP, keySize=(1024,2048), hw, encrypt, decrypt, wrap, unwrap RSA-PKCS-PSS, keySize= (1024,2048), hw, sign, verify SHA1-RSA-PKCS-PSS, keySize=(1024,2048), hw, sign, verify mechtype-0x43, keySize=(1024,2048), hw, sign, verify mechtype -0x44, keySize=(1024,2048), hw, sign, verify mechtype-0x45, keySize=(1024,2048), hw, sign, verify RSA-X-509, keySize=(1024,2048), hw, encrypt , dešifriranje, potpisivanje, sign_recover, verify, verify_recover, wrap, unwrap , verify SHA256-RSA-PKCS, keySize=(1024,2048), hw, sign, verify SHA384-RSA-PKCS, keySize=(1024,2048), h , potpiši, provjeri SHA512-RSA-PKCS, veličina ključa=(1024 ,2048), hw, potpiši, provjeri RC4-KEY-GEN, veličina ključa=(8204 8), generiraj DES-KEY-GEN, keySize=(8,8), generiraj DES2-KEY-GEN, keySize=(16,16), generiraj DES3-KEY-GEN, keySize=(24,24), generiraj AES -KEY-GEN, veličina ključa=(16,32), generiranje PBE-SHA1-RC4-128, veličina ključa=(128,128), generiranje PBE-SHA1-RC4-40, veličina ključa=(40,40), generiranje PBE-SHA1- DES3-EDE-CBC, veličina ključa=(24,24), generiranje PBE-SHA1-DES2-EDE-CBC, veličina ključa=(16,16), generiranje GENERIC-SECRET-KEY-GEN, veličina ključa=(8,2048), hw, generiraj PBA-SHA1-WITH-SHA1-HMAC, keySize=(160,160), hw, generiraj PBE-MD5-DES-CBC, keySize=(8,8), generiraj PKCS5-PBKD2, generiraj MD5-HMAC-GENERAL, keySize=(8,2048), sign, verify MD5-HMAC, keySize=(8,2048), sign, verify SHA-1-HMAC-GENERAL, keySize=(8,2048), sign, verify SHA-1-HMAC , keySize=(8,2048), sign, verify mechtype-0x252, keySize=(8,2048), sign, verify mechtype-0x251, keySize=(8,2048), sign, verify mechtype-0x262, keySize=(8 ,2048), sign, verify mechtype-0x261, keySize=(8,2048), sign, verify mechtype-0x272, keySize=(8,2048), sign, verify mechtype-0x271, keySize=(8,2) 048), potpišite, provjerite MD5, digest SHA-1, digest SHA256, digest SHA384, digest SHA512, digest mechtype-0x80006001, keySize=(24,24), generirajte $ pkcs11-tool --module /usr/local/lib64/ libjcPKCS11.so. 1 -M Podržani mehanizmi: GOSTR3410-KEY-PAIR-GEN, hw, generate_key_pair GOSTR3410, hw, sign, verify GOSTR3410-WITH-GOSTR3411, hw, sign, verify mechtype-0x1204, hw,hw,hwder mech1,hw04 digestive mech1,hw04 , generiraj mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001

Može se vidjeti da je popis podržanih mehanizama za eToken vrlo dugačak, ali ne uključuje GOST algoritme. Popis podržanih mehanizama JaCarta uključuje samo GOST algoritme, ali u količini potrebnoj za implementaciju EDS funkcionalnosti na hardverskom tokenu.

Važno je razumjeti da se moderni hardverski tokeni općenito mogu koristiti i kao softverski tokeni. Odnosno, obično imaju malo područje memorije dostupno izvana, koje se, po želji, može koristiti za snimanje i pohranu tajnog ključa generiranog izvana. Tehnološki, to nema smisla, ali zapravo se ova metoda koristi, nažalost, prilično široko. Nažalost, jer često vlasnik tokena ne zna da se njegov moderni hardverski token, pošteno kupljen ne za nominalnu naknadu, koristi kao softverski.

Primjeri isključivo softverskih tokena uključuju Rutoken S i Rutoken Lite. Kao primjeri hardverskih tokena koji ne podržavaju kriptografske algoritme certificirane u Rusiji, postoje “eToken” uređaji; kao podrška ruskoj kriptografiji - "Rutoken EDS", "JaCarta GOST".

Pružatelji kriptovaluta

Softver koji operateru omogućuje pristup kriptografskim funkcijama – elektronički potpis, šifriranje, dešifriranje, raspršivanje – naziva se kriptografski pružatelj, pružatelj kriptografskih funkcija. U slučaju hardverskog tokena, kriptografski pružatelj implementiran je izravno na tokenu, u slučaju softverskog tokena ili u slučaju pohranjivanja ključeva na disk računala, implementiran je kao obična korisnička aplikacija.

Sa stajališta sigurnosti korisničkih podataka, jedan od glavnih vektora napada usmjeren je na kripto davatelja – tajni ključ se dešifrira u memoriji kripto davatelja. U slučaju uspješnog napada, napadač će moći zamijeniti kod aplikacije svojim vlastitim i napraviti kopiju tajnog ključa, čak i ako je ključ normalno pohranjen u šifriranom obliku. Stoga, u slučaju korištenja kriptografije za obavljanje elektroničkog potpisa koji ima pravnu snagu, država nastoji zaštititi građane od mogućeg curenja tajnih ključeva. To se izražava u činjenici da je za rad s kvalificiranim elektroničkim potpisom službeno dopušteno koristiti samo davatelje kriptovaluta koji imaju odgovarajući certifikat i stoga su prošli odgovarajuće provjere.

Kripto pružatelji usluga certificirani u Ruskoj Federaciji za EDS uključuju, posebice: Rutoken EDS, JaCarta GOST, CryptoPro CSP, LISSI-CSP, VipNet CSP. Prva dva su implementirana izravno na hardverske tokene, ostali su u obliku korisničkih aplikacija. Važno je razumjeti da prilikom kupnje hardverskog tokena certificiranog u Ruskoj Federaciji, mi već stječemo kripto davatelja certificiranog u Ruskoj Federaciji i nema potrebe - tehnološke i pravne - za kupnjom drugog kripto davatelja.

Osim skupa podržanih algoritama, kriptografski pružatelji se razlikuju i po skupu kriptografskih funkcija - šifriranje i dešifriranje dokumenata, potpisivanje i provjera potpisa, prisutnost grafičkog korisničkog sučelja i tako dalje. Štoviše, od cijelog ovog skupa funkcija, certificirani kriptografski pružatelj mora izvoditi samo one koje su izravno povezane s implementacijom kriptografskih algoritama. Sve ostalo može učiniti aplikacija treće strane. Upravo tako kriptopružatelji rade na hardverskim tokenima: korisničko sučelje implementira aplikacija treće strane koja ne podliježe obveznoj certifikaciji. Aplikacija koja implementira korisničko sučelje komunicira s kriptografskim davateljem na tokenu preko drugog standardnog sučelja - PKCS#11. Istodobno, s korisničke točke gledišta, rad s ključevima odvija se, na primjer, izravno iz html preglednika Firefox. Zapravo, preglednik, putem sučelja PKCS #11, koristi poseban softverski sloj koji implementira mehanizme za pristup određenom hardverskom tokenu.

Osim pojma „davatelj kriptografskih usluga“ postoji još jedan pojam koji je blizak po značenju – „sredstvo zaštite kriptografskih informacija“ (CIPF). Ne postoji jasna razlika između ova dva koncepta. Prvi izraz je manje službeni, drugi se češće koristi u odnosu na certificirana tehnička rješenja. Budući da ovaj dokument uglavnom opisuje tehnološke, a ne formalne aspekte, češće ćemo koristiti izraz „kriptopružatelj“.

Implementacija mehanizama

Algoritmi elektroničkog potpisa

Trenutno je u Ruskoj Federaciji službeno dopušteno korištenje samo dva algoritma potpisa i dva algoritma za raspršivanje za kvalificirani elektronički potpis. Do kraja 2017. dopušteno je koristiti GOST R 34.10-2001 u kombinaciji s algoritmom za raspršivanje GOST R 34.11-94. Od početka 2018. dopušteno je koristiti samo GOST R 34.10-2012 i hasheve u skladu s GOST R 34.11-2012. U situacijama kada nije potrebna obvezna uporaba GOST algoritama, mogu se koristiti svi dostupni algoritmi.

Na primjer, sada većina web stranica dostupnih putem HTTP protokola ne zna koristiti GOST algoritme za međusobnu autentifikaciju klijenta i poslužitelja. U slučaju interakcije s jednom od ovih stranica, strana klijenta također će morati primijeniti algoritme "strane proizvodnje". Ali, na primjer, ako želite koristiti hardverski token kao pohranu ključeva za provjeru autentičnosti na web stranici državnih službi, morat ćete odabrati token s podrškom za EDS prema GOST-u.

Potreba za korištenjem ruskih algoritama u interakciji s vladinim agencijama uopće nije posljedica želje da se građanima ograniči njihov izbor. Razlog je taj što je država, koja je uložila u razvoj ovih algoritama, odgovorna za njihovu kriptografsku snagu i nepostojanje neprijavljenih značajki u njima. Svi kriptografski algoritmi standardizirani u Ruskoj Federaciji više puta su prošli neovisnu reviziju i uvjerljivo dokazali svoju vrijednost. Isto se može reći i za mnoge druge uobičajene kriptografske algoritme. Ali, nažalost, nepostojanje neprijavljenih sposobnosti u njima se ne može s jednakom lakoćom dokazati. Sasvim je jasno da je sa stajališta države nerazumno koristiti nepovjerljiva sredstva, primjerice, za obradu osobnih podataka građana.

Sučelja, formati i protokoli

Kako bi se osigurala kompatibilnost pri radu s elektroničkim potpisom, razvijen je niz međunarodnih standarda koji se odnose na pohranu podataka i omogućavanje pristupa njima. Glavni standardi uključuju:

  • PC/SC - sučelje niske razine za pristup kriptografskim uređajima, uključujući softverske i hardverske tokene;
  • PKCS#11 - sučelje visoke razine za interakciju s hardverskim kriptografskim modulima, može se smatrati jedinstvenim sučeljem za pristup pružateljima kriptografskih usluga;
  • PKCS#15 - format spremnika s ključevima elektroničkog potpisa, namijenjen za pohranu na fizičkom uređaju;
  • PKCS#12, PEM - formati spremnika s ključevima elektroničkog potpisa namijenjeni za pohranu u datotekama, binarnim i tekstualnim;
  • PKCS#10 – format dokumenta – zahtjev za potpisivanje koji klijent šalje CA-u za primanje potpisanog certifikata.

Važno je razumjeti da su standardi kao što su PKCS#11 ili PKCS#15 izvorno razvijeni bez uzimanja u obzir specifičnosti kriptovaluta certificiranih u Ruskoj Federaciji. Stoga, kako bi se implementirala puna podrška domaćoj kriptografiji, standardi su morali i još uvijek moraju biti dovršeni. Proces donošenja izmjena i dopuna standarda je dugotrajan, pa su se do konačnog usvajanja dovršenih standarda pojavile njihove implementacije koje su međusobno nespojive. To se posebno odnosi na pružatelje kriptovaluta certificiranih u Ruskoj Federaciji. Dakle, sada svi certificirani pružatelji kriptovaluta imaju nekompatibilne implementacije spremnika za pohranjivanje ključeva na tokenu. Što se tiče standarda za razmjenu podataka - PKCS # 10, PKCS # 12, PEM - njihove su implementacije, srećom, obično međusobno kompatibilne. Također, obično nema odstupanja u tumačenju PC/SC standarda.

Pitanjima finalizacije standarda, razvoja preporuka, osiguravanja kompatibilnosti u području EDS-a u Ruskoj Federaciji trenutno se bavi posebna organizacija - Tehnički odbor za standardizaciju "Zaštita kriptografskih informacija" (TK 26), koji uključuje stručnjake, predstavnike vladine agencije, programeri kriptografskih pružatelja usluga i druge zainteresirane strane. Može se raspravljati o učinkovitosti rada povjerenstva, ali i samo postojanje takve platforme iznimno je važno.

Softverski dio

Softverski stog za rad s elektroničkim potpisom sastoji se od sljedećih komponenti:

  • implementacija sučelja za niskorazinski pristup spremnicima za pohranu s ključevima - na primjer, PC / SC sučelje za pristup fizičkim uređajima - tokenima;
  • modul koji implementira PKCS#11 sučelje za interakciju s kriptografskim davateljem - na primjer, implementiran na hardverskom tokenu;
  • kriptografski davatelj koji implementira odgovarajuće kriptografske algoritme i izvršava radnje s njima - na primjer, elektronički potpis ili šifriranje podataka;
  • korisnička aplikacija koja je u interakciji s drugom - u odnosu na kriptografskog davatelja - stranom s PKCS # 11 modulom, i izvodi operacije kao što su elektronički potpis ili autentifikacija u ime korisnika.

Primjer hrpe:

  • Aplikacija naredbenog retka cryptcp iz CryptoPro CSP softvera stupa u interakciju s bibliotekom libcppksc11.so preko PKCS#11 sučelja i pruža mogućnost potpisivanja dokumenata korisničkim tajnim ključem; u isto vrijeme, funkcije kripto davatelja su u potpunosti implementirane u komponente CryptoPro CSP softvera, kripto davatelj hardverskog tokena nije uključen.

Još jedan primjer:

  • otvoreni softver pcsc-lite implementira PC/SC sučelje za interakciju s Rutoken EDS hardverskim tokenom;
  • biblioteka libcppksc11.so iz CryptoPro CSP softvera pruža interakciju sa spremnikom koji se nalazi na tokenu, koji pohranjuje privatni ključ i certifikat korisnika;
  • aplikacija "CryptoPro EDS Browser plugin", koja radi kao dio html preglednika Firefox, komunicira s bibliotekom libcppksc11.so putem sučelja PKCS #11 i pruža mogućnost potpisivanja dokumenata u sučelju preglednika na elektroničkim stranicama trgovački podovi; u isto vrijeme, funkcije kripto davatelja su u potpunosti implementirane u komponente CryptoPro CSP softvera, kripto davatelj hardverskog tokena nije uključen.

Treći primjer:

  • otvoreni softver pcsc-lite implementira PC/SC sučelje za interakciju s Rutoken EDS hardverskim tokenom;
  • biblioteka librtpksc11.so koju proizvodi Aktiv pruža interakciju s kriptografskim davateljem tokena;
  • kriptografski pružatelj tokena obavlja funkcije potpisivanja podataka koji su mu poslani tajnim ključem; tajni ključ ne napušta granice tokena;
  • aplikacija Rutoken Plugin koja se izvodi kao dio html preglednika Firefox komunicira s bibliotekom librtpksc11.so putem sučelja PKCS # 11 i pruža mogućnost potpisivanja dokumenata u sučelju preglednika na kompatibilnim web-mjestima; u isto vrijeme, funkcije kriptografskog pružatelja usluga su u potpunosti implementirane na hardverskom tokenu.

Izbor konkretne implementacije steka trenutačno je određen, prije svega, tri čimbenika - predviđenim opsegom EDS-a, stupnjem tehničke pismenosti korisnika i spremnošću certifikacijskog centra za rad sa zahtjevom za potpisivanje certifikata. .

Osim gore navedenog skupa softvera na korisničkoj strani, postoje još dvije aplikacije koje je potrebno razmotriti. Prvi je softver koji služi certifikacijskom centru. Drugi je softver s kojim želimo biti kompatibilni. Na primjer, web stranica državnih službi. Ili softver za potpisivanje elektroničkih dokumenata.

Ako certifikacijsko tijelo u kojem planiramo dobiti certifikat nije spremno za rad sa zahtjevima za potpisivanje u formatu PKCS #10 i može raditi samo sa softverskim tokenima (odnosno, percipira bilo koji token kao softver), nemamo izbora. U pravilu će u ovom slučaju CA softver za nas generirati par ključeva, zapisati ga u token, odmah generirati zahtjev za potpis na temelju javnog ključa i naših osobnih podataka, potpisati ga i pohraniti certifikat na token . Certifikat i ključ bit će u zatvorenom formatu koji je poznat samo programeru CA softvera. Sukladno tome, da biste pristupili spremniku s ključevima, morat ćete kupiti kriptografskog davatelja od istog programera. A opseg EDS-a bit će ograničen mogućnostima softvera jednog određenog programera. U ovom slučaju nema smisla kupovati hardverski token - možete proći i sa softverskim. U ovom slučaju, token će se svakako morati prenijeti u CA.

Ako je certifikacijsko tijelo u kojem planiramo dobiti certifikat spremno za rad sa zahtjevima za potpisivanje u formatu PKCS #10, onda nam nije važno kakav se softver koristi u ovom CA. Moći ćemo koristiti kriptografskog davatelja koji je kompatibilan s našim ciljanim aplikacijama. Na primjer, s platformama za elektroničko trgovanje ili internetskim stranicama državnih službi. U tom slučaju ne morate nositi token u CA, dovoljno je generirati zahtjev za potpis i tamo ga predočiti zajedno sa svojim papirnatim dokumentima; nabavite certifikat, te ga sami spremite na token uz pomoć odabranog kripto davatelja.

Nažalost, vrlo malo CA-ova trenutno je (krajem 2016.) spremno za rad sa zahtjevom za potpisivanje. Ova situacija je dijelom posljedica nedostatka tehnički trening korisnici koji nisu u mogućnosti osigurati da se zahtjev za potpisom ispravno izvrši – sa svim potrebnim atributima i njihovim vrijednostima. Ovaj vodič namijenjen je rješavanju ovog problema.

Hardver

Među predstavljenima na rusko tržište tokeni uključuju sljedeće:

Hardverski mediji s podrškom za rusku kriptografiju: Rutoken EDS, Jasarta GOST, MS_KEY K.

Razmotrimo kao primjer popise podržanih kriptografskih mehanizama hardvera Rutoken EDS i softvera Rutoken_Lite:

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Podržani mehanizmi: RSA-PKCS-KEY-PAIR-GEN, keySize=(512,2048), hw, generate_key_pair RSA-PKCS, keySize=( 512,2048), hw, encrypt, decrypt, sign, verify RSA-PKCS-OAEP, keySize=(512,2048), hw, encrypt, decrypt MD5, digest SHA-1, digest GOSTR3410-KEY-PAIR-GEN, hw , generate_key_pair GOSTR3410, hw, sign, verify mechtype-0x1204, hw, derive GOSTR3411, hw, digest GOSTR3410-WITH-GOSTR3411, hw, digest, sign mechtype-0x1224, unwx decrypt mechwtype-,hwx decrypt mechwtype mechtype-0x1222, hw, encrypt, decrypt mechtype-0x1220, hw, generiraj mechtype-0x1223, hw, sign, verify $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so: -M Podržani mehanizmi

Kao što vidite, popisi podržanih kriptografskih mehanizama Rutoken Lite su prazni, za razliku od Rutoken EDS-a, koji uključuje GOST i RSA algoritme.

Hardverski tokeni bez podrške za rusku kriptografiju, kao što je gore spomenuto, uključuju, posebno, JaCarta PKI i eToken.

S obzirom na relativno niske cijene hardverskih tokena s podrškom za rusku kriptografiju, možemo s povjerenjem preporučiti njihovu upotrebu. Uz očitu prednost u obliku nepovratnog tajnog ključa, hardverski token uključuje i certificiranog pružatelja kriptovaluta. Odnosno, moguće je organizirati rad s tokenom na način da ne morate dodatno kupovati skupi softver.

Od nedavnih događaja, želio bih napomenuti Rutoken EDS 2.0 s podrškom za standard GOST R 34.10-2012.

Primjena

Korisnički alati

Otvorite Alati

Softver otvorenog koda trenutno vam omogućuje implementaciju gotovo cjelovitog softverskog paketa za rad s EDS-om.

PCSC lite

PC/SC implementacija razvijena u okviru PCSC lite projekta je referenca za obitelj Linux OS. Uključen je u bilo koju od varijanti softverskog paketa koji se razmatra u ovom dokumentu za rad s EDS-om. U budućnosti, ako određena opcija implementacije nije navedena, smatrat ćemo je omogućenom prema zadanim postavkama.

OpenSC

Knjižnica koja implementira sučelje PKCS#11, kao i skup aplikacijskih alata koji koriste njegovu funkcionalnost, razvijena je u sklopu OpenSC projekta. Alat podržava mnoge hardverske tokene, uključujući Rutoken EDS, čiju su podršku dodali stručnjaci tvrtke Aktiv, koja razvija tokene obitelji Rutoken.

Koristeći OpenSC uslužne programe, možete izvesti, posebno, sljedeće radnje na hardverskom tokenu:

  • inicijalizirati token - resetirati postavke na izvorno stanje;
  • postavite administratorske i korisničke PIN-ove (ako je podržano);
  • generirajte par ključeva (ako ga podržava biblioteka PKCS#11);
  • uvesti certifikat potpisan od strane certifikacijskog tijela na token.

Knjižnica PKCS#11 iz paketa OpenSC omogućuje vam izvođenje cijelog skupa operacija elektroničkog potpisa na podržanim tokenima. Podržani tokeni također uključuju Rutoken EDS.

Ovdje je važno razumjeti da za Rutoken EDS postoje dvije različite opcije softverske podrške koje nisu međusobno kompatibilne u pogledu formata za pohranu ključeva na tokenu. Pri korištenju knjižnice PKCS #11 iz OpenSC-a možemo koristiti otvoreni softverski stog, a kada koristimo besplatnu distribuiranu zatvorenu knjižnicu koju proizvodi Aktiv, možemo koristiti zatvoreni Aktiva stog.

OpenSSL

Kako bi se u potpunosti iskoristile mogućnosti EDS-a, osim same biblioteke PKCS # 11, moraju se implementirati korisničke aplikacije koje operateru omogućuju pristup funkcijama knjižnice i mogućnostima tokena. Najbolji primjer takve implementacije je softver otvorenog koda iz OpenSSL projekta. Posebno podržava sljedeće značajke:

  • šifriranje podataka;
  • dešifriranje podataka;
  • potpis dokumenta;
  • ovjera potpisa;
  • generiranje zahtjeva za potpisivanje certifikata;
  • uvoz certifikata;
  • izvoz certifikata.

Osim toga, pomoću OpenSSL-a možete implementirati funkcionalnost punopravnog certifikacijskog tijela, uključujući:

  • izdavanje klijentskih certifikata potpisivanjem zahtjeva za potpisivanje u PKCS#10 formatu;
  • opoziv certifikata klijenata;
  • upis izdanih i opozvanih potvrda.

Jedini nedostatak OpenSSL-a u ovom trenutku, koji još ne dopušta implementaciju potpuno opremljene verzije softverskog paketa EDS zasnovanog na softveru otvorenog koda, je nedostatak otvorenog modula za interakciju s PKCS # 11 bibliotekama s podrškom za GOST algoritmi. Postoji zatvorena implementacija takvog modula, koju je izradio Aktiv, ali nije uključen u osnovnu distribuciju OpenSSL-a, pa se s izlaskom novih verzija OpenSSL-a kompatibilnost povremeno prekida. Otvorena implementacija ovog modula još ne podržava GOST algoritme.

Firefox

Osim OpenSSL-a, poznati Firefox html preglednik također može komunicirati s bibliotekama PKCS #11. Da biste povezali biblioteku PKCS # 11, morate otići na izbornik za upravljanje postavkama "Preferences", zatim odabrati "Advanced" na okomitom popisu s lijeve strane, odabrati "Certificates" na horizontalnom popisu, kliknuti gumb "Sigurnosni uređaji" , u dijaloškom okviru koji se pojavi kliknite gumb "Učitaj"". Pojavit će se još jedan prozor s opcijom odabira puta do datoteke s bibliotekom PKCS#11 i opcijom za unos lokalnog naziva za tu određenu knjižnicu. Na ovaj način možete učitati nekoliko različitih PKCS#11 modula za različite vrste fizičkih i virtualnih uređaja.

Nažalost, funkcionalnost Firefoxa još nije dovoljna za potpisivanje dokumenata u sučelju web stranice. Stoga, za potpuno otvoreni EDS softverski stog s GOST podrškom, još uvijek nema dovoljno dodatka (dodatka) koji vam omogućuje pristup objektima na tokenu iz softvera web-mjesta. Nadamo se da će takav dodatak biti napisan u bliskoj budućnosti. Ili otvoren.

CryptoPro

U verzijama CryptoPro CSP-a do i uključujući 4.0, ručno upravljanje lokalnim predmemorijama koristi se za pohranu korisničkih certifikata i CA certifikata. Za potpuni rad s korisničkim certifikatom potrebno je da njegova kopija bude u jednoj lokalnoj predmemoriji, a cijeli lanac CA certifikata do i uključujući korijenski - u drugom. Tehnološki, ova značajka CryptoPro-a, strogo govoreći, nije u potpunosti opravdana: ima smisla provjeravati lanac tijekom provjere autentičnosti; stvarna činjenica valjanosti potvrde ne utječe na mogućnost potpisivanja. Pogotovo ako je to naš vlastiti certifikat i znamo odakle je došao. U svježim u vrijeme pisanja beta verzijama CryptoPro CSP-a, prema riječima programera, implementirano je automatsko učitavanje lanca CA certifikata. Ali osiguravanje da se samo onaj koji je trenutno u upotrebi nalazi u lokalnoj predmemoriji korisničkih certifikata čini se da se i dalje mora ručno nadzirati.

Programeri trećih strana pokušavaju napisati grafička sučelja za CryptoPro CSP, olakšavajući rutinske korisničke operacije. Primjer takvog uslužnog programa je rosa-crypto-tool, koji automatizira potpisivanje i šifriranje dokumenata. Paket u ALT distribucijama.

CryptoPro CA

Lissi SOFT softver karakterizira strogo pridržavanje standarda i tehničkih specifikacija. Pružatelji kripto usluga, uključujući one jedinstvene, dizajnirani su kao PKCS#11 knjižnice. Prema riječima programera, dobro se uklapaju u softver otvorenog koda, koji je također fokusiran na podršku standardima. Na primjer, s html preglednicima i uslužnim programima iz OpenSSL kompleta.

Što se tiče organiziranja pristupa stranicama javnih usluga, zanimljivi su i proizvodi Lissy SOFT. Prije svega - kompatibilnost s "IFCPlugin" - dodatkom preglednika koji implementira EDS mehanizme na portalu državnih službi. Drugo, sposobnost softvera certifikacijskog tijela da radi sa zahtjevima za potpisivanje certifikata u formatu PKCS#10.

Preglednici

Ponekad, da bismo pristupili stranicama na kojima planiramo koristiti mehanizme elektroničkog potpisa, moramo koristiti druge tehnologije koje koriste rusku kriptografiju. Na primjer, GOST algoritmi se mogu koristiti za organiziranje šifriranog kanala za prijenos podataka. U tom slučaju potrebna je podrška za odgovarajuće algoritme u pregledniku. Nažalost, službene verzije Firefoxa i Chromiuma još ne podržavaju u potpunosti rusku kriptografiju. Stoga morate koristiti alternativne sklopove. Takvi sklopovi su, primjerice, u arsenalu kripto-sredstava tvrtki "CryptoPro" i "Lissy SOFT", kao i u Alt distribucijama.

Stranice

Među stranicama koje zahtijevaju korištenje tehnologija elektroničkog potpisa, prvenstveno nas zanimaju stranice koje pružaju javne usluge, kao i platforme za elektroničko trgovanje (ETP). Nažalost, neki ETP-ovi još ne podržavaju rad s OS-om iz Registra ruskog softvera. Ali situacija se postupno mijenja na bolje.

Upotreba EDS-a za web stranice obično se svodi na provjeru autentičnosti i potpisivanje dokumenata generiranih u sučelju stranice. U principu, autentifikacija izgleda isto kao i potpis bilo kojeg drugog dokumenta: stranica na kojoj se klijent želi autentifikovati generira niz znakova koje šalje klijentu. Klijent šalje natrag potpis ove sekvence napravljen pomoću njegovog privatnog ključa i svog certifikata (certifikat je malo ranije). Stranica preuzima javni ključ iz certifikata klijenta i provjerava potpis izvornog niza. Isto vrijedi i za potpisivanje dokumenata. Ovdje se umjesto proizvoljnog niza pojavljuje sam dokument.

javne službe

Kao rezultat studije pokazalo se da je od 14. prosinca 2016. većina saveznih trgovačkih platformi - "", "RTS-tender" i "Sberbank-AST" spremna za korištenje na radnim mjestima s operativnim sustavima Linux. Preostale dvije stranice još ne pružaju čak ni mogućnost prijave s klijentskim certifikatom. Planiraju li njihovi programeri ikakve mjere kako bi osigurali kompatibilnost, nažalost, još uvijek nije otkriveno.

Istodobno, u službenim uputama svih web-mjesta, osim Jedinstvene elektroničke trgovačke platforme, operacijski sustav Windows naveden je kao jedini podržani. Službeni odgovori službi tehničke podrške potvrđuju ovu informaciju. Upute na web stranici United Electronic Trading Platforma opisuju postavke preglednika bez navođenja određenog operativnog sustava.

U sažetom obliku, rezultati studije dati su u tablici:

Elektronsko tržište Mogućnost prijave s korisničkim certifikatom Mogućnost potpisivanja dokumenta u sučelju platforme Dokumentacija o radu sa stranicama pod OS-om iz Registra
Sberbank - Automatizirani sustav trgovanja Da Da Ne
Jedinstvena platforma za elektroničko trgovanje Da Da Da

Za ETP-ove koji pružaju kompatibilnost s Linuxom, jedini podržani kripto alat u ovom trenutku je dodatak Cades, koji može koristiti samo CryptoPro CSP kao pružatelj kriptovaluta. Stoga je dobra vijest da je vrlo lako dobiti token za pristup elektroničkim trgovačkim platformama – većina CA ih izdaje. Loše vijesti - token će se temeljiti na softveru i neće biti kompatibilan s web-stranicom državnih službi.

Za druge platforme za trgovanje, jedini način pristupa EDS funkcionalnosti je komponenta Windows OS-a pod nazivom CAPICOM. Stručnjaci Etersofta proveli su istraživački rad, kao rezultat toga je razjašnjena teoretska mogućnost pokretanja CAPICOM-a u Wine okruženju.

Druge stranice

Osim navedenih stranica koje izravno koriste EDS - za ulazak na stranicu i potpisivanje dokumenata generiranih u sučelju stranice, postoji niz stranica koje pružaju mogućnost preuzimanja dokumenata prethodno potpisanih kvalificiranim elektroničkim potpisom. Primjer je stranica Glavnog radiofrekventnog centra. Pristup stranici se vrši putem prijave i lozinke, a dokumenti se pripremaju i potpisuju unaprijed - u korisničkom sučelju OS-a. Stoga je za rad s takvim stranicama potrebna samo funkcionalnost lokalnog potpisivanja dokumenata. Odnosno, u ovom slučaju praktički nema ograničenja u izboru kripto davatelja.

Primjer rješenja po sistemu ključ u ruke

Nažalost, u ovom trenutku autori ovog dokumenta ne znaju kako koristiti isti token istovremeno na web stranici državnih službi i na platformama za elektroničko trgovanje. Stoga ćete morati napraviti dva tokena s dva para ključeva i dva certifikata. Nije zakonski zabranjeno, tehnički je izvedivo. Financijski je također sasvim realno: jedan token će biti, primjerice, hardverski Rutoken EDS, drugi će biti neki stari model eTokena, koji se sada može pronaći uz nominalnu naknadu.

Pristup web stranici državnih službi

Da biste pristupili državnim službama, uzmite Rutoken EDS i izvršite sljedeće korake:

  1. preuzmite softver dodataka Rutoken sa stranice na poveznici;
  2. instalirajte dodatak Rutoken - kopirajte datoteke dodataka (npCryptoPlugin.so i librtpkcs11ecp.so) na ~/.mozilla/plugins/ ;
  3. idite na stranicu sa softverom Registracijskog centra i slijedite upute za izvođenje sljedećih radnji - inicijalizirajte token, generirajte par ključeva, generirajte i spremite lokalnu datoteku sa zahtjevom za potpis u formatu PKCS # 10;
  4. kontaktirat ćemo CA koji nam je spreman izdati certifikat na zahtjev za potpis, dobit ćemo certifikat u obliku datoteke;
  5. u sučelju "Centar za registraciju" spremite certifikat iz primljene datoteke na token;
  6. preuzmite paket formata “deb” s veze - datoteke IFCPlugin-x86_64.deb ;
  7. pomoću softvera "Midnight Commander" (naredba mc) "idi" u datoteku paketa kao u direktorij;
  8. kopirajte sadržaj imenika SADRŽAJ/usr/lib/mozilla/plugins u lokalni ~/.mozilla/plugins direktorij;
  9. u pregledniku Firefox na web stranici Državnih službi slijedit ćemo poveznice "Prijava" i "Prijava elektroničkim putem".

Glavni problem u provedbi ove upute je pronaći certifikacijsko tijelo koje je spremno raditi sa zahtjevom za potpis.

Pristup elektroničkim platformama za trgovanje

Za pristup stranicama platformi za elektroničko trgovanje koje podržavaju rad u Linuxu, izvršite sljedeće korake:

  1. sa bilo kojim tokenom koji je službeno prodan u Ruskoj Federaciji, kontaktirat ćemo bilo koji certifikacijski centar koji koristi CryptoPro CA, a mi ćemo primiti korisnički certifikat i tajni ključ pohranjeni na tokenu u spremniku formata koji podržava softver CryptoPro;
  2. u skladu s upute instalirati softver "CryptoPro CSP" i "Cades plugin" za preglednik Chromium;
  3. koristeći Chromium preglednik, otići ćemo na stranice elektroničkih platformi za trgovanje i početi raditi s njima prema službenim uputama.

Mogućnost potpisivanja dokumenata u obliku datoteka bit će dostupna putem konzolnih uslužnih programa CryptoPro i putem omotača trećih strana poput već spomenutog rosa-crypto-alata.