Mosmarrëveshjet me fqinjët 

Certifikata Lissy soft root. Seksionet Wiki

Kërkesat e sistemit

  • hyrje në internet
  • Sistemi operativ: Windows 8, 7, XP SP 3/2
  • Procesori: 1.6 GHz ose më i lartë
  • RAM: 512 MB
  • Disponueshmëria e një prej ofruesve të kriptove të mbështetur: CryptoPro CSP 3.6 ose më i lartë, LISSI CSP, VIPNet CSP, Signal-COM CSP
  • Rezolucioni i ekranit: të paktën 800x600 px

Përdorni një ofrues të certifikuar të kriptove

Për funksionimin e programit Ekey.Signature, prania në vendin e punës e një mjeti të mbrojtjes së informacionit kriptografik (CIPF) që kodon dokumentet në përputhje me algoritmet GOST është i detyrueshëm. Sistemet CryptoPro CSP jo më të ulëta se 3.6, LISSI CSP, VIPNet CSP, Signal-COM CSP mund të përdoren si CIPF.

Mjetet e mbrojtjes së informacionit kriptografik janë në përputhje me Ekey.Signature, por ato janë të papajtueshme me njëra-tjetrën. Vetëm një CIPF mund të instalohet në një vend pune.

Përdorni një antivirus

Instaloni një antivirus popullor në vendin tuaj të punës dhe përditësoni atë rregullisht. Antivirusi mbron nga viruset, spyware dhe eliminon vetë shumicën e kërcënimeve të sigurisë.

Mbroni aksesin në nënshkrimin tuaj elektronik dhe vendin e punës me një fjalëkalim

Duke përdorur Ekey.Signature dhe mjetet e mbrojtjes kriptografike, mbroni kompjuterin tuaj nga aksesi fizik i të huajve. Përdorni aksesin me fjalëkalim.

Për të hyrë nënshkrim elektronik, përdorni një fjalëkalim kompleks. Një fjalëkalim i mirë është një siguri e garantuar e të dhënave tuaja. Një mënyrë e mirë për të mbajtur mend një fjalëkalim është futja e tij vazhdimisht gjatë kryerjes së operacioneve të nënshkrimit elektronik.

Një vend i mrekullueshëm për të ruajtur fjalëkalimin tuaj është kujtesa juaj. Nuk këshillohet të shkruani fjalëkalimin askund. Mos e ruani fjalëkalimin pranë operatorit fizik të nënshkrimit elektronik, mos e ruani fjalëkalimin në sistem.

Përdorni vetëm programe të licencuara dhe të përditësuara

Periodikisht, programet e instaluara në vendin tuaj të punës përditësohen për të përmirësuar stabilitetin dhe sigurinë e punës suaj.

Instaloni përditësimet e softuerit vetëm nga faqet zyrtare, kontrolloni adresat e faqeve dhe informacionin rreth botuesit të programit përpara se ta instaloni.

Instalimi Ekey.Nënshkrimi

1. Shkarkoni

2. Për të filluar instalimin e programit, ekzekutoni skedarin e konfigurimit. Nëse hapet UAC, duhet të lejoni ndryshime në programin Ekey Transfer.

Përgatitja e skedarëve për Rosreestr

1. Zgjidhni llojin e funksionimit "Rosreestr" në dritaren kryesore të programit ose në menynë e kontekstit të skedarit.


3. Shtoni një raport duke përdorur butonin "Attach File(s)" ose tërhiqni dhe lëshoni një skedar duke përdorur miun.
4. Klikoni butonin Generate.
6. Pas përfundimit të operacionit, skedari i nënshkrimit do të ruhet në të njëjtën direktori si skedari origjinal, skedari i nënshkrimit të shkëputur është i vlefshëm vetëm nëse skedari origjinal është i pranishëm.

Përgatitja e një kontejneri për FFMS të Rusisë, Shërbimin e Bankës së Rusisë, Bankën Qendrore

1. Zgjidhni llojin e operacionit "FFMS e Rusisë".

2. Zgjidhni një certifikatë personale.

3. Shtoni një raport me shtrirje xtdd ose smcl duke përdorur butonin "Bashngjit skedar(s)" ose tërhiqni dhe lëshoni skedarin me miun.

5. Nëse është e nevojshme, futni fjalëkalimin për kontejnerin e çelësit privat

7. Për të shtuar një nënshkrim, bashkëngjitni kontejnerin e krijuar më parë, zgjidhni certifikatën e kërkuar dhe klikoni butonin Generate.

8. Për të dërguar raporte në portalin e Shërbimit të Bankës së Rusisë (FFMS), klikoni butonin shto, në menynë që shfaqet, zgjidhni kontejnerin e kërkuar me raportin dhe klikoni butonin e ngarkimit në portal.

FSIS TP Ministria e Zhvillimit Rajonal të Rusisë

1. Zgjidhni llojin e operimit "FSIS TP".

2. Zgjidhni një certifikatë personale.

3. Shtoni një raport duke përdorur butonin "Attach File(s)" ose tërhiqni dhe lëshoni një skedar duke përdorur miun.

4. Klikoni butonin Generate.

5. Nëse është e nevojshme, futni fjalëkalimin për kontejnerin e çelësit privat

6. Në menynë e ruajtjes që shfaqet, zgjidhni një vendndodhje për të ruajtur rezultatin e operacionit.

Regjistri Roskomnadzor (zapret-info.gov.ru)

1. Zgjidhni regjistrin e operacionit Roskomnadzor

2. Zgjidhni një certifikatë personale

3. Për të gjetur kohën e përditësimit të fundit të regjistrit, klikoni "Koha e përditësimit të fundit të shkarkimit nga regjistri"

4. Për të dërguar një kërkesë, klikoni "dërgo kërkesën"

Plotësoni fushat për të krijuar një kërkesë.

5. Për të marrë rezultatin e përpunimit të kërkesës, klikoni "Kërko për të marrë rezultatin"

Për të shkarkuar automatikisht regjistrin, duhet të kontrolloni kutinë "Shkarko automatikisht", të vendosni periudhën e kërkuar për shkarkim dhe të specifikoni drejtorinë për të ruajtur rezultatet e shkarkimit.

ISED

1. Zgjidhni llojin e operacionit "ISED".

2. Shtoni një raport duke përdorur butonin "Attach File(s)" ose tërhiqni dhe lëshoni një skedar duke përdorur miun.

3. Zgjidhni certifikatat e marrësve

4. Klikoni butonin Generate.

5. Në menynë e ruajtjes që shfaqet, zgjidhni një vendndodhje për të ruajtur rezultatin e operacionit.

Nënshkrimi i dosjes

1. Zgjidhni llojin e funksionimit "Sign manually".

2. Zgjidhni një certifikatë personale.

4. Zgjidhni opsionet e dëshiruara të nënshkrimit.

5. Klikoni butonin "Sign".

6. Nëse është e nevojshme, futni fjalëkalimin për kontejnerin e çelësit privat

Shpjegimet:

Ruani nënshkrimin në një skedar të veçantë

Kur të vendoset flamuri, do të krijohet një nënshkrim elektronik i pagozhduar Nëse flamuri nuk është i pranishëm, nënshkrimi do të shtohet në fund të dosjes (në këtë rast, dokumenti dhe nënshkrimi elektronik do të ruhen së bashku)

Arkivi i skedarëve

A duhet të arkivoj skedarët pas nënshkrimit?

Zgjerim - Shtesa e parazgjedhur e skedarit të nënshkrimit është sig, ju gjithashtu mund të specifikoni shtesën tuaj

Kodimi - Zgjidhni kodimin që ju nevojitet Der ose Base-64

Çaktivizo titujt e shërbimit- Nëse zgjidhet kodimi Base-64 (Titujt përdoren për pajtueshmëri me palët e treta software).

Kriptimi i skedarit

1. Zgjidhni llojin e funksionimit "Encrypt manually".

2. Zgjidhni një certifikatë personale.

3. Shtoni një skedar duke përdorur butonin "Attach File(s)" ose tërhiqni dhe lëshoni një skedar duke përdorur miun.

4. Zgjidhni opsionet e kërkuara të enkriptimit.

5. Shtoni ose zgjidhni nga certifikatat e disponueshme të marrësve (të cilëve do t'u kodohet skedari)

6. Klikoni butonin "Encrypt".

7. Nëse kërkohet, futni fjalëkalimin për kontejnerin e çelësit privat

8. Në menynë e ruajtjes që shfaqet, zgjidhni një vendndodhje për të ruajtur rezultatin e operacionit. Shpjegimet:

Kodimi

Zgjidhni kodimin Der ose Base-64 që ju nevojitet

Zgjerim

Zgjatja që do të ketë skedari përfundimtar (enc si parazgjedhje), mund të specifikoni gjithashtu shtesën tuaj. Çaktivizo titujt e shërbimit - Nëse zgjidhet kodimi Base-64 (kërkohet për pajtueshmëri me softuerin e palëve të treta).

Arkivoni skedarët përpara enkriptimit

Nëse keni nevojë të arkivoni skedarët përpara kriptimit, kontrolloni kutinë e duhur.

Nëse shtoni shumë skedarë, të gjithë skedarët do të paketohen në një arkiv.

Deshifrimi i skedarit

1. Zgjidhni llojin e veprimit "Decrypt".

2. Zgjidhni një certifikatë personale.

3. Shtoni një skedar duke përdorur butonin "Attach File(s)" ose tërhiqni dhe lëshoni një skedar duke përdorur miun.

4. Klikoni butonin "Decrypt".

5. Nëse është e nevojshme, futni fjalëkalimin për kontejnerin e çelësit privat

6. Në menynë e ruajtjes që shfaqet, zgjidhni një vendndodhje për të ruajtur rezultatin e operacionit.

Verifikimi i nënshkrimit

1. Për të filluar verifikimin e nënshkrimit, përdorni metodën e verifikimit që është e përshtatshme për ju.

  • Duke klikuar dy herë në skedarin që përmban nënshkrimin.
  • Zgjidhni llojin e funksionimit "Verifikimi i nënshkrimit" në menunë kryesore të programit.
  • Përmes menysë së kontekstit të skedarit që do të kontrollohet.

2. Shtoni një skedar duke përdorur butonin "Attach File(s)" ose tërhiqni dhe lëshoni një skedar duke përdorur miun.

3. Klikoni butonin Kontrollo.

Pasi të klikoni butonin "Kontrollo", shfaqet një dritare me rezultatin e verifikimit të nënshkrimit. Në të, ju mund të shikoni pemën e nënshkrimit, të printoni rezultatin e verifikimit dhe të hapni skedarin burimor për shikim.

Gjithashtu, gjatë skanimit, mund të shikoni përmbajtjen e skedarëve me shtesën: doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif.

Shpjegimet:

Hiq nënshkrimin e skedarëve

Nëse është krijuar një nënshkrim i bashkangjitur, ky opsion mund të përdoret për të marrë një skedar burimor që nuk përmban asnjë nënshkrim.

Shto nënshkrim

1. Zgjidhni llojin e operacionit "Shto nënshkrim".

2. Zgjidhni një certifikatë personale.

4. Klikoni butonin "Sign".

5. Nëse është e nevojshme, futni fjalëkalimin për kontejnerin e çelësit privat

6. Në menynë e ruajtjes që shfaqet, zgjidhni një vendndodhje për të ruajtur rezultatin e operacionit.

Verifiko nënshkrimin

1. Zgjidhni llojin e operimit "Certify Signature".

2. Zgjidhni një certifikatë personale.

3. Shtoni një skedar nënshkrimi duke përdorur butonin "Attach File(s)" ose tërhiqeni dhe lëshoni skedarin duke përdorur miun.

4. Klikoni butonin Verifiko.

5. Nëse është e nevojshme, futni fjalëkalimin për kontejnerin e çelësit privat

6. Në menynë që shfaqet, zgjidhni nënshkrimin që dëshironi të vërtetoni

7. Në menynë e ruajtjes që shfaqet, zgjidhni një vendndodhje për të ruajtur rezultatin e operacionit.

Përditësim automatik

Kur një përditësim bëhet i disponueshëm, një mbishkrim përkatës shfaqet në këndin e sipërm djathtas të aplikacionit të nisur Ekey Signature. Për të filluar një përditësim, klikoni mbi të me butonin e majtë të miut.

Pasi të përfundojë procesi i përditësimit, klikoni "OK" në mesazhin se disa ndryshime do të hyjnë në fuqi vetëm pas një rindezjeje. Klikoni butonin "Finish". Pas kësaj, rekomandohet të rindizni kompjuterin. Para së gjithash kërkohet një rindezje që përditësimet që lidhen me punën e menysë së kontekstit të Windows të hyjnë në fuqi.

Instalimi automatik i certifikatave rrënjësore

Nëse nuk ka certifikatë rrënjësore në dyqan, kur hapet aplikacioni Ekey Signature, një gabim përkatës shfaqet në regjistrin e përdoruesit. Në këtë rast, duhet të nënshkruani një skedar me një certifikatë personale "problematike". Kur kryeni operacionin e nënshkrimit, do të shfaqet një kuti dialogu që ju kërkon të instaloni certifikatën rrënjë që mungon. Klikoni Po për të instaluar certifikatën rrënjë që mungon.

Autoriteti i Certifikimit CAFL63 krijuar në bazë të . SQLite3 DBMS përdoret për të ruajtur të dhënat (kërkesat, certifikatat, cilësimet, etj.). Autoriteti i certifikimit ka një ndërfaqe grafike të zhvilluar në Tcl/Tk.

CAFL63 CA u zhvillua duke marrë parasysh kërkesat e Ligjit Federal të 6 Prillit 2011 Nr. Nr. 63-FZ "Për nënshkrimin elektronik", si dhe "Kërkesat për formularin certifikatë e kualifikuarçelësi për verifikimin e nënshkrimit elektronik”, miratuar me urdhër të Shërbimit Federal të Sigurisë së Rusisë, datë 27 dhjetor 2011, nr. 795.

AK përfshin Qendrën e Regjistrimit (QR), e cila është përgjegjëse për pranimin e kërkesave për certifikata nga qytetarët. Sot lëshohen certifikata për persona juridikë, individë dhe sipërmarrës individualë. Aplikimet pranohen në në format elektronik në formatin PKCS#10, CSR (Kërkesë për nënshkrimin e certifikatës) ose SPKAC. Vini re se formati CSR është një kërkesë e koduar PEM PKCS#10 me titullin ----- FILLO KËRKESËN E CERTIFIKATËS -----.

Kërkesa është një pyetësor i plotësuar, qëllimet për të cilat nevojitet një certifikatë, çelësi publik i përdoruesit, i nënshkruar (nënshkruar) me çelësin privat të përdoruesit. Më tej, me një paketë dokumentesh që vërtetojnë veçanërisht identitetin e aplikantit dhe me një medium elektronik ku ruhet kërkesa (theksoj se kërkesa është më mirë ta ruash çelësin privat diku tjetër), qytetari vjen. te AK CR.

CR kontrollon dokumentet, kërkesën (të dhënat e plotësuara, korrektësinë e nënshkrimit elektronik etj.), dhe nëse gjithçka ka shkuar mirë, ata e pranojnë kërkesën, e miratojnë dhe e transferojnë në Qendrën e Certifikimit (QK).

Në rast se aplikanti ka ardhur pa një kërkesë të gatshme, atëherë ai, së bashku me punonjësin e CR, shkon në një të veçantë vendin e punës ku përgatitet kërkesa për certifikatë. Kërkesa e përgatitur për media elektronike, siç u përmend tashmë, hyn në CR. Çfarë duhet të mbajë mend aplikanti këtu? Së pari dhe më kryesorja: aplikanti duhet të marrë median me çelësin privat të krijuar!

Kërkesa e miratuar për median elektronike i transmetohet AK-së, ku në bazë të saj lëshohet vërtetimi.

Ky është një diagram bazë i punës së UC. Detajet do të bëhen të qarta më poshtë. Një shënim, për hir të lehtësisë në demonstrimin e programit të përgatitjes së kërkesës, CR dhe CA janë kombinuar në një kompleks demo. Por nuk ka probleme me ndarjen e funksionalitetit. Zgjidhja më e thjeshtë është të keni një kopje të CAFL63 në çdo vend pune dhe të përdorni vetëm funksionalitetin e kërkuar.

Kur projekti ishte në lëvizje të plotë, projekti SimpleCA më tërhoqi vëmendjen. Studimi i këtij projekti ishte shumë i dobishëm në zbatimin përfundimtar të CAFL63 CA.

Shkarkoni shpërndarjen CAFL63 për platformat Win32/Win64, Linux_x86/Linux_x86_64.

Pra, ne nisim mjetin CAFL63 - faqja fillestare CAFL63 shfaqet në ekran:

Fillojmë punën duke shtypur butonin "Krijo DB". Baza e të dhënave CA është krijuar duke përdorur DBMS ndër-platformë SQLite3. Baza e të dhënave CA përmban disa tabela. Tabela kryesore - mainDB - përmban vetëm një hyrje, e cila ruan certifikatën rrënjë, një çelës privat të koduar me një fjalëkalim dhe cilësimet e CA. Ekzistojnë dy tabela të lidhura me kërkesat për certifikatë: kërkesat aktuale të reqDB dhe arkivi i kërkesave reqDBArc. Janë krijuar tre tabela për certifikatat: tabela e re e certifikatave certDBNew, tabela e arkivit të certifikatave CertDB dhe tabela e revokimit të certifikatave CertDBRev. Të gjitha tabelat e kërkesave dhe certifikatave përdorin vlerën hash (sha1) të çelësit publik si çelës primar. Kjo doli të ishte shumë e përshtatshme, për shembull, kur kërkoni një certifikatë sipas kërkesës ose anasjelltas. Ekziston një tabelë tjetër crlDB në bazën e të dhënave, e cila ruan listat e certifikatave të revokuara. Dhe kështu, ne klikuam butonin "Krijo DB":

Krijimi i një CA fillon me zgjedhjen e një drejtorie në të cilën do të ruajmë bazën e të dhënave dhe vendosjen e një fjalëkalimi për të hyrë në çelësin privat të CA. Duke shtypur tastin "Next", shkojmë në faqen për zgjedhjen e llojit dhe parametrave të çiftit të çelësave për CA:

Pasi kemi vendosur për çiftin e çelësave për certifikatën rrënjësore të autoritetit të certifikimit që po krijohet, ne vazhdojmë të plotësojmë formularin me informacione rreth pronarit (ne kapërcejmë pamjen e parë të ekranit):

Vini re se programi CAFL63 ka një "inteligjencë" të caktuar dhe për këtë arsye kontrollon jo vetëm praninë e të dhënave në fusha, por edhe korrektësinë (theksimi i kuq - i pasaktë) i plotësimit të fushave të tilla si TIN, OGRN, SNILS, OGRNIP, adresa Email dhe etj.

Pas plotësimit të fushave me informacione për pronarin e AK-së, do t'ju kërkohet të vendosni për cilësimet e sistemit të AK-së:

Nëse nuk do të punoni me kriptografinë ruse, atëherë mund të përdorni OpenSSL të rregullt. Për të punuar me kriptografinë ruse, duhet të specifikoni versionin e duhur, modifikimin e OpenSSL. Lexoni README.txt në shpërndarjen e shkarkuar për më shumë detaje. Gjithashtu, në përputhje me FZ-63, propozohet të vendoset informacion në lidhje me certifikimin e vetë AK-së dhe CIPF të përdorur prej tij.

Pasi të plotësoni saktë të gjitha fushat, do t'ju kërkohet edhe një herë të kontrolloni vlefshmërinë e tyre dhe të klikoni butonin "Finish":

Pasi të klikoni butonin "Finish", do të krijohet një bazë të dhënash CA, në të cilën do të ruhen: certifikata rrënjësore e CA, çelësi privat, cilësimet e sistemit. Dhe faqja fillestare e programit CAFL63 do të rishfaqet në ekran. Tani që kemi krijuar bazën e të dhënave të AK-së së sapokrijuar, shtypim butonin "Open DB", zgjedhim drejtorinë me bazën e të dhënave dhe futemi në dritaren kryesore të punës së AK-së:

Duke klikuar butonin "Shiko CA CA", ne sigurohemi që kjo është certifikata jonë rrënjësore.

Hapi tjetër është përgatitja e modeleve/profileve të aplikimit për persona juridikë, individë dhe sipërmarrës individualë ( Mjetet->Cilësimet->Llojet e certifikatës->E re ):

Pas vendosjes së emrit të profilit të ri, do t'ju kërkohet të përcaktoni përbërjen e tij:

Pas përgatitjes së profileve, AK është e gatshme të pranojë aplikantët dhe aplikacionet prej tyre. Siç u përmend më lart, aplikanti mund të vijë me ose pa një aplikim të plotësuar për një certifikatë.

Nëse aplikanti ka ardhur me një aplikacion të kompletuar, atëherë pasi të kontrollohen dokumentet e tij, aplikacioni importohet në bazën e të dhënave të AK-së. Për ta bërë këtë, në dritaren kryesore të punës, zgjidhni skedën "Kërkesat për Certifikatë", klikoni në butonin "Kërkesë Importi / CSR" dhe zgjidhni skedarin me kërkesën. Pas kësaj, do të shfaqet një dritare me informacion në lidhje me kërkesën:

Pasi ta shqyrtoni kërkesën dhe të siguroheni që ajo është plotësuar saktë, mund të klikoni butonin "Import" për ta futur atë në bazën e të dhënave. Vëmë re menjëherë se kur përpiqeni të rifusni kërkesën në bazën e të dhënave CA, do të shfaqet një mesazh:

Kërkesat në bazën e të dhënave të AK-së shënohen (kolona “Lloji”) ose si “Locale”, krijuar nga AK-ja, ose si “Import”, krijuar nga vetë aplikanti, dhe koha e marrjes së aplikacionit nga AK-ja është të regjistruara gjithashtu. Kjo mund të jetë e dobishme në trajtimin e situatave konfliktuale.

Nëse aplikanti erdhi pa një aplikim dhe kërkon ta krijojë atë, atëherë para së gjithash është e nevojshme të vendosni ( Cilësimet->Llojet e certifikatës->Individual->Redakto ) me llojin e çiftit të çelësave ( -> Çifti i çelësave ), per cfare qellimi ( -> Përdorimi i çelësit ) certifikata e kërkuar:

Çifti i çelësave mund të krijohet ose me anë të CIPF "LIRSSL-CSP" (butoni OpenSSL) dhe të ruhet në një skedar, ose në një token PKCS#11 (butoni PKCS#11). Në rastin e fundit, duhet të specifikoni gjithashtu bibliotekën për hyrjen në token (për shembull, rtpkcs11ecp për shenjën RuToken ECP ose ls11cloud për ).

Pasi të keni vendosur për profilin dhe të keni klikuar butonin "Next", procedura e mëtejshme nuk është shumë e ndryshme nga lëshimi i një certifikate rrënjë. Një shënim i rëndësishëm: mbani mend se ku e ruani çelësin privat dhe fjalëkalimin për të hyrë në çelës. Nëse një token/kartë inteligjente PKCS#11 përdoret si një CIPF për të gjeneruar një çift çelësash, atëherë ai duhet të lidhet me një kompjuter:

Aplikacioni i krijuar ose i importuar ndodhet në bazën e të dhënave CA dhe shfaqet në dritaren kryesore në skedën "Kërkesat për Certifikatë". Kërkesat e marra janë nën "konsiderim" (kolona "Statusi" e skedave "Kërkesat për certifikatë" dhe "Arkivi i kërkesave"). Për çdo kërkesë të sapo pranuar, duhet të merret një vendim (menuja e kontekstit kur klikoni me të djathtën mbi kërkesën e zgjedhur):

Çdo kërkesë mund të refuzohet ose miratohet:


Nëse kërkesa refuzohet, ajo zhvendoset nga tabela e kërkesës aktuale reqDB në tabelën e arkivit të kërkesës reqDBArc dhe, në përputhje me rrethanat, zhduket nga skeda Kërkesat për certifikatë dhe rishfaqet në skedën Arkivi i kërkesës.

Aplikacioni i miratuar qëndron në tabelën reqDB dhe në skedën "Kërkesat për Certifikatë" derisa të lëshohet certifikata, dhe më pas futet në arkiv.

Procedura për lëshimin e një certifikate, artikulli i menusë "Lëshoni një certifikatë") ndryshon pak nga procedura për krijimin e një aplikacioni:

Certifikata e lëshuar shfaqet menjëherë në skedën "Certifikatat". Në këtë rast, vetë certifikata hyn në tabelën certDBNew të bazës së të dhënave CA dhe qëndron atje derisa të publikohet. Një certifikatë konsiderohet e publikuar pasi të eksportohet në një depo SQL të certifikatave të reja, e cila transferohet në një shërbim publik. Publikimi i një certifikate e zhvendos atë nga tabela certDBNew në tabelën certDB.

Nëse shtypni butonin e djathtë të miut në rreshtin e zgjedhur në skedën "Certifikatat", do të shfaqet një menu me funksionet e mëposhtme:

Nëse kërkesa është krijuar në AK me çelësin e gjeneruar dhe ruajtur në një skedar, atëherë duhet të krijoni një kontejner PKCS # 12 dhe t'ia dërgoni aplikuesit:

Duhet t'i kushtoni vëmendje "emrit miqësor" - citatet në të duhet të shmangen:

Pasi të krijohet kontejneri i sigurt PKCS#12, skedari i çelësit privat të aplikantit shkatërrohet.

Pra, AK filloi jetën e saj, lëshoi ​​certifikatën e parë. Një nga detyrat e AK-së është të organizojë qasje të lirë në certifikatat e lëshuara. Publikimi i certifikatave, si rregull, kalon përmes shërbimeve në internet. CAFL63 gjithashtu ka një shërbim të tillë:

Për të publikuar certifikatat dhe listat e certifikatave të revokuara në një shërbim publik, AK-ja ose ngarkon paraprakisht certifikatat në skedarë (Certifikatat-> Certifikatat e eksportit), ose bën një grumbullim SQL të të gjithë tabelës së certifikatave, nga e cila mund të krijoni një bazë të dhënash të certifikatave dhe ngarkoni një listë certifikatash në të, dhe më pas bëni një depo SQL të certifikatave të reja, nga të cilat ato do të shtohen në bazën e të dhënave të shërbimit publik:

Funksioni themelor i AK-së është publikimi i listës së certifikatave të revokuara, të ngjashme me atë që vepron Ministria e Punëve të Brendshme në lidhje me pasaportat e skaduara. Certifikata mund të revokohet me kërkesë të pronarit. Arsyeja kryesore e revokimit është humbja e çelësit privat ose humbja e besimit në të.

Për të revokuar një certifikatë, thjesht zgjidhni atë në skedën "Certifikatat", kliko me të djathtën dhe zgjidhni artikullin e menusë "Revokimi i certifikatës":

Procedura e revokimit është e njëjtë si për krijimin e një kërkese ose lëshimin e një certifikate. Certifikata e revokuar hyn në tabelën cerDBRev të bazës së të dhënave CA dhe shfaqet në skedën Certifikatat e Revokuara.

Mbetet të merret në konsideratë funksioni i fundit i AK - lëshimi i CRL - një listë e certifikatave të revokuara. Lista CRL gjenerohet në skedën "Certifikatat e revokuara" duke klikuar butonin "Krijo COS/CRL". Gjithçka që kërkohet këtu nga administratori është të futni fjalëkalimin e AK-së dhe të konfirmoni qëllimin e tij për të lëshuar një CRL:

CRL e lëshuar shkon në tabelën crlDB të bazës së të dhënave dhe shfaqet në skedën CRL/COS. Për të parë CRL-në ose për ta eksportuar atë me qëllim të publikimit në një shërbim publik, duhet, si gjithmonë, të zgjidhni rreshtin e dëshiruar, të shtypni butonin e djathtë të miut dhe të zgjidhni artikullin e menysë:

Shkarkoni shpërndarjen CAFL63 për platformat Win32/Win64, Linux_x86/Linux_x86_64. Për më tepër, gjithçka funksionon me sukses në platformën Android.

Vëmendja e lexuesve është e ftuar në punën kërkimore, gjatë së cilës identifikohen një sërë problemesh me përdorimin e mjeteve të nënshkrimit dixhital që lindin për përdoruesit e Linux. Në veçanti, u zbuluan pikat e mëposhtme jo mjaft të dukshme:

  • mundësia për të marrë dhe përdorur një certifikatë personale të nënshkrimit dixhital për akses në shërbimet publike ofrohet aktualisht vetëm me tarifë nga organizatat tregtare;
  • Transportuesit e të dhënave të nënshkrimeve elektronike të lëshuara për përdoruesit fundorë nga organizata të ndryshme të autorizuara mund të jenë të papajtueshëm si me njëri-tjetrin ashtu edhe me portalet që ofrojnë akses në shërbime, duke përfshirë ato publike;
  • niveli i sigurisë së bartësve të të dhënave të nënshkrimit elektronik, i lëshuar masivisht për përdoruesit fundorë, si rregull, është ulur ndjeshëm në raport me nivelin teknologjik të disponueshëm sot;
  • për shumicën e përdoruesve të OS nga Regjistri i Softuerit Vendas, mekanizmat EDS në Portalin e Unifikuar të Shërbimeve Publike nuk janë të disponueshëm për shkak të papajtueshmërisë së softuerit EPGU dhe softuerit të organizatave të autorizuara që lëshojnë certifikata personale të nënshkrimit elektronik;
  • në disa raste, zhvilluesit e portaleve që ofrojnë shërbime publike rekomandojnë përdorimin e sistemeve operative që nuk përfshihen në regjistër, si dhe mjetet dhe konfigurimet softuerike që reduktojnë me vetëdije sigurinë e të dhënave të përdoruesit.

Autorët e punës presin që rezultatet e marra të jenë të dobishme për përdoruesit e zgjidhjeve që përdorin mekanizmat EDS, integruesit që zbatojnë zgjidhjet përkatëse, dhe gjithashtu do të merren parasysh nga organizatat përgjegjëse për ofrimin e shërbimeve të informacionit publik dhe për zbatimin e mekanizma specifikë të infrastrukturës EDS, si dhe zhvillues të softuerit dhe harduerit përkatës.

Për çfarë bëhet fjalë

Artikulli i kushtohet mbështetjes së nënshkrimit elektronik dixhital (EDS) të dokumenteve në ALT OS, si dhe specifikave të përdorimit të EDS në Federatën Ruse.

Detyra kryesore është të kuptojmë se çfarë duhet të bëjë një "përdorues i zakonshëm" ™ - pa marrë parasysh nëse është një individ apo një person juridik - duke vepruar në një bazë të përbashkët, në mënyrë që të përdorë plotësisht aftësitë e platformave të tregtimit elektronik dhe portaleve të shërbimeve publike ndërkohë që duke punuar në OS nga Regjistri i Softuerit Vendas. "Përdorim i plotë" nënkupton, para së gjithash, mundësinë e vërtetimit në faqen përkatëse duke përdorur një certifikatë të vendosur në një medium fizik të veçantë dhe mundësinë e nënshkrimit elektronik të dokumenteve të krijuara në ndërfaqen e sitit.

Për këtë temë tashmë janë kryer një sërë punimesh kërkimore, rezultati i të cilave ishte përfundimi se, në parim, gjithçka funksionon. Është e rëndësishme të kuptohet këtu se shumica e studimeve të përputhshmërisë me portalet e shërbimeve shtetërore të Federatës Ruse të mjeteve moderne kriptografike që funksionojnë nën sistemin operativ Linux janë kryer në kushte laboratorike. Për shembull, nëse ka marrëveshje të veçanta ndërmjet studiuesit dhe autoritetit të certifikimit që lëshon certifikatën. Fatkeqësisht, bazuar në rezultatet e një pune të tillë, është e vështirë të gjykohen aftësitë reale të personave që veprojnë mbi një bazë të përbashkët.

Si funksionon e gjitha

Për të hyrë në sit pa futur një hyrje dhe fjalëkalim, por thjesht duke lidhur një shenjë harduerike me lidhësin USB, është e nevojshme që një pirg i specializuar softueri të funksionojë siç duhet në sistemin operativ: mbështetje për pajisjet fizike, algoritme kriptografike, ndërfaqe softuerësh. , formatet dhe protokollet e komunikimit. Në të njëjtën kohë, përputhshmëria e algoritmeve, formateve dhe protokolleve kriptografike gjithashtu duhet të sigurohet jashtë fushës së përgjegjësisë së OS - në autoritetin e certifikimit që lëshon certifikatën, dhe në faqen në të cilën duhet të sigurohet qasja.

Dhe nëse flasim për faqet e internetit të agjencive qeveritare, është gjithashtu e nevojshme që kriptovalutat e përdorura të jenë të certifikuara për përdorimin e duhur në Federata Ruse.

Mekanizmat Bazë

Teknologjia EDS, e përdorur zyrtarisht në Federatën Ruse, bazohet në infrastrukturën e çelësit publik. Le të hedhim një vështrim se si funksionon me një shembull.

Për qartësi, le të shqyrtojmë mekanizmin e veprimit të algoritmeve universale të përshtatshme si për nënshkrimin elektronik ashtu edhe për kriptim. Këto algoritme, ndër të tjera, përfshijnë standardin e Internetit RSA dhe GOST R 34.10-94 ruse, i cili ishte në fuqi në Federatën Ruse si një standard i nënshkrimit elektronik deri në vitin 2001. Algoritmet më moderne EDS, të cilat përfshijnë, ndër të tjera, GOST R aktuale 34.10-2001 dhe GOST R 34.10-2012, si rregull, janë të specializuar. Ato janë të destinuara ekskluzivisht për nënshkrimin e dokumenteve dhe nuk janë të përshtatshme për kriptim. Teknikisht, ndryshimi midis algoritmeve të specializuara është se hash-i në rastin e tyre nuk është i koduar. Në vend që të kriptohet, mbi të kryhen edhe llogaritje të tjera duke përdorur çelësin privat, rezultati i të cilit ruhet si nënshkrim. Kur verifikoni një nënshkrim, llogaritjet përkatëse plotësuese kryhen duke përdorur çelësin publik. Humbja e universalitetit në këtë rast është një pagesë për një forcë më të lartë kriptografike. Shembulli i mëposhtëm me një algoritëm universal është ndoshta pak më pak i rëndësishëm, por ndoshta më i kuptueshëm për një lexues të papërgatitur.

Nënshkrimi i dokumentit

Pra, për të formuar një nënshkrim elektronik në një infrastrukturë të çelësit publik, përdoret një skemë asimetrike enkriptimi, e cila karakterizohet nga përdorimi i një palë çelësash. Ajo që është e koduar nga njëri prej këtyre çelësave mund të deshifrohet vetëm nga çelësi tjetër i çiftit. Njëri nga çelësat e çiftit quhet sekret, ose privat, dhe mbahet sa më i fshehtë, tjetri quhet publik, ose i hapur dhe shpërndahet lirshëm - si rregull, si pjesë e një certifikate. Përveç çelësit, certifikata e nënshkrimit elektronik përfshin informacione për pronarin e certifikatës, si dhe nënshkrimin e çelësit, së bashku me informacionin për pronarin, të bëra nga një palë e besuar. Kështu, certifikata tashmë përmban një nënshkrim elektronik që konfirmon se informacioni për pronarin korrespondon me çiftin e tij të çelësave.

Organizativisht, kjo nënshkrim kryhet nga një autoritet certifikues (CA) - një person juridik të cilit i është deleguar autoriteti për të vendosur dhe konfirmuar korrespondencën e pronarit dhe çelësit. Pajtueshmëria vendoset pas paraqitjes së dokumenteve në letër, dhe konfirmohet pikërisht nga një nënshkrim elektronik, i cili është i përshtatshëm për t'u marrë parasysh vetëm me shembullin e bërjes së një certifikate.

Autoriteti i certifikimit për nënshkrimin e certifikatave të klientit ka gjithashtu një palë çelësa. Informacioni i konfirmuar për pronarin e certifikatës në formën e një tabele të krijuar posaçërisht kombinohet në një dokument me çelësin e tij publik. Ky dokument më pas kalon nëpër dy transformime. Së pari, funksioni hash e kthen dokumentin në një sekuencë unike karakteresh me gjatësi fikse (hash). Më pas, hash-i që rezulton kodohet me çelësin privat të autoritetit të certifikimit. Rezultati i kriptimit është nënshkrimi aktual elektronik. Ai i bashkëngjitet dokumentit të nënshkruar, në këtë rast, informacion për përdoruesin dhe çelësin e tij dhe shpërndahet së bashku me të. E gjithë kjo së bashku - një dokument me informacione për përdoruesin dhe çelësin e tij publik, si dhe nënshkrimin e këtij dokumenti me çelësin publik të AK-së, hartohet në një mënyrë të veçantë dhe quhet certifikatë përdoruesi.

Ashtu si në rastin e të dhënave të përdoruesit si pjesë e një certifikate, lëshohet një nënshkrim elektronik i çdo dokumenti tjetër. Për shembull, një skedar me një aplikacion për një shërbim. Skedari është hash, hash-i që rezulton është i koduar me çelësin sekret të përdoruesit dhe i bashkëngjitet dokumentit. Rezultati është një dokument i nënshkruar.

Verifikimi i nënshkrimit

Siç ndodh zakonisht me enkriptimin asimetrik, ajo që është e koduar me një çelës mund të deshifrohet vetëm nga çelësi tjetër i çiftit. Pra, në rastin e një certifikate, hash-i i koduar i një dokumenti që përmban çelësin publik të përdoruesit dhe informacionin e verifikuar rreth përdoruesit mund të deshifrohet duke përdorur çelësin publik të autoritetit certifikues, i cili shpërndahet lirisht si pjesë e certifikatës së autoritetit certifikues. Kështu, kushdo që merr një certifikatë CA do të jetë në gjendje të marrë hash-in e deshifruar nga certifikata e përdoruesit. Meqenëse funksioni hash prodhon një rezultat unik, duke e aplikuar atë në një dokument që përmban çelësin publik të përdoruesit dhe informacion rreth tij, mund të kontrolloni nëse këto dy hash përputhen. Nëse janë, atëherë ne kemi të njëjtin dokument që është nënshkruar nga qendra e certifikimit, dhe informacioni i përfshirë në të mund të besohet. Nëse jo, atëherë nënshkrimi nuk përputhet me dokumentin, dhe ne kemi një të rremë.

Situata me kontrollimin e certifikatës CA është saktësisht e njëjtë - ajo gjithashtu nënshkruhet nga një çelës. Si rezultat, zinxhiri i certifikatave të nënshkruara përfundon me një certifikatë "rrënjë", e cila nënshkruhet vetë. Një certifikatë e tillë quhet e vetë-nënshkruar. Për qendrat e certifikimit të akredituara zyrtarisht të Federatës Ruse, çertifikata rrënjësore është certifikata e Qendrës Kryesore të Certifikimit të Ministrisë së Telekomit dhe Komunikimeve Masive.

Përveç informacionit në lidhje me përdoruesin dhe çelësin e tij publik, certifikata përmban disa të dhëna shtesë - në veçanti, periudhën e vlefshmërisë së certifikatës. Nëse të paktën një certifikatë në zinxhir ka skaduar, nënshkrimi konsiderohet i pavlefshëm.

Gjithashtu, nënshkrimi do të konsiderohet i pavlefshëm nëse certifikata e klientit revokohet nga AK. Aftësia për të revokuar një certifikatë është e dobishme, për shembull, në situatat kur çelësi sekret rrjedh. Një analogji me kontaktimin me një bankë në rast të humbjes së një karte bankare është e përshtatshme.

Shërbimet e qendrave të certifikimit

Pra, qendra e certifikimit me nënshkrimin e saj konfirmon korrespondencën e një çelësi të caktuar publik me një grup të caktuar të dhënash. Teorikisht, kostot e një AK për nënshkrimin e një certifikate janë afër zeros: vetë nënshkrimi është një operacion llogaritës i mirë-automatizuar, jo shumë i shtrenjtë në pajisjet moderne. Në të njëjtën kohë, shërbimet e UC paguhen. Por, ndryshe nga AK-të që lëshojnë certifikata për faqet e internetit, këtu paratë nuk bëhen tërësisht nga ajri.

Komponenti i parë i kostos së certifikatës janë kostot e përgjithshme për shërbimin e një AK të akredituar. Kjo përfshin: koston e një certifikate CA, e cila gjithashtu paguhet, koston e një licence për softuer të certifikuar, koston e sigurimit të masave organizative për mbrojtjen e të dhënave personale, etj. Kështu përcaktohet kostoja, për shembull, e një certifikate personale të një individi. Kjo bën të mundur nënshkrimin e skedarëve lokalë, dokumenteve në faqet e internetit të shërbimit publik dhe mesazheve postare.

Komponenti i dytë i kostos së certifikatës shfaqet kur përdoruesi dëshiron të përdorë certifikatën e tij, për shembull, për të punuar në platformat e tregtimit elektronik. Sipas rregulloreve aktuale, faqja e platformës elektronike të tregtimit vërteton klientin nëse plotësohen tashmë dy kushte: së pari, nëse certifikata nuk ka skaduar, certifikata nuk është revokuar dhe nënshkrimi i saj është i vlefshëm. Dhe së dyti, nëse certifikata thotë qartë se është krijuar për të punuar në një sit specifik. Hyrja për këtë duket si një hyrje e rregullt në të njëjtën tabelë që ruan pjesën tjetër të të dhënave të certifikatës. Për çdo hyrje të tillë në çdo certifikatë përdoruesi, qendra e certifikimit jep një shumë të caktuar. E cila kërkon të kompensojë në kurriz të pronarit të certifikatës. Prandaj, certifikatat që lejojnë hyrjen në platformat e tregtimit elektronik janë më të shtrenjta.

Kërcënimet dhe sulmet

Ndryshe nga enkriptimi, në rastin e një nënshkrimi elektronik, detyra kryesore e sulmuesit nuk është të marrë tekstin e deshifruar, por të jetë në gjendje të falsifikojë ose prodhojë një nënshkrim elektronik të një dokumenti arbitrar. Kjo do të thotë, relativisht, jo për deshifrim, por për enkriptim. Me kusht - sepse algoritmet moderne të specializuara të nënshkrimit dixhital, siç u përmend më lart, nuk e kodojnë hash-in e dokumentit, por kryejnë operacione matematikore të ngjashme në kuptim, por teknikisht të ndryshëm, mbi të.

Sipas standardeve të miratuara në Federatën Ruse, gjatë nënshkrimit elektronik të dokumenteve, përdoren algoritme kriptografike që korrespondojnë me Standardi shtetëror RF (GOST R). Në kohën e shkrimit të këtij teksti (gjysma e dytë e 2016), për asnjë nga algoritmet që lidhen me EDS dhe që kanë statusin e një standardi në Federatën Ruse, metodat e sulmit janë të panjohura që janë dukshëm të ndryshme në kompleksitet nga numërimi i thjeshtë. Në praktikë, kjo do të thotë se është më e lehtë për një sulmues, niveli i aksesit të të cilit në burimet kompjuterike është më i ulët se ai i një shteti të madh, të përpiqet të vjedhë çelësin sesa të hakojë algoritmin dhe të falsifikojë një nënshkrim.

Kështu, në rastin e një nënshkrimi elektronik, vektorët kryesorë të sulmit synojnë marrjen e çelësit sekret nga sulmuesi. Nëse çelësi ruhet në një skedar në disk, ai mund të vidhet në çdo kohë duke marrë aksesin e duhur të leximit. Për shembull, me ndihmën e një virusi. Nëse çelësi ruhet në formë të koduar, ai mund të merret në momentin e aplikimit - për shembull, kur programi që kryen nënshkrimin elektronik ka deshifruar tashmë çelësin dhe përpunon të dhënat me të. Në këtë rast, detyra bëhet shumë më e ndërlikuar - ju duhet të gjeni një dobësi në program, ose do të duhet të deshifroni vetë çelësin. Pavarësisht nga ndërlikimet e rëndësishme të detyrës, ajo ende mbetet mjaft reale. Për specialistët e fushës përkatëse, i përket kategorisë së rutinës.

Është e mundur të komplikohet edhe më shumë detyra e marrjes së një çelësi sekret nga një sulmues duke e vendosur çelësin sekret në një medium të veçantë harduerësh në mënyrë të tillë që çelësi të mos largohet kurrë nga kufijtë e kësaj pajisjeje fizike. Në këtë rast, një sulmues mund të fitojë akses te çelësi vetëm duke vjedhur pajisjen fizike. Humbja e pajisjes do të jetë një sinjal për pronarin se çelësi është vjedhur. Në çdo rast tjetër - dhe kjo është nuanca më e rëndësishme - vjedhja e çelësit mund të kalojë pa u vënë re, dhe pronari i çelësit nuk do ta zbulojë me kohë se është e nevojshme të kontaktojë urgjentisht AK-në dhe të revokojë vlefshmërinë e certifikatës së tij .

Këtu përsëri, analogjia me kartë bankare, i cili është një mjet vërtetimi për të hyrë në një llogari bankare. Ndërsa ajo është me pronarin, ai është i qetë. Nëse karta humbet, duhet ta bllokoni menjëherë. Në këtë rast, detyra e sulmuesit nuk është të vjedhë kartën, por të bëjë në mënyrë diskrete një kopje të saj në mënyrë që pronari të mos bllokojë aksesin. Për argumentet moderne të harduerit, metodat e klonimit janë aktualisht të panjohura.

Shenjat

Për momentin, termi përgjithësisht i pranuar për pajisjet fizike individuale të përdorura për ruajtjen e çelësave të nënshkrimit elektronik është simbol. Shenjat mund të lidhen me një kompjuter nëpërmjet USB-së, Bluetooth-it ose përmes pajisjeve të veçanta të lexuesit. Shumica e argumenteve moderne përdorin ndërfaqen USB. Por ndryshimi kryesor midis llojeve të argumenteve nuk është në ndërfaqen e lidhjes. Shenjat mund të ndahen në dy lloje - ato që përdoren në të vërtetë vetëm si një dyqan çelësash dhe ato që "mund" të kryejnë vetë operacione kriptografike.

Shenjat e llojit të parë ndryshojnë nga disqet e zakonshme flash në thelb vetëm në atë që të dhënat mund të lexohen prej tyre vetëm me ndihmën e softuerit special. Përndryshe, ky është një ruajtje e rregullt e të dhënave të jashtme, dhe nëse ruajmë një çelës sekret në të, atëherë kushdo që ka të drejtën për të hyrë në pajisje dhe di të lexojë çelësin prej saj mund ta vjedhë atë. Shenja të tilla quhen argumente softuerësh dhe praktikisht nuk ofrojnë ndonjë avantazh në krahasim me ruajtjen e çelësit në një disk kompjuteri - pronari i çelësit gjithashtu nuk mund të jetë i sigurt se ai i di të gjitha vendet ku ruhet çelësi i tij sekret.

Shenjat e llojit të dytë quhen argumente harduerike, dhe ndryshimi i tyre kryesor është se çelësi sekret është i pa rikuperueshëm - ai kurrë nuk i lë kufijtë e tokenit. Për ta bërë këtë, një grup i veçantë softuerësh vendoset në token, i cili aktivizohet kur token lidhet me kompjuterin. Në fakt, një shenjë e tillë është një pajisje e pavarur informatike me procesorin, memorien dhe aplikacionet e veta që komunikon me një kompjuter.

Çelësi sekret nuk largohet kurrë nga tokeni i harduerit sepse ai gjenerohet pikërisht në vetë token. Për të nënshkruar një dokument, hash-i i dokumentit ngarkohet në token, llogaritjet bëhen drejtpërdrejt "në bord" të tokenit duke përdorur çelësin sekret të ruajtur atje dhe nënshkrimi i përfunduar ngarkohet përsëri. Kështu, duke ditur vendndodhjen e tokenit, ne gjithmonë e dimë vendndodhjen e çelësit sekret.

Një nga karakteristikat kryesore të një tokeni të harduerit është grupi i algoritmeve kriptografike të mbështetura. Për shembull, nëse duam të përdorim një shenjë harduerike për të vërtetuar në kompjuterin tonë të shtëpisë, çdo token modern do ta bëjë këtë. Dhe nëse duam të vërtetojmë në portalin e Shërbimeve Shtetërore, atëherë na duhet një shenjë që mbështet algoritme kriptografike të certifikuara në Rusi.

Më poshtë janë listat e mekanizmave kriptografikë të mbështetur për tokenat eToken dhe JaCarta GOST. Për të kërkuar një listë mekanizmash, mjeti i hapur pkcs11-tool u përdor me parametrin "-M" (nga fjala "mekanizëm"), i cili mund të veprojë si një aplikacion klienti për çdo bibliotekë që zbaton ndërfaqen PKCS # 11 në saj. drejtimin. libeToken.so dhe libjcPKCS11.so.1 përdoren si biblioteka PKCS#11 për eToken dhe JaCarta, respektivisht. Biblioteka për eToken shpërndahet si pjesë e softuerit SafeNet, biblioteka për JaCarta është e disponueshme për shkarkim nga faqja e internetit e Aladdin R.D.

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M Mekanizmat e mbështetur: DES-MAC, keySize=(8,8), nënshkruaj, verifiko DES-MAC-GENERAL, keySize=( 8,8), nënshkruani, verifikoni DES3-MAC, keySize=(24,24), nënshkruani, verifikoni DES3-MAC-GENERAL, keySize=(24,24), nënshkruani, verifikoni AES-MAC, keySize=(16,32 ), nënshkruani, verifikoni AES-MAC-GENERAL, keySize=(16,32), nënshkruani, verifikoni RC4, keySize=(8,2048), kriptoni, deshifroni DES-ECB, keySize=(8,8), enkriptoni, dekriptoni , mbështjellë, hap DES-CBC, keySize=(8,8), enkripto, deshifro, mbështjell, hap DES-CBC-PAD, keySize=(8,8), enkripto, deshifro, mbështjell, hap DES3-ECB, keySize= (24,24), hw, enkripto, dekriptoj, mbështjell, hap DES3-CBC, keySize=(24,24), hw, enkripto, deshifro, mbështjell, hap DES3-CBC-PAD, keySize=(24,24), hw, enkripto, deshifroj, mbështjell, shpalos AES-ECB, keySize=(16,32), enkripto, deshifro, mbështjell, hap AES-CBC, keySize=(16,32), kripto, deshifro, mbështjell, shpalos AES-CBC -PAD, keySize=(16,32), enkripto, deshifro, mbështjell, hap mechtype-0x1086, keySize=(16,32), enkripto, deshifro, mbështjell, shpalos mec htype-0x1088, keySize=(16,32), enkripto, deshifro, mbështjell, çmbështjell RSA-PKCS-KEY-PAIR-GEN, keySize=(1024,2048), hw, gjeneroj_key_çift RSA-PKCS, keySize=(1024,2048 ), hw, enkripto, deshifroj, nënshkruaj, shënj_rikuper, verifiko, verifiko_rikuper, mbështjell, hap RSA-PKCS-OAEP, keySize=(1024,2048), hw, enkrip, deshifro, mbështjell, shpalos RSA-PKCS-PSS, keySize= (1024,2048), hw, shenjë, verifiko SHA1-RSA-PKCS-PSS, keySize=(1024,2048), hw, shenjë, verifiko mechtype-0x43, keySize=(1024,2048), hw, shëno, verifiko mechtype -0x44, keySize=(1024,2048), hw, shenjë, verifiko mechtype-0x45, keySize=(1024,2048), hw, shenjë, verifiko RSA-X-509, keySize=(1024,2048), hw, enkripto , deshifroni, nënshkruani, shënoni_rikuperoni, verifikoni, verifikoni_rikuperoni, mbështillni, hapni , verifikoni SHA256-RSA-PKCS, keySize=(1024,2048), hw, nënshkruani, verifikoni SHA384-RSA-PKCS, keySize=(1024,2048), hw , nënshkruani, verifikoni SHA512-RSA-PKCS, keySize=(1024 ,2048), hw, nënshkruani, verifikoni RC4-KEY-GEN, keySize=(8,204 8), gjeneroni DES-KEY-GEN, keySize=(8,8), gjeneroni DES2-KEY-GEN, keySize=(16,16), gjeneroni DES3-KEY-GEN, keySize=(24,24), gjeneroni AES -KEY-GEN, keySize=(16,32), gjeneroni PBE-SHA1-RC4-128, keySize=(128,128), gjeneroni PBE-SHA1-RC4-40, keySize=(40,40), gjeneroni PBE-SHA1- DES3-EDE-CBC, keySize=(24,24), gjeneroni PBE-SHA1-DES2-EDE-CBC, keySize=(16,16), gjeneroni GENERIC-SECRET-KEY-GEN, keySize=(8,2048), hw, gjeneroni PBA-SHA1-WITH-SHA1-HMAC, keySize=(160,160), hw, gjeneroni PBE-MD5-DES-CBC, keySize=(8,8), gjeneroni PKCS5-PBKD2, gjeneroni MD5-HMAC-GENERAL, keySize=(8,2048), shëno, verifiko MD5-HMAC, keySize=(8,2048), shëno, verifiko SHA-1-HMAC-GENERAL, keySize=(8,2048), nënshkruaj, verifiko SHA-1-HMAC , keySize=(8,2048), shëno, verifiko mechtype-0x252, keySize=(8,2048), shëno, verifiko mechtype-0x251, keySize=(8,2048), shëno, verifiko mechtype-0x262, keySize=(8 ,2048), shëno, verifiko mechtype-0x261, keySize=(8,2048), shëno, verifiko mechtype-0x272, keySize=(8,2048), firmo, verifiko mechtype-0x271, keySize=(8,2 048), nënshkruaj, verifiko MD5, tret SHA-1, tret SHA256, tret SHA384, tret SHA512, tret mechtype-0x80006001, keySize=(24,24), gjeneron $ pkcs11-tool --module /usr/local/6 libjcPKCS11.pra. 1 -M Mekanizmat e mbështetur: GOSTR3410-KEY-PAIR-GEN, hw, generoj_key_pair GOSTR3410, hw, sign, verifiko GOSTR3410-WITH-GOSTR3411, hw, sign, verifiko mechtype-0x1204, GOSTRh20x1, die GOSTRhw3, die , gjeneroni mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001

Mund të shihet se lista e mekanizmave të mbështetur për eToken është shumë e gjatë, por nuk përfshin algoritmet GOST. Lista e mekanizmave të mbështetur JaCarta përfshin vetëm algoritmet GOST, por në sasinë e nevojshme për të zbatuar funksionalitetin EDS në një shenjë harduerike.

Është e rëndësishme të kuptohet se argumentet moderne të harduerit në përgjithësi mund të përdoren gjithashtu si argumente softuerësh. Kjo do të thotë, ata zakonisht kanë një zonë të vogël memorie të aksesueshme nga jashtë, e cila, nëse dëshironi, mund të përdoret për të regjistruar dhe ruajtur një çelës sekret të krijuar nga jashtë. Teknologjikisht, kjo nuk ka kuptim, por në fakt, kjo metodë përdoret, për fat të keq, mjaft gjerësisht. Fatkeqësisht, sepse shpesh pronari i tokenit nuk e di që tokeni i tij modern i harduerit, i blerë sinqerisht jo për një tarifë nominale, përdoret si një softuer.

Shembuj të argumenteve ekskluzivisht të softuerit përfshijnë Rutoken S dhe Rutoken Lite. Si shembuj të shenjave harduerike që nuk mbështesin algoritme kriptografike të çertifikuara në Rusi, ekzistojnë pajisje "eToken"; si kriptografi ruse mbështetëse - "Rutoken EDS", "JaCarta GOST".

Ofruesit e kriptove

Softueri që i siguron operatorit akses në funksionet kriptografike - nënshkrimi elektronik, enkriptimi, deshifrimi, hashimi - quhet ofrues kriptografik, ofrues i funksioneve kriptografike. Në rastin e një tokeni harduer, ofruesi kriptografik zbatohet drejtpërdrejt në token, në rastin e një token softuerësh ose në rastin e ruajtjes së çelësave në një disk kompjuteri, ai zbatohet si një aplikacion i zakonshëm i përdoruesit.

Nga pikëpamja e sigurisë së të dhënave të përdoruesit, një nga vektorët kryesorë të sulmit i drejtohet ofruesit të kriptove - është në kujtesën e ofruesit të kriptove që çelësi sekret deshifrohet. Në rast të një sulmi të suksesshëm, një sulmues do të jetë në gjendje të zëvendësojë kodin e aplikacionit me kodin e tij dhe të bëjë një kopje të çelësit sekret, edhe nëse çelësi zakonisht ruhet në formë të koduar. Prandaj, në rastin e përdorimit të kriptografisë për kryerjen e një nënshkrimi elektronik që ka fuqi ligjore, shteti kërkon të mbrojë qytetarët nga rrjedhjet e mundshme të çelësave sekretë. Kjo shprehet në faktin se për të punuar me një nënshkrim elektronik të kualifikuar, zyrtarisht lejohet të përdoren vetëm ofruesit e kriptove që kanë certifikatën e duhur dhe, për rrjedhojë, kanë kaluar kontrollet e duhura.

Ofruesit e kriptove të çertifikuar në Federatën Ruse për EDS përfshijnë, në veçanti: Rutoken EDS, JaCarta GOST, CryptoPro CSP, LISSI-CSP, VipNet CSP. Dy të parat zbatohen drejtpërdrejt në argumentet e harduerit, pjesa tjetër janë në formën e aplikacioneve të përdoruesve. Është e rëndësishme të kuptohet se kur blejmë një token harduerësh të çertifikuar në Federatën Ruse, ne tashmë po blejmë një ofrues kriptosh të certifikuar në Federatën Ruse dhe nuk ka nevojë - teknologjike dhe ligjore - për të blerë një ofrues tjetër kriptosh.

Përveç grupit të algoritmeve të mbështetura, ofruesit kriptografikë ndryshojnë gjithashtu në grupin e funksioneve kriptografike - kriptimi dhe deshifrimi i dokumenteve, nënshkrimi dhe verifikimi i një nënshkrimi, prania e një ndërfaqeje grafike të përdoruesit, etj. Për më tepër, nga i gjithë ky grup funksionesh, një ofrues kriptografik i certifikuar duhet të kryejë vetëm ato që lidhen drejtpërdrejt me zbatimin e algoritmeve kriptografike. Çdo gjë tjetër mund të bëhet nga një aplikacion i palës së tretë. Kjo është saktësisht se si ofruesit e kriptove punojnë në argumentet e harduerit: ndërfaqja e përdoruesit zbatohet nga një aplikacion i palës së tretë që nuk i nënshtrohet certifikimit të detyrueshëm. Aplikacioni që implementon ndërfaqen e përdoruesit komunikon me ofruesin kriptografik në token përmes një ndërfaqeje tjetër standarde - PKCS#11. Në të njëjtën kohë, nga këndvështrimi i përdoruesit, puna me çelësat ndodh, për shembull, drejtpërdrejt nga shfletuesi Firefox html. Në fakt, shfletuesi, përmes ndërfaqes PKCS # 11, përdor një shtresë të veçantë softueri që zbaton mekanizmat për të hyrë në një token specifik harduer.

Përveç termit "ofrues kriptografik", ekziston një term tjetër që është i afërt në kuptim - "mjetet e mbrojtjes së informacionit kriptografik" (CIPF). Nuk ka asnjë dallim të qartë midis këtyre dy koncepteve. Termi i parë është më pak zyrtar, i dyti përdoret më shpesh në lidhje me zgjidhjet teknike të certifikuara. Meqenëse ky dokument përshkruan kryesisht aspekte teknologjike sesa formale, ne do të përdorim më shpesh termin "kriptoprovues".

Zbatimi i mekanizmave

Algoritmet e nënshkrimit elektronik

Aktualisht, në Federatën Ruse, vetëm dy algoritme nënshkrimi dhe dy algoritme hash lejohen zyrtarisht të përdoren për një nënshkrim elektronik të kualifikuar. Deri në fund të vitit 2017, lejohet përdorimi i GOST R 34.10-2001 në lidhje me algoritmin hash GOST R 34.11-94. Që nga fillimi i vitit 2018, lejohen të përdoren vetëm GOST R 34.10-2012 dhe hash në përputhje me GOST R 34.11-2012. Në situatat kur përdorimi i detyrueshëm i algoritmeve GOST nuk kërkohet, mund të përdoret çdo algoritëm i disponueshëm.

Për shembull, tani shumica e faqeve të internetit të aksesueshme përmes protokollit HTTP nuk dinë të përdorin algoritmet GOST për vërtetimin e ndërsjellë të klientit dhe serverit. Në rastin e ndërveprimit me një nga këto faqe, pala e klientit do të duhet gjithashtu të aplikojë algoritme "të prodhuara nga jashtë". Por, për shembull, nëse dëshironi të përdorni një shenjë harduerike si një dyqan kyç për vërtetim në faqen e internetit të Shërbimeve Shtetërore, do t'ju duhet të zgjidhni një shenjë me mbështetje EDS sipas GOST.

Nevoja për të përdorur algoritme ruse kur bashkëveproni me agjencitë qeveritare nuk është aspak për shkak të dëshirës për të kufizuar qytetarët në zgjedhjen e tyre. Arsyeja është se shteti, pasi ka investuar në zhvillimin e këtyre algoritmeve, është përgjegjës për forcën e tyre kriptografike dhe mungesën e veçorive të padeklaruara në to. Të gjithë algoritmet kriptografike të standardizuara në Federatën Ruse kanë kaluar vazhdimisht një auditim të pavarur dhe kanë vërtetuar bindshëm vlerën e tyre. E njëjta gjë mund të thuhet për shumë algoritme të tjera të zakonshme kriptografike. Por, për fat të keq, mungesa e aftësive të padeklaruara në to nuk mund të vërtetohet me të njëjtën lehtësi. Është fare e qartë se nga pikëpamja e shtetit, është e paarsyeshme përdorimi i mjeteve jo të besueshme, për shembull, për të përpunuar të dhënat personale të qytetarëve.

Ndërfaqet, formatet dhe protokollet

Për të siguruar përputhshmërinë kur punoni me një nënshkrim elektronik, janë zhvilluar një sërë standardesh ndërkombëtare në lidhje me ruajtjen e të dhënave dhe sigurimin e aksesit në to. Standardet kryesore përfshijnë:

  • PC/SC - ndërfaqe e nivelit të ulët për akses në pajisjet kriptografike, duke përfshirë softuerin dhe tokenat e harduerit;
  • PKCS#11 - një ndërfaqe e nivelit të lartë për ndërveprim me modulet kriptografike harduerike, mund të konsiderohet si një ndërfaqe e unifikuar për aksesimin e ofruesve kriptografikë;
  • PKCS#15 - format kontejner me çelësa nënshkrimi elektronik, i destinuar për ruajtje në një pajisje fizike;
  • PKCS#12, PEM - formatet e kontejnerëve me çelësa nënshkrimi elektronik të destinuar për ruajtje në skedarë, përkatësisht binar dhe tekst;
  • PKCS#10 - format dokumenti - një kërkesë nënshkrimi e dërguar nga një klient te një AK për të marrë një certifikatë të nënshkruar.

Është e rëndësishme të kuptohet se standarde të tilla si PKCS#11 ose PKCS#15 fillimisht u zhvilluan pa marrë parasysh specifikat e kriptomonedhave të certifikuara në Federatën Ruse. Prandaj, për të zbatuar mbështetje të plotë për kriptografinë vendase, standardet duhej dhe ende duhet të finalizohen. Procesi i miratimit të ndryshimeve në standarde është i gjatë, prandaj, derisa standardet e finalizuara u miratuan përfundimisht, u shfaqën zbatime të tyre të papajtueshme me njëra-tjetrën. Në veçanti, kjo vlen për ofruesit e kriptove të çertifikuar në Federatën Ruse. Pra, tani të gjithë ofruesit e certifikuar të kriptove kanë zbatime të papajtueshme të kontejnerëve për ruajtjen e çelësave në një shenjë. Sa i përket standardeve të shkëmbimit të të dhënave - PKCS # 10, PKCS # 12, PEM - zbatimet e tyre, për fat të mirë, zakonisht janë të pajtueshme me njëri-tjetrin. Gjithashtu, zakonisht nuk ka mospërputhje në interpretimin e standardit PC / SC.

Çështjet e finalizimit të standardeve, zhvillimin e rekomandimeve, sigurimin e përputhshmërisë në fushën e EDS në Federatën Ruse aktualisht po trajtohen nga një organizatë e veçantë - Komiteti Teknik për Standardizimin "Mbrojtja e Informacionit Kriptografik" (TK 26), i cili përfshin ekspertë, përfaqësues të agjencitë qeveritare, zhvilluesit e ofruesve kriptografikë dhe palët e tjera të interesuara. Mund të diskutohet për efektivitetin e punës së komisionit, por edhe vetë ekzistenca e një platforme të tillë është jashtëzakonisht e rëndësishme.

Pjesa e softuerit

Rafti i softuerit për të punuar me një nënshkrim elektronik përbëhet nga komponentët e mëposhtëm:

  • zbatimi i një ndërfaqeje për qasje të nivelit të ulët në kontejnerët e magazinimit me çelësa - për shembull, një ndërfaqe PC / SC për qasje në pajisjet fizike - argumentet;
  • një modul që zbaton ndërfaqen PKCS#11 për ndërveprim me një ofrues kriptografik - për shembull, i implementuar në një shenjë harduerike;
  • një ofrues kriptografik që zbaton algoritmet përkatëse kriptografike dhe kryen veprime me to - për shembull, një nënshkrim elektronik ose kriptim të të dhënave;
  • një aplikacion përdoruesi që ndërvepron me tjetrin - në lidhje me ofruesin kriptografik - me modulin PKCS # 11 dhe kryen operacione të tilla si nënshkrimi elektronik ose vërtetimi në emër të përdoruesit.

Shembull i stivës:

  • Aplikacioni i linjës së komandës cryptcp nga softueri CryptoPro CSP ndërvepron me bibliotekën libcppksc11.so përmes ndërfaqes PKCS#11 dhe ofron mundësinë për të nënshkruar dokumente me çelësin sekret të përdoruesit; në të njëjtën kohë, funksionet e ofruesit të kriptove zbatohen plotësisht në komponentët e softuerit CryptoPro CSP, ofruesi i kriptove të tokenit të harduerit nuk është i përfshirë.

Një shembull tjetër:

  • softueri i hapur pcsc-lite zbaton ndërfaqen PC/SC për ndërveprim me tokenin e harduerit Rutoken EDS;
  • biblioteka libcppksc11.so nga softueri CryptoPro CSP ofron ndërveprim me kontejnerin e vendosur në token, i cili ruan çelësin privat dhe certifikatën e përdoruesit;
  • aplikacioni "CryptoPro EDS Browser plugin", i cili funksionon si pjesë e shfletuesit Firefox html, ndërvepron me bibliotekën libcppksc11.so përmes ndërfaqes PKCS # 11 dhe ofron mundësinë për të nënshkruar dokumente në ndërfaqen e shfletuesit në faqet elektronike kate tregtare; në të njëjtën kohë, funksionet e ofruesit të kriptove zbatohen plotësisht në komponentët e softuerit CryptoPro CSP, ofruesi i kriptove të tokenit të harduerit nuk është i përfshirë.

Shembulli i tretë:

  • softueri i hapur pcsc-lite zbaton ndërfaqen PC/SC për ndërveprim me tokenin e harduerit Rutoken EDS;
  • biblioteka librtpksc11.so e prodhuar nga Aktiv ofron ndërveprim me ofruesin kriptografik të tokenit;
  • ofruesi kriptografik i tokenit kryen funksionet e nënshkrimit të të dhënave të transmetuara në të me një çelës sekret; çelësi sekret nuk i lë kufijtë e shenjës;
  • aplikacioni Rutoken Plugin që funksionon si pjesë e shfletuesit Firefox html ndërvepron me bibliotekën librtpksc11.so përmes ndërfaqes PKCS # 11 dhe ofron mundësinë për të nënshkruar dokumente në ndërfaqen e shfletuesit në sajte të përputhshme; në të njëjtën kohë, funksionet e ofruesit kriptografik zbatohen plotësisht në një shenjë harduerike.

Zgjedhja e një zbatimi specifik të pirgut aktualisht përcaktohet, para së gjithash, nga tre faktorë - qëllimi i synuar i EDS, niveli i njohurive teknike të përdoruesit dhe gatishmëria e qendrës së certifikimit për të punuar me një kërkesë për nënshkrimin e certifikatës. .

Përveç grupit të softuerit nga ana e përdoruesit të listuar më sipër, ka edhe dy aplikacione të tjera që duhet të merren parasysh. I pari është softueri që i shërben qendrës së certifikimit. E dyta është softueri me të cilin duam të jemi të pajtueshëm. Për shembull, faqja e internetit e Shërbimeve Shtetërore. Ose softuer për nënshkrimin e dokumenteve elektronike.

Nëse autoriteti i certifikimit ku ne planifikojmë të marrim një certifikatë nuk është i gatshëm të punojë me kërkesat e nënshkrimit në formatin PKCS # 10 dhe mund të punojë vetëm me tokenat e softuerit (d.m.th., ai percepton çdo shenjë si softuer), ne nuk kemi zgjidhje. Si rregull, në këtë rast, softueri CA do të gjenerojë një çift çelësash për ne, do ta shkruajë atë në token, do të gjenerojë menjëherë një kërkesë nënshkrimi bazuar në çelësin publik dhe të dhënat tona personale, do ta nënshkruajë atë dhe do ta ruajë certifikatën në token. . Certifikata dhe çelësi do të jenë në një kontejner me format të mbyllur të njohur vetëm për zhvilluesin e softuerit CA. Prandaj, për të hyrë në kontejnerin me çelësa, do t'ju duhet të blini një ofrues kriptografik nga i njëjti zhvillues. Dhe fushëveprimi i EDS do të kufizohet nga aftësitë e softuerit të një zhvilluesi të veçantë. Në këtë rast, nuk ka kuptim të blini një shenjë harduerike - mund t'ia dilni me një softuer. Në këtë rast, token patjetër do të duhet të bartet në AK.

Nëse autoriteti i certifikimit ku ne planifikojmë të marrim një certifikatë është i gatshëm të punojë me kërkesat e nënshkrimit në formatin PKCS # 10, atëherë për ne nuk ka rëndësi se çfarë lloj softueri përdoret në këtë AK. Ne do të jemi në gjendje të përdorim ofruesin kriptografik që është në përputhje me aplikacionet tona të synuara. Për shembull, me platformat elektronike të tregtimit ose faqen e internetit të Shërbimeve Shtetërore. Në këtë rast, nuk keni nevojë ta bartni tokenin në AK, mjafton të gjeneroni një kërkesë nënshkrimi dhe ta paraqisni atje së bashku me dokumentet tuaja në letër; merrni një certifikatë dhe ruajeni vetë në token me ndihmën e ofruesit të zgjedhur të kriptos.

Fatkeqësisht, shumë pak AK janë aktualisht (në fund të vitit 2016) të gatshme për të punuar me një kërkesë nënshkrimi. Kjo situatë është pjesërisht për shkak të mungesës së trajnim teknik përdoruesit të cilët nuk janë në gjendje të sigurojnë që kërkesa e nënshkrimit të ekzekutohet siç duhet - me të gjitha atributet e nevojshme dhe vlerat e tyre. Ky udhëzues synon të zgjidhë këtë problem.

Hardware

Ndër ato të paraqitura në tregu rus argumentet përfshijnë sa vijon:

Media harduerike me mbështetje për kriptografinë ruse: Rutoken EDS, JaСarta GOST, MS_KEY K.

Le të shqyrtojmë si shembull listat e mekanizmave kriptografikë të mbështetur të harduerit Rutoken EDS dhe softuerit Rutoken_Lite:

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Mekanizmat e mbështetur: RSA-PKCS-KEY-PAIR-GEN, keySize=(512,2048), hw,gene_key_pair RSA-PKCS, keySize=( 512,2048), hw, enkripto, deshifro, nënshkruar, verifiko RSA-PKCS-OAEP, keySize=(512,2048), hw, enkripto, deshifro MD5, tret SHA-1, tret GOSTR3410-KEY-PAIR-GEN, hw , gjeneroni_çift_çelës GOSTR3410, hw, shenjë, verifikoni mechtype-0x1204, hw, nxirrni GOSTR3411, hw, përmbledh GOSTR3410-ME-GOSTR3411, hw, përmbledh, nënshkrim mechtype-0x12wraphw24, uncrypth, wrapx1, uncrypth, mechtype-0x1222, hw, enkripto, deshifroj mechtype-0x1220, hw, gjeneron mechtype-0x1223, hw, shëno, verifiko $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Mekanizmat e mbështetur: -M:

Siç mund ta shihni, listat e mekanizmave kriptografikë të mbështetur Rutoken Lite janë bosh, ndryshe nga Rutoken EDS, i cili përfshin algoritmet GOST dhe RSA.

Shenjat e harduerit pa mbështetje për kriptografinë ruse, siç u përmend më lart, përfshijnë, në veçanti, JaCarta PKI dhe eToken.

Duke pasur parasysh çmimet relativisht të ulëta për argumentet harduerike me mbështetje për kriptografinë ruse, ne mund t'ju rekomandojmë me besim përdorimin e tyre. Përveç avantazhit të dukshëm në formën e një çelësi sekret të pakthyeshëm, tokeni i harduerit përfshin gjithashtu një ofrues të certifikuar të kriptove. Kjo do të thotë, është e mundur të organizoni punën me shenjën në atë mënyrë që të mos keni nevojë të blini shtesë softuer të shtrenjtë.

Nga zhvillimet e fundit, do të doja të shënoja Rutoken EDS 2.0 me mbështetje për standardin GOST R 34.10-2012.

Aplikacion

Mjetet e Përdoruesit

Hap Veglat

Softueri me burim të hapur aktualisht ju lejon të zbatoni një grumbull pothuajse të plotë softuerësh për të punuar me EDS.

PCSC lite

Implementimi PC/SC i zhvilluar në kuadër të projektit PCSC lite është një referencë për familjen Linux OS. Përfshihet në cilindo nga variantet e grumbullit të softuerit të konsideruar në këtë dokument për të punuar me EDS. Në të ardhmen, nëse një opsion specifik zbatimi nuk specifikohet, ne do ta konsiderojmë atë të aktivizuar si parazgjedhje.

OpenSC

Biblioteka që zbaton ndërfaqen PKCS#11, si dhe një grup mjetesh aplikacioni që përdorin funksionalitetin e saj, u zhvillua si pjesë e projektit OpenSC. Paketa e veglave mbështet shumë argumente harduerike, përfshirë Rutoken EDS, mbështetja e së cilës u shtua nga specialistët e kompanisë Aktiv, e cila zhvillon shenja të familjes Rutoken.

Duke përdorur shërbimet OpenSC, mund të kryeni, në veçanti, veprimet e mëposhtme në një shenjë harduerike:

  • inicializoni shenjën - rivendosni cilësimet në gjendjen origjinale;
  • vendos kodin PIN të administratorit dhe përdoruesit (nëse mbështetet);
  • gjeneroni një çift çelësash (nëse mbështetet nga biblioteka PKCS#11);
  • importoni një certifikatë të nënshkruar nga një autoritet certifikues në token.

Biblioteka PKCS#11 nga paketa OpenSC ju lejon të kryeni një grup të plotë të operacioneve të nënshkrimit elektronik në argumentet e mbështetur. Shenjat e mbështetur përfshijnë gjithashtu Rutoken EDS.

Është e rëndësishme të kuptohet këtu se për Rutoken EDS ekzistojnë dy opsione të ndryshme të mbështetjes së softuerit që nuk janë në përputhje me njëra-tjetrën për sa i përket formatit për ruajtjen e çelësave në token. Kur përdorim bibliotekën PKCS # 11 nga OpenSC, ne mund të përdorim grumbullin e hapur të softuerit, dhe kur përdorim bibliotekën e mbyllur të shpërndarë falas të prodhuar nga Aktiv, mund të përdorim raftin e mbyllur Aktiva.

OpenSSL

Për të përdorur plotësisht aftësitë e EDS, përveç vetë bibliotekës PKCS # 11, duhet të zbatohen aplikacione të përdoruesve që i ofrojnë operatorit akses në funksionet e bibliotekës dhe aftësitë e shenjave. Një shembull kryesor i një zbatimi të tillë është softueri me burim të hapur nga projekti OpenSSL. Ai mbështet veçoritë e mëposhtme:

  • enkriptimi i të dhënave;
  • deshifrimi i të dhënave;
  • nënshkrimi i dokumentit;
  • verifikimi i nënshkrimit;
  • gjenerimi i një kërkese për nënshkrimin e certifikatës;
  • importi i certifikatës;
  • certifikatë eksporti.

Përveç kësaj, duke përdorur OpenSSL, ju mund të zbatoni funksionalitetin e një autoriteti certifikues të plotë, duke përfshirë:

  • lëshimi i certifikatave të klientit duke nënshkruar kërkesat e nënshkrimit në formatin PKCS#10;
  • revokimin e certifikatave të klientit;
  • regjistrimin e certifikatave të lëshuara dhe të revokuara.

E vetmja mangësi e OpenSSL për momentin, e cila nuk lejon ende zbatimin e një versioni të plotë të softuerit EDS bazuar në softuer me burim të hapur, është mungesa e një moduli të hapur për ndërveprim me bibliotekat PKCS # 11 me mbështetje për Algoritmet GOST. Ekziston një zbatim i mbyllur i një moduli të tillë, i bërë nga Aktiv, por ai nuk përfshihet në shpërndarjen bazë OpenSSL, dhe për këtë arsye, me lëshimin e versioneve të reja të OpenSSL, përputhshmëria prishet periodikisht. Zbatimi i hapur i këtij moduli nuk mbështet ende algoritmet GOST.

Firefox

Përveç OpenSSL, shfletuesi i mirënjohur Firefox html mund të ndërveprojë edhe me bibliotekat PKCS # 11. Për të lidhur bibliotekën PKCS # 11, duhet të shkoni te menyja e menaxhimit të cilësimeve "Preferencat", më pas zgjidhni "Advanced" në listën vertikale në të majtë, zgjidhni "Certifikatat" në listën horizontale, klikoni butonin "Pajisjet e sigurisë". , në kutinë e dialogut që shfaqet, klikoni butonin "Ngarko". Do të shfaqet një dritare tjetër me opsionin për të zgjedhur shtegun për në skedar me bibliotekën PKCS#11 dhe opsionin për të futur emrin lokal për atë bibliotekë të veçantë. Në këtë mënyrë mund të ngarkoni disa module të ndryshme PKCS#11 për lloje të ndryshme pajisjesh fizike dhe virtuale.

Fatkeqësisht, funksionaliteti i Firefox-it nuk është ende i mjaftueshëm për të nënshkruar dokumente në ndërfaqen e faqes së internetit. Prandaj, për një pirg të plotë softuerësh të hapur EDS me mbështetje GOST, ende nuk ka mjaft plug-in (prizë) që ju lejon të aksesoni objektet në token nga softueri i faqes. Shpresojmë që një shtojcë e tillë të shkruhet në të ardhmen e afërt. Ose të hapur.

CryptoPro

Në versionet e CryptoPro CSP deri në dhe duke përfshirë 4.0, menaxhimi manual i cache-ve lokale përdoret për të ruajtur certifikatat e përdoruesve dhe certifikatat CA. Për punë të plotë me një certifikatë përdoruesi, është e nevojshme që kopja e saj të jetë në një memorie lokale, dhe zinxhiri i plotë i certifikatave CA deri në dhe duke përfshirë rrënjën - në një tjetër. Teknologjikisht, kjo veçori e CryptoPro, në mënyrë rigoroze, nuk është plotësisht e justifikuar: ka kuptim të kontrolloni zinxhirin gjatë vërtetimit; fakti aktual i vlefshmërisë së certifikatës nuk ndikon në mundësinë e nënshkrimit. Sidomos nëse është certifikata jonë dhe e dimë se nga ka ardhur. Të reja në kohën e shkrimit të versioneve beta të CryptoPro CSP, sipas zhvilluesve, është zbatuar ngarkimi automatik i zinxhirit të certifikatave CA. Por sigurimi që vetëm ai që është aktualisht në përdorim të jetë në memorien lokale të certifikatave të përdoruesve duket se duhet ende të monitorohet manualisht.

Zhvilluesit e palëve të treta po bëjnë përpjekje për të shkruar ndërfaqe grafike për CryptoPro CSP, duke lehtësuar operacionet rutinë të përdoruesit. Një shembull i një mjeti të tillë është rosa-crypto-tool, i cili automatizon nënshkrimin dhe enkriptimin e dokumenteve. Paketa në shpërndarjet ALT.

CryptoPro CA

Softueri Lissi SOFT karakterizohet nga respektimi i rreptë i standardeve dhe specifikimeve teknike. Ofruesit e kriptove, përfshirë ato unike, janë krijuar si biblioteka PKCS#11. Sipas zhvilluesve, ato përshtaten mirë me softuerin me burim të hapur, i cili gjithashtu është i fokusuar në mbështetjen e standardeve. Për shembull, me shfletues html dhe shërbime nga kompleti OpenSSL.

Në lidhje me organizimin e aksesit në faqet e shërbimeve publike, produktet Lissy SOFT janë gjithashtu me interes. Para së gjithash - pajtueshmëria me "IFCPlugin" - një shtojcë e shfletuesit që zbaton mekanizmat EDS në portalin e Shërbimeve Shtetërore. Së dyti, aftësia e softuerit të autoritetit të certifikimit për të punuar me kërkesat për nënshkrimin e certifikatës në formatin PKCS#10.

Shfletuesit

Ndonjëherë, për të hyrë në faqet ku planifikojmë të përdorim mekanizmat e nënshkrimit elektronik, duhet të përdorim teknologji të tjera që përdorin kriptografinë ruse. Për shembull, algoritmet GOST mund të përdoren për të organizuar një kanal të koduar të transmetimit të të dhënave. Në këtë rast, kërkohet mbështetje për algoritmet e duhura në shfletues. Fatkeqësisht, ndërtimet zyrtare të Firefox dhe Chromium nuk e mbështesin ende plotësisht kriptografinë ruse. Prandaj, duhet të përdorni asamble alternative. Asamble të tilla janë, për shembull, në arsenalin e mjeteve kriptomatike të kompanive "CryptoPro" dhe "Lissy SOFT", si dhe në shpërndarjet Alt.

Faqet

Ndër faqet që kërkojnë përdorimin e teknologjive të nënshkrimit elektronik, ne jemi të interesuar kryesisht për faqet që ofrojnë shërbime publike, si dhe platformat elektronike të tregtimit (ETP). Fatkeqësisht, disa ETP nuk e mbështesin ende punën me OS nga Regjistri i Softuerit Rus. Por situata gradualisht po ndryshon për mirë.

Përdorimi i EDS për faqet e internetit zakonisht zbret në vërtetimin dhe nënshkrimin e dokumenteve të krijuara në ndërfaqen e faqes. Në parim, vërtetimi duket i njëjtë me nënshkrimin e çdo dokumenti tjetër: faqja në të cilën klienti dëshiron të vërtetojë gjeneron një sekuencë karakteresh që i dërgon klientit. Klienti kthen nënshkrimin e kësaj sekuence të bërë duke përdorur çelësin e tij privat dhe certifikatën e tij (certifikata është pak më e hershme). Sajti merr çelësin publik nga certifikata e klientit dhe verifikon nënshkrimin e sekuencës origjinale. E njëjta gjë vlen edhe për nënshkrimin e dokumenteve. Këtu, në vend të një sekuence arbitrare, shfaqet vetë dokumenti.

Sherbime Publike

Si rezultat i studimit, rezultoi se që nga 14 dhjetori 2016, shumica e platformave tregtare federale - "", "RTS-tender" dhe "Sberbank-AST" janë gati për përdorim në vendet e punës që përdorin sisteme operative Linux. Dy faqet e mbetura nuk ofrojnë ende mundësinë për t'u identifikuar me një certifikatë klienti. Nëse zhvilluesit e tyre po planifikojnë ndonjë masë për të siguruar përputhshmërinë, për fat të keq, ende nuk është zbuluar.

Në të njëjtën kohë, në udhëzimet zyrtare të të gjitha faqeve, përveç Platformës së Unifikuar të Tregtisë Elektronike, sistemi operativ Windows tregohet si i vetmi i mbështetur. Përgjigjet zyrtare nga shërbimet e mbështetjes teknike konfirmojnë këtë informacion. Udhëzimet në faqen e internetit të Platformës së Tregtisë Elektronike të Bashkuar përshkruajnë cilësimet e shfletuesit pa specifikuar një sistem operativ specifik.

Në një formë të përmbledhur, rezultatet e studimit janë dhënë në tabelë:

Tregu elektronik Mundësia për t'u identifikuar me një certifikatë përdoruesi Aftësia për të nënshkruar një dokument në ndërfaqen e platformës Dokumentacioni për punën me sitin nën OS nga Regjistri
Sberbank - Sistemi i automatizuar i tregtimit po po Jo
Platforma e unifikuar e tregtimit elektronik po po po

Për ETP-të që ofrojnë përputhshmëri me Linux-in, i vetmi mjet i mbështetur kripto për momentin është shtojca Cades, e cila mund të përdorë vetëm CryptoPro CSP si një ofrues kriptosh. Kështu, lajmi i mirë është se është shumë e lehtë të marrësh një shenjë për akses në platformat e tregtimit elektronik - shumica e CA-ve i lëshojnë ato. Lajm i keq - token do të jetë i bazuar në softuer dhe nuk do të jetë i pajtueshëm me faqen e internetit të Shërbimeve Shtetërore.

Për platformat e tjera tregtare, mënyra e vetme për të hyrë në funksionalitetin EDS është komponenti i Windows OS i quajtur CAPICOM. Specialistët e Etersoft kryen punë kërkimore, si rezultat i së cilës u qartësua mundësia teorike e lëshimit të CAPICOM në mjedisin e verës.

Faqe të tjera

Përveç faqeve të listuara që përdorin drejtpërdrejt EDS - për të hyrë në sit dhe për të nënshkruar dokumentet e krijuara në ndërfaqen e faqes, ka një numër faqesh që ofrojnë mundësinë për të shkarkuar dokumente të nënshkruara më parë me një nënshkrim elektronik të kualifikuar. Një shembull është faqja e qendrës kryesore të radiofrekuencave. Qasja në sit kryhet me hyrje dhe fjalëkalim, dhe dokumentet përgatiten dhe nënshkruhen paraprakisht - në ndërfaqen e OS të përdoruesit. Kështu, për të punuar me faqe të tilla, nevojitet vetëm funksionaliteti i nënshkrimit të dokumentit lokal. Kjo do të thotë, praktikisht nuk ka kufizime në zgjedhjen e një ofruesi të kriptove në këtë rast.

Shembull i një zgjidhjeje me çelës në dorë

Për fat të keq, për momentin, autorët e këtij dokumenti nuk dinë të përdorin të njëjtin kod në të njëjtën kohë në faqen e internetit të Shërbimeve Shtetërore dhe në platformat elektronike të tregtimit. Prandaj, do t'ju duhet të bëni dy shenja me dy palë çelësash dhe dy certifikata, respektivisht. Nuk është e ndaluar ligjërisht, teknikisht është e realizueshme. Financiarisht, është gjithashtu mjaft realiste: një shenjë do të jetë, për shembull, një Rutoken EDS harduerike, tjetra do të jetë një model i vjetër eToken, i cili tani mund të gjendet me një tarifë nominale.

Qasje në faqen e internetit të Shërbimeve Shtetërore

Për të hyrë në Shërbimet Shtetërore, merrni Rutoken EDS dhe kryeni hapat e mëposhtëm:

  1. shkarkoni softuerin e shtojcave Rutoken nga faqja në lidhje;
  2. instaloni shtojcën Rutoken - kopjoni skedarët e shtojcave (npCryptoPlugin.so dhe librtpkcs11ecp.so) në ~/.mozilla/plugins/ ;
  3. shkoni në sit me softuerin e Qendrës së Regjistrimit dhe ndiqni udhëzimet për të kryer veprimet e mëposhtme - inicializoni shenjën, gjeneroni një çift çelësash, gjeneroni dhe ruani një skedar lokal me një kërkesë për një nënshkrim në formatin PKCS # 10;
  4. ne do të kontaktojmë AK-në, e cila është e gatshme të na lëshojë një certifikatë me kërkesë për nënshkrim, do të marrim një certifikatë në formën e dosjes;
  5. në ndërfaqen "Qendra e Regjistrimit", ruani certifikatën nga skedari i marrë në shenjë;
  6. shkarkoni paketën e formatit "deb" nga lidhja - skedari IFCPlugin-x86_64.deb ;
  7. duke përdorur softuerin "Midnight Commander" (komandë mc ) "shko" në skedarin e paketës si në një direktori;
  8. kopjoni përmbajtjen e drejtorisë PËRMBAJTJA/usr/lib/mozilla/plugins në drejtorinë lokale ~/.mozilla/plugins;
  9. në shfletuesin Firefox në faqen e internetit të Shërbimeve Shtetërore, ne do të ndjekim lidhjet "Hyrja" dhe "Hyrja duke përdorur mjete elektronike" në sekuencë.

Problemi kryesor në zbatimin e këtij udhëzimi është gjetja e një autoriteti certifikues që është i gatshëm të punojë me një kërkesë nënshkrimi.

Qasje në platformat elektronike të tregtimit

Për të hyrë në faqet e platformave të tregtimit elektronik që mbështesin punën në Linux, kryeni hapat e mëposhtëm:

  1. me çdo shenjë të shitur zyrtarisht në Federatën Ruse, ne do të kontaktojmë çdo qendër certifikimi duke përdorur CryptoPro CA dhe do të marrim certifikatën e përdoruesit dhe çelësin sekret të ruajtur në token në një enë të formatit të mbështetur nga softueri CryptoPro;
  2. në përputhje me udhëzim instaloni softuerin "CryptoPro CSP" dhe "Cades plugin" për shfletuesin Chromium;
  3. duke përdorur shfletuesin Chromium, ne do të shkojmë në faqet e platformave të tregtimit elektronik dhe do të fillojmë të punojmë me to sipas udhëzimeve zyrtare.

Mundësia për të nënshkruar dokumente në formën e skedarëve do të jetë e disponueshme përmes shërbimeve të konsolës CryptoPro dhe përmes aplikacioneve mbështjellëse të palëve të treta, si mjeti i përmendur tashmë rosa-crypto.