Leserne inviteres til undersøkelser, hvor det ble identifisert en rekke problemer med bruken av digitale signaturverktøy som oppstår for Linux-brukere. Spesielt ble følgende ikke helt åpenbare punkter funnet ut:

• muligheten til å få og bruke et personlig elektronisk sertifikat digital signatur for tilgang til offentlige tjenester i dag gis kun mot et gebyr av kommersielle organisasjoner;
• databærere elektronisk signatur, utstedt til sluttbrukere av forskjellige autoriserte organisasjoner, kan være inkompatible både med hverandre og med portaler som gir tilgang til tjenester, inkludert offentlige;
• Sikkerhetsnivået til databærere for elektronisk signatur som er massivt utstedt til sluttbrukere, er som regel betydelig redusert i forhold til det teknologiske nivået som er tilgjengelig i dag;
• for flertallet av OS-brukere fra Register av innenlandsk programvare, EDS-mekanismer på enkelt portal offentlige tjenester er ikke tilgjengelige på grunn av inkompatibiliteten til EPGU-programvaren og programvaren til autoriserte organisasjoner som utsteder personlige elektroniske signatursertifikater;
• i noen tilfeller utviklere av portaler som tilbyr offentlige tjenester, anbefaler å bruke operativsystemer som ikke er inkludert i registeret, samt programvareverktøy og konfigurasjoner som bevisst reduserer sikkerheten til brukerdata.

Forfatterne av arbeidet forventer at de oppnådde resultatene vil være nyttige for brukere av løsninger som bruker EDS-mekanismer, integratorer som implementerer relevante løsninger, og vil også bli tatt i betraktning av organisasjoner som er ansvarlige for å tilby staten informasjonstjenester og for implementering av spesifikke EDS-infrastrukturmekanismer, så vel som av utviklerne av tilsvarende programvare og maskinvare.

Hva handler det om

Artikkelen er viet til støtte for elektronisk digital signatur (EDS) av dokumenter i ALT OS, samt spesifikasjonene for bruken av EDS i den russiske føderasjonen.

Hovedoppgaven er å forstå hva den "vanlige brukeren" ™ trenger å gjøre - det spiller ingen rolle om det er en enkeltperson eller en juridisk enhet - som handler på felles grunnlag for å fullt ut bruke mulighetene til elektroniske handelsplattformer og portaler for offentlige tjenester mens du arbeider i OS fra Register of Domestic Software. "Full bruk" betyr først og fremst muligheten for autentisering på det tilsvarende nettstedet ved hjelp av et sertifikat plassert på et eget fysisk medium, og muligheten for elektronisk signering av dokumenter generert i nettstedets grensesnitt.

En rekke forskningsarbeider er allerede utført på dette emnet, resultatet av dette var konklusjonen at i prinsippet fungerer alt. Det er viktig å forstå her at de fleste av studiene av kompatibilitet med portalene til statlige tjenester i den russiske føderasjonen av moderne kryptografiske verktøy som kjører under Linux OS ble utført under laboratorieforhold. For eksempel hvis det er spesielle avtaler mellom forskeren og sertifiseringsmyndigheten som utsteder sertifikatet. Dessverre, basert på resultatene av slikt arbeid, er det vanskelig å bedømme de reelle evnene til personer som handler på felles grunnlag.

Hvordan det hele fungerer

For å komme inn på nettstedet uten å angi pålogging og passord, men ganske enkelt ved å koble et maskinvaretoken til USB-kontakten, er det nødvendig at en spesialisert programvarestabel fungerer riktig i operativsystemet: støtte for fysiske enheter, kryptografiske algoritmer, programvaregrensesnitt, formater og protokoller for datautveksling. Samtidig må kompatibiliteten til kryptografiske algoritmer, formater og protokoller også sikres utenfor operativsystemets ansvarsområde - i sertifiseringsmyndigheten som utsteder sertifikatet, og på nettstedet som det er nødvendig å levere til. adgang.

Og hvis vi snakker om nettstedene til offentlige etater, er det også nødvendig at kryptovalutaene som brukes er sertifisert for riktig bruk i Den russiske føderasjonen.

Grunnleggende mekanismer

EDS-teknologi, offisielt brukt i den russiske føderasjonen, er basert på offentlig nøkkelinfrastruktur. La oss ta en titt på hvordan det fungerer med et eksempel.

For klarhet, la oss vurdere virkningsmekanismen til universelle algoritmer som er egnet for både elektronisk signatur og kryptering. Disse algoritmene inkluderer blant annet RSA Internett-standarden og den russiske GOST R 34.10-94, som var i kraft i den russiske føderasjonen som en elektronisk signaturstandard frem til 2001. Mer moderne EDS-algoritmer, som blant annet inkluderer den nåværende GOST R 34.10-2001 og GOST R 34.10-2012, er som regel spesialiserte. De er utelukkende ment for signering av dokumenter, og er ikke egnet for kryptering. Teknisk sett er forskjellen mellom spesialiserte algoritmer at hashen i deres tilfelle ikke er kryptert. I stedet for å kryptere den, utføres også andre beregninger på den ved hjelp av den private nøkkelen, hvis resultat lagres som en signatur. Ved verifisering av en signatur utføres de tilsvarende komplementære beregningene vha offentlig nøkkel. Tapet av universalitet i dette tilfellet er en betaling for en høyere kryptografisk styrke. Eksemplet nedenfor med en universell algoritme er kanskje litt mindre relevant, men sannsynligvis mer forståelig for en uforberedt leser.

Dokumentsignatur

Så for å danne en elektronisk signatur i en offentlig nøkkelinfrastruktur, brukes et asymmetrisk krypteringsskjema, som er preget av bruken av et par nøkler. Det som er kryptert med en av disse nøklene kan bare dekrypteres av den andre nøkkelen i paret. En av nøklene til paret kalles hemmelig, eller privat, og holdes så hemmelig som mulig, den andre kalles offentlig, eller åpen, og distribueres fritt - som regel som en del av et sertifikat. I tillegg til nøkkelen inneholder det elektroniske signatursertifikatet informasjon om eieren av sertifikatet, samt signaturen til nøkkelen, sammen med informasjon om eieren, laget av en betrodd part. Dermed inneholder sertifikatet allerede en elektronisk signatur som bekrefter at informasjonen om eieren tilsvarer nøkkelparet.

Organisatorisk utføres denne signaturen av en sertifiseringsmyndighet (CA) - en juridisk enhet som er delegert myndighet til å etablere og bekrefte korrespondansen til eieren og nøkkelen. Samsvar etableres etter presentasjon av papirdokumenter, og det bekreftes nøyaktig av en elektronisk signatur, som er praktisk å vurdere bare ved å lage et sertifikat.

Sertifiseringsinstansen for signering av klientsertifikater har også et par nøkler. Bekreftet informasjon om eieren av sertifikatet i form av en spesialdesignet tabell kombineres til ett dokument med dens offentlige nøkkel. Dette dokumentet går deretter gjennom to transformasjoner. For det første gjør hash-funksjonen dokumentet til en unik sekvens av tegn med fast lengde (hash). Deretter blir den resulterende hashen kryptert med den private nøkkelen til sertifiseringsmyndigheten. Resultatet av kryptering er den faktiske elektroniske signaturen. Den er vedlagt det signerte dokumentet, i dette tilfellet informasjon om brukeren og nøkkelen hans, og distribueres sammen med den. Alt dette sammen - et dokument med informasjon om brukeren og hans offentlige nøkkel, samt signaturen til dette dokumentet med den offentlige nøkkelen til CA, er utarbeidet på en spesiell måte og kalles et brukersertifikat.

Akkurat som for brukerdata som en del av et sertifikat, utstedes en elektronisk signatur av ethvert annet dokument. For eksempel en fil med en applikasjon for en tjeneste. Filen hashes, den resulterende hashen krypteres med brukerens hemmelige nøkkel og festes til dokumentet. Resultatet er et signert dokument.

Signaturbekreftelse

Som vanligvis er tilfellet med asymmetrisk kryptering, kan det som er kryptert med en nøkkel bare dekrypteres av den andre nøkkelen i paret. Så, når det gjelder et sertifikat, kan den krypterte hashen til et dokument som inneholder brukerens offentlige nøkkel og verifisert informasjon om brukeren dekrypteres ved å bruke den offentlige nøkkelen til sertifiseringsmyndigheten, som distribueres fritt som en del av sertifiseringsmyndighetens sertifikat. Dermed vil alle som mottar et CA-sertifikat kunne få den dekrypterte hashen fra brukersertifikatet. Siden hash-funksjonen produserer et unikt resultat, ved å bruke det på et dokument som inneholder brukerens offentlige nøkkel og informasjon om den, kan du sjekke om disse to hashene stemmer overens. Hvis de er det, har vi det samme dokumentet som ble signert av sertifiseringssenteret, og informasjonen i det kan stole på. Hvis ikke, stemmer ikke signaturen med dokumentet, og vi har en falsk.

Situasjonen med å sjekke CA-sertifikatet er nøyaktig den samme - det er også signert med en nøkkel. Som et resultat ender kjeden av signerte sertifikater med et "root"-sertifikat, som er selvsignert. Et slikt sertifikat kalles selvsignert. For offisielt akkrediterte sertifiseringssentre i den russiske føderasjonen er rotsertifikatet sertifikatet til hovedsertifiseringssenteret til departementet for telekom og massekommunikasjon.

I tillegg til informasjon om brukeren og hans offentlige nøkkel, inneholder sertifikatet noen tilleggsdata - spesielt sertifikatets gyldighetsperiode. Hvis minst ett sertifikat i kjeden har utløpt, anses signaturen som ugyldig.

Signaturen vil også bli ansett som ugyldig hvis klientsertifikatet trekkes tilbake av CA. Muligheten til å tilbakekalle et sertifikat er nyttig, for eksempel i situasjoner der den hemmelige nøkkelen lekkes. En analogi med å kontakte en bank i tilfelle tap av et bankkort er passende.

Tjenester av sertifiseringssentre

Så sertifiseringssenteret med sin signatur bekrefter korrespondansen til en viss offentlig nøkkel til et bestemt sett med poster. Teoretisk sett er kostnadene for en CA for å signere ett sertifikat nær null: selve signaturen er en godt automatisert, ikke veldig dyr beregningsoperasjon på moderne utstyr. Samtidig betales tjenestene til UC. Men i motsetning til CA-ene som utsteder sertifikater for nettsteder, er ikke penger her tjent helt ut av løse luften.

Den første komponenten av kostnaden for sertifikatet er overheadkostnadene for å betjene en akkreditert CA. Dette inkluderer: kostnaden for et CA-sertifikat, som også betales, kostnaden for en lisens for sertifisert programvare, kostnaden for å sikre organisatoriske tiltak for å beskytte personopplysninger, og så videre. Slik fastsettes kostnaden for for eksempel et personlig sertifikat til en enkeltperson. Som gjør det mulig å signere lokale filer, dokumenter på offentlige nettsteder og postmeldinger.

Den andre komponenten av kostnaden for sertifikatet vises når brukeren ønsker å bruke sertifikatet sitt, for eksempel til å arbeide på elektroniske handelsplattformer. I følge gjeldende regelverk, nettstedet til den elektroniske handelsplattformen autentiserer klienten under to forhold: først, selvfølgelig, hvis sertifikatet ikke har utløpt, er sertifikatet ikke tilbakekalt og signaturen er gyldig. Og for det andre, hvis sertifikatet tydelig sier at det er designet for å fungere på et bestemt nettsted. Oppføringen for dette ser ut som en vanlig oppføring i samme tabell som lagrer resten av sertifikatdataene. For hver slik oppføring i hvert brukersertifikat gir sertifiseringssenteret et visst beløp. Som søker å kompensere på bekostning av eieren av sertifikatet. Derfor er sertifikater som tillater adgang til elektroniske handelsplattformer dyrere.

Trusler og angrep

I motsetning til kryptering, er angriperens hovedoppgave ved elektronisk signatur ikke å skaffe den dekrypterte teksten, men å kunne forfalske eller produsere en elektronisk signatur av et vilkårlig dokument. Det vil si, relativt sett, ikke til dekryptering, men til kryptering. Betinget - fordi moderne spesialiserte digitale signaturalgoritmer, som nevnt ovenfor, ikke krypterer hashen til dokumentet, men utfører matematiske operasjoner med lignende betydning, men teknisk forskjellige, på det.

I henhold til standardene vedtatt i den russiske føderasjonen, ved elektronisk signering av dokumenter, brukes kryptografiske algoritmer som tilsvarer Statlig standard RF (GOST R). På tidspunktet for skriving av denne teksten (andre halvdel av 2016), for ingen av algoritmene relatert til EDS og har status som en standard i den russiske føderasjonen, er angrepsmetoder ukjente som er vesentlig forskjellige i arbeidsintensitet fra enkel oppregning. I praksis betyr dette at det er lettere for en angriper, hvis tilgangsnivå til dataressurser er lavere enn for en stor stat, å prøve å stjele nøkkelen enn å hacke algoritmen og forfalske en signatur.

Når det gjelder en elektronisk signatur, er derfor hovedangrepsvektorene rettet mot å skaffe den hemmelige nøkkelen av angriperen. Hvis nøkkelen er lagret i en fil på disk, kan den bli stjålet når som helst ved å få riktig lesetilgang. For eksempel ved hjelp av et virus. Hvis nøkkelen er lagret i kryptert form, kan den fås ved søknadstidspunktet – for eksempel når programmet som utfører den elektroniske signaturen allerede har dekryptert nøkkelen og behandler dataene med den. I dette tilfellet blir oppgaven mye mer komplisert - du må finne en sårbarhet i programmet, eller du må dekryptere nøkkelen selv. Til tross for den betydelige komplikasjonen av oppgaven, er den fortsatt ganske reell. For spesialister på det aktuelle feltet hører det til kategorien rutine.

Det er mulig å komplisere oppgaven med å skaffe en hemmelig nøkkel av en angriper enda mer betydelig ved å plassere den hemmelige nøkkelen på et eget maskinvaremedium på en slik måte at nøkkelen aldri forlater grensene til denne fysiske enheten. I dette tilfellet kan en angriper bare få tilgang til nøkkelen ved å stjele den fysiske enheten. Tapet av enheten vil være et signal til eieren om at nøkkelen er stjålet. I alle andre tilfeller - og dette den viktigste nyansen- tyveriet av nøkkelen kan gå ubemerket hen, og eieren av nøkkelen vil ikke vite i tide at det er nødvendig å snarest kontakte CA og tilbakekalle gyldigheten av sertifikatet hans.

Også her er analogien med et bankkort, som er et autentiseringsverktøy for å få tilgang til en bankkonto, passende. Mens hun er hos eieren er han rolig. Hvis kortet går tapt, må du umiddelbart sperre det. I dette tilfellet er angriperens oppgave ikke å stjele kortet, men å diskret lage en kopi av det slik at eieren ikke blokkerer tilgangen. For moderne maskinvaretokens er kloningsmetoder foreløpig ukjente.

Tokens

For øyeblikket er den generelt aksepterte betegnelsen for individuelle fysiske enheter som brukes til å lagre elektroniske signaturnøkler token. Tokens kan kobles til en datamaskin via USB, Bluetooth eller gjennom spesielle leserenheter. De fleste moderne tokens bruker USB-grensesnittet. Men hovedforskjellen mellom typene tokens er ikke i tilkoblingsgrensesnittet. Tokens kan deles inn i to typer - de som faktisk bare brukes som nøkkellager, og de som "kan" utføre kryptografiske operasjoner på egenhånd.

Tokens av den første typen skiller seg fra vanlige flash-stasjoner i hovedsak bare ved at data bare kan leses fra dem ved hjelp av spesiell programvare. Ellers er dette en vanlig ekstern datalagring, og hvis vi lagrer en hemmelig nøkkel i den, så kan alle som får tilgangsrettigheter til enheten og vet hvordan de skal lese nøkkelen fra den stjele den. Slike tokens kalles programvaretokens og gir praktisk talt ingen fordeler sammenlignet med å lagre nøkkelen på en datadisk – eieren av nøkkelen kan heller ikke være sikker på at han kjenner alle stedene der den hemmelige nøkkelen hans er lagret.

Tokens av den andre typen kalles hardware-tokens, og hovedforskjellen deres er at den hemmelige nøkkelen ikke kan gjenopprettes - den forlater aldri grensene for tokenet. For å gjøre dette plasseres et spesielt sett med programvare på tokenet, som aktiveres når tokenet kobles til datamaskinen. Faktisk er en slik token en uavhengig dataenhet med sin egen prosessor, minne og applikasjoner som kommuniserer med en datamaskin.

Den hemmelige nøkkelen forlater aldri maskinvaretokenet fordi det genereres rett på selve tokenet. For å signere et dokument, lastes hashen til dokumentet inn i tokenet, beregninger gjøres direkte "om bord" på tokenet ved å bruke den hemmelige nøkkelen som er lagret der, og den ferdige signaturen lastes opp tilbake. Når vi derfor kjenner plasseringen til tokenet, vet vi alltid plasseringen til den hemmelige nøkkelen.

En av hovedkarakteristikkene til et maskinvaretoken er settet med støttede kryptografiske algoritmer. For eksempel, hvis vi ønsker å bruke et maskinvaretoken for å autentisere på hjemmedatamaskinen vår, vil ethvert moderne token gjøre det. Og hvis vi ønsker å autentisere på State Services-portalen, trenger vi et token som støtter kryptografiske algoritmer sertifisert i Russland.

Nedenfor er lister over støttede kryptografiske mekanismer for eToken og JaCarta GOST-tokens. For å be om en liste over mekanismer ble det åpne verktøyet pkcs11-tool brukt med parameteren "-M" (fra ordet "mekanisme"), som kan fungere som en klientapplikasjon for ethvert bibliotek som implementerer PKCS # 11-grensesnittet i sitt retning. libeToken.so og libjcPKCS11.so.1 brukes som PKCS#11-biblioteker for henholdsvis eToken og JaCarta. Biblioteket for eToken distribueres som en del av SafeNet-programvaren, biblioteket for JaCarta er tilgjengelig for nedlasting fra nettstedet til Aladdin R.D.

$ pkcs11-tool --module /usr/local/lib64/libeToken.so.9.1.7 -M Støttede mekanismer: DES-MAC, keySize=(8,8), signere, verifisere DES-MAC-GENERAL, keySize=( 8,8), signere, verifisere DES3-MAC, keySize=(24,24), signere, verifisere DES3-MAC-GENERAL, keySize=(24,24), signere, verifisere AES-MAC, keySize=(16,32 ), signer, verifiser AES-MAC-GENERAL, keySize=(16,32), signer, verifiser RC4, keySize=(8,2048), krypter, dekrypter DES-ECB, keySize=(8,8), krypter, dekrypter , wrap, unwrap DES-CBC, keySize=(8,8), krypter, dekrypter, wrap, unwrap DES-CBC-PAD, keySize=(8,8), krypter, dekrypter, wrap, unwrap DES3-ECB, keySize= (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), krypter, dekrypter, wrap, unwrap AES-CBC -PAD, keySize=(16,32), krypter, dekrypter, wrap, unwrap mechtype-0x1086, keySize=(16,32), krypter, dekrypter, wrap, unwrap mec htype-0x1088, keySize=(16,32), krypter, dekrypter, wrap, unwrap RSA-PKCS-KEY-PAIR-GEN, keySize=(1024,2048), hw, gener_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 , dekryptere, signere, sign_recover, verify, verify_recover, wrap, unwrap , verify SHA256-RSA-PKCS, keySize=(1024,2048), hw, sign, verify SHA384-RSA-PKCS, keySize=(1024,2048), hw , signere, verifisere SHA512-RSA-PKCS, keySize=(1024 ,2048), hw, signere, verifisere RC4-KEY-GEN, keySize=(8,204 8), generer DES-KEY-GEN, keySize=(8,8), generer DES2-KEY-GEN, keySize=(16,16), generer DES3-KEY-GEN, keySize=(24,24), generer AES -KEY-GEN, keySize=(16,32), generer PBE-SHA1-RC4-128, keySize=(128,128), generer PBE-SHA1-RC4-40, keySize=(40,40), generer PBE-SHA1- DES3-EDE-CBC, keySize=(24,24), generer PBE-SHA1-DES2-EDE-CBC, keySize=(16,16), generer GENERIC-SECRET-KEY-GEN, keySize=(8,2048), hw, generer PBA-SHA1-WITH-SHA1-HMAC, keySize=(160,160), hw, generer PBE-MD5-DES-CBC, keySize=(8,8), generer PKCS5-PBKD2, generer 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), signer, verifiser MD5, digest SHA-1, digest SHA256, digest SHA384, digest SHA512, digest mechtype-0x80006001, keySize=(24,24), generer $ pkcs11-tool --module /usr/local/lib64/ libjcPKCS11.so. 1 -M Støttede mekanismer: GOSTR3410-Key-Pair-Gen, HW, Generate_Key_Pair GOSTR3410, HW, Sign, bekreft GOSTR3410-With-GOSTR3411, HW, Sign, Verify MechType-0x1204, HESPE, DECE2 , generer mechtype-0xC4321101 mechtype-0xC4321102 mechtype-0xC4321103 mechtype-0xC4321104 mechtype-0xC4900001

Det kan sees at listen over støttede mekanismer for eToken er veldig lang, men inkluderer ikke GOST-algoritmer. Listen over støttede JaCarta-mekanismer inkluderer bare GOST-algoritmer, men i mengden som er nødvendig for å implementere EDS-funksjonaliteten på et maskinvaretoken.

Det er viktig å forstå at moderne maskinvaretokens generelt også kan brukes som programvaretokens. Det vil si at de vanligvis har et lite minneområde tilgjengelig fra utsiden, som om ønskelig kan brukes til å registrere og lagre en eksternt generert hemmelig nøkkel. Teknologisk gir dette ingen mening, men faktisk brukes denne metoden, dessverre, ganske mye. Dessverre, fordi eieren av tokenet ofte ikke vet at hans moderne maskinvaretoken, ærlig kjøpt ikke for en nominell avgift, brukes som en programvare.

Eksempler på utelukkende programvaretokens inkluderer Rutoken S og Rutoken Lite. Som eksempler på maskinvaretokens som ikke støtter kryptografiske algoritmer sertifisert i Russland, er det "eToken"-enheter; som støtte for russisk kryptografi - "Rutoken EDS", "JaCarta GOST".

Krypto-leverandører

Programvare som gir operatøren tilgang til kryptografiske funksjoner – elektronisk signatur, kryptering, dekryptering, hashing – kalles en kryptografisk leverandør, en leverandør av kryptografiske funksjoner. Når det gjelder et maskinvaretoken, implementeres den kryptografiske leverandøren direkte på tokenet, i tilfelle av et programvaretoken eller ved lagring av nøkler på en datadisk implementeres den som en vanlig brukerapplikasjon.

Fra et synspunkt om sikkerheten til brukerdata er en av hovedangrepsvektorene rettet mot kryptoleverandøren - det er i minnet til kryptoleverandøren at den hemmelige nøkkelen dekrypteres. Ved et vellykket angrep vil en angriper kunne erstatte applikasjonskoden med sin egen og lage en kopi av den hemmelige nøkkelen, selv om nøkkelen normalt er lagret i kryptert form. Derfor, i tilfelle bruk av kryptografi for å utføre en elektronisk signatur som har rettskraft, søker staten å beskytte innbyggerne mot mulig lekkasje av hemmelige nøkler. Dette kommer til uttrykk i det faktum at for å jobbe med en kvalifisert elektronisk signatur, er det offisielt tillatt å bruke kun kryptoleverandører som har riktig sertifikat og derfor har bestått de nødvendige kontrollene.

Krypto-leverandører sertifisert i den russiske føderasjonen for EDS inkluderer spesielt: Rutoken EDS, JaCarta GOST, CryptoPro CSP", "LISSI-CSP", "VipNet CSP". De to første er implementert direkte på maskinvaretokens, resten er i form av brukerapplikasjoner. Det er viktig å forstå at når vi kjøper et maskinvaretoken sertifisert i den russiske føderasjonen, anskaffer vi allerede en kryptoleverandør sertifisert i den russiske føderasjonen, og det er ikke nødvendig - teknologisk og lovlig - å kjøpe en annen kryptoleverandør.

I tillegg til settet med støttede algoritmer, skiller kryptografiske leverandører seg også i et sett med kryptografiske funksjoner - kryptering og dekryptering av dokumenter, signering og verifisering av en signatur, tilstedeværelsen av et grafisk brukergrensesnitt, og så videre. Dessuten, av hele dette settet med funksjoner, må en sertifisert kryptografleverandør kun utføre de som er direkte relatert til implementeringen av kryptografiske algoritmer. Alt annet kan gjøres av en tredjepartsapplikasjon. Dette er nøyaktig hvordan kryptoleverandører jobber med maskinvaretokens: brukergrensesnittet implementeres av en tredjepartsapplikasjon som ikke er underlagt obligatorisk sertifisering. Applikasjonen som implementerer brukergrensesnittet kommuniserer med kryptografleverandøren på tokenet gjennom et annet standardgrensesnitt - PKCS#11. Samtidig, fra brukerens synspunkt, skjer arbeid med nøkler, for eksempel direkte fra Firefox html-nettleser. Faktisk bruker nettleseren, gjennom PKCS # 11-grensesnittet, et spesielt programvarelag som implementerer mekanismer for å få tilgang til et spesifikt maskinvaretoken.

I tillegg til begrepet "kryptografisk leverandør", er det et annet begrep som har nær betydning - "midler til kryptografisk informasjonsbeskyttelse" (CIPF). Det er ingen klar forskjell mellom disse to konseptene. Det første begrepet er mindre offisielt, det andre brukes oftere i forhold til sertifiserte tekniske løsninger. Siden dette dokumentet hovedsakelig beskriver teknologiske snarere enn formelle aspekter, vil vi bruke begrepet "kryptoleverandør" oftere.

Implementering av mekanismer

Elektroniske signaturalgoritmer

For øyeblikket, i den russiske føderasjonen, er det kun to signaturalgoritmer og to hashing-algoritmer som er offisielt tillatt å brukes for en kvalifisert elektronisk signatur. Frem til slutten av 2017 er det tillatt å bruke GOST R 34.10-2001 i forbindelse med GOST R 34.11-94 hashing-algoritmen. Siden begynnelsen av 2018 er det kun tillatt å bruke GOST R 34.10-2012 og hash i samsvar med GOST R 34.11-2012. I situasjoner der obligatorisk bruk av GOST-algoritmer ikke er nødvendig, kan alle tilgjengelige algoritmer brukes.

For eksempel, nå vet ikke de fleste nettsteder som er tilgjengelige via HTTP-protokollen hvordan de skal bruke GOST-algoritmer for gjensidig klient- og serverautentisering. I tilfelle interaksjon med en av disse nettstedene, vil klientsiden også måtte bruke "fremmedlagde" algoritmer. Men hvis du for eksempel vil bruke et maskinvaretoken som nøkkellager for autentisering på nettstedet til Statens tjenester, må du velge et token med EDS-støtte i henhold til GOST.

Behovet for å bruke russiske algoritmer i samhandling med offentlige etater skyldes ikke i det hele tatt ønsket om å begrense innbyggerne i deres valg. Årsaken er at staten, etter å ha investert i utviklingen av disse algoritmene, er ansvarlig for deres kryptografiske styrke og fraværet av uerklærte funksjoner i dem. Alle kryptografiske algoritmer standardisert i den russiske føderasjonen har gjentatte ganger bestått en uavhengig revisjon og overbevisende bevist deres verdi. Det samme kan sies om mange andre vanlige kryptografiske algoritmer. Men dessverre kan fraværet av uerklærte evner i dem ikke bevises med samme letthet. Det er helt klart at fra statens synspunkt er det urimelig å bruke upålitelige midler, for eksempel for å behandle personopplysninger til borgere.

Grensesnitt, formater og protokoller

For å sikre kompatibilitet ved arbeid med elektronisk signatur er det utviklet en rekke internasjonale standarder for lagring av data og tilgang til dem. Hovedstandardene inkluderer:

• PC/SC - lavnivågrensesnitt for tilgang til kryptografiske enheter, inkludert programvare- og maskinvaretokens;
• PKCS#11 - et høynivågrensesnitt for samhandling med maskinvarekryptografiske moduler, kan betraktes som et enhetlig grensesnitt for tilgang til kryptografiske leverandører;
• PKCS#15 - beholderformat med elektroniske signaturnøkler, beregnet for lagring på en fysisk enhet;
• PKCS#12, PEM - beholderformater med elektroniske signaturnøkler beregnet for lagring i filer, henholdsvis binær og tekst;
• PKCS#10 - dokumentformat - en signeringsforespørsel sendt av en klient til en CA for å motta et signert sertifikat.

Det er viktig å forstå at standarder som PKCS#11 eller PKCS#15 opprinnelig ble utviklet uten å ta hensyn til spesifikasjonene til kryptovalutaer sertifisert i den russiske føderasjonen. Derfor, for å implementere fullverdig støtte for innenlandsk kryptografi, måtte og må standardene ferdigstilles. Prosessen med å vedta endringer i standardene er lang, derfor, inntil de endelige standardene ble endelig vedtatt, dukket det opp at implementeringene deres var uforenlige med hverandre. Spesielt gjelder dette kryptoleverandører sertifisert i den russiske føderasjonen. Så nå har alle sertifiserte kryptoleverandører inkompatible containerimplementeringer for lagring av nøkler på et token. Når det gjelder datautvekslingsstandardene - PKCS # 10, PKCS # 12, PEM - er implementeringene deres, heldigvis, vanligvis kompatible med hverandre. Dessuten er det vanligvis ingen avvik i tolkningen av PC / SC-standarden.

Spørsmålene om å fullføre standarder, utvikle anbefalinger, sikre kompatibilitet innen EDS i Russland håndteres for tiden av en spesiell organisasjon - den tekniske komiteen for standardisering "Cryptographic Information Protection" (TK 26), som inkluderer eksperter, representanter for offentlige etater, utviklere av kryptografiske leverandører og andre interesserte mennesker. Man kan krangle om effektiviteten av utvalgets arbeid, men selve eksistensen av en slik plattform er ekstremt viktig.

Programvare del

Programvarestabelen for å arbeide med en elektronisk signatur består av følgende komponenter:

• implementering av et grensesnitt for lavnivåtilgang til lagringsbeholdere med nøkler - for eksempel et PC / SC-grensesnitt for tilgang til fysiske enheter - tokens;
• en modul som implementerer PKCS#11-grensesnittet for samhandling med en kryptografisk leverandør - for eksempel implementert på et maskinvaretoken;
• en kryptografisk leverandør som implementerer de tilsvarende kryptografiske algoritmene og utfører handlinger med dem - for eksempel en elektronisk signatur eller datakryptering;
• en brukerapplikasjon som samhandler med den andre - i forhold til den kryptografiske leverandøren - siden med PKCS # 11-modulen, og utfører operasjoner som elektronisk signatur eller autentisering på vegne av brukeren.

Stabeleksempel:

• cryptcp-kommandolinjeapplikasjonen fra CryptoPro CSP-programvaren samhandler med libcppksc11.so-biblioteket gjennom PKCS#11-grensesnittet og gir muligheten til å signere dokumenter med brukerens hemmelige nøkkel; samtidig er funksjonene til kryptoleverandøren fullt implementert i komponentene til CryptoPro CSP-programvaren, kryptoleverandøren av maskinvaretoken er ikke involvert.

Et annet eksempel:

• den åpne programvaren pcsc-lite implementerer PC/SC-grensesnittet for interaksjon med Rutoken EDS maskinvaretoken;
• libcppksc11.so-biblioteket fra CryptoPro CSP-programvaren gir interaksjon med beholderen som er vert på tokenet, som lagrer brukerens private nøkkel og sertifikat;
• applikasjonen "CryptoPro EDS Browser plugin", som fungerer som en del av Firefox html-nettleseren, samhandler med libcppksc11.so-biblioteket gjennom PKCS#11-grensesnittet og gir muligheten til å signere dokumenter i nettlesergrensesnittet på elektroniske nettsteder. handelsgulv; samtidig er funksjonene til kryptoleverandøren fullt implementert i komponentene til CryptoPro CSP-programvaren, kryptoleverandøren av maskinvaretoken er ikke involvert.

Tredje eksempel:

• den åpne programvaren pcsc-lite implementerer PC/SC-grensesnittet for interaksjon med Rutoken EDS maskinvaretoken;
• librtpksc11.so-biblioteket produsert av Aktiv gir interaksjon med den kryptografiske leverandøren av token;
• den kryptografiske leverandøren av tokenet utfører funksjonene for å signere dataene som er overført til den med en hemmelig nøkkel; den hemmelige nøkkelen forlater ikke grensene for tokenet;
• Rutoken Plugin-applikasjonen som kjører som en del av Firefox html-nettleseren samhandler med librtpksc11.so-biblioteket gjennom PKCS # 11-grensesnittet og gir muligheten til å signere dokumenter i nettlesergrensesnittet på kompatible nettsteder; samtidig er de kryptografiske leverandørfunksjonene fullt implementert på et maskinvaretoken.

Valget av en spesifikk stackimplementering bestemmes foreløpig, først av alt, av tre faktorer - det tiltenkte omfanget av EDS, nivået av teknisk kunnskap til brukeren og sertifiseringssenterets beredskap til å jobbe med en sertifikatsigneringsforespørsel.

I tillegg til settet med programvare på brukersiden som er oppført ovenfor, er det ytterligere to applikasjoner som må vurderes. Den første er programvaren som betjener sertifiseringssenteret. Den andre er programvaren vi ønsker å være kompatibel med. For eksempel nettstedet til Statens tjenester. Eller programvare for signering av elektroniske dokumenter.

Hvis sertifiseringsmyndigheten der vi planlegger å få et sertifikat ikke er klar til å jobbe med signeringsforespørsler i PKCS # 10-formatet og bare kan jobbe med programvaretokens (det vil si at den oppfatter et hvilket som helst token som programvare), har vi ikke noe valg. Som regel, i dette tilfellet vil CA-programvaren generere et nøkkelpar for oss, skrive det til tokenet, umiddelbart generere en signaturforespørsel basert på den offentlige nøkkelen og våre personlige data, signere den og lagre sertifikatet på tokenet . Sertifikatet og nøkkelen vil være i en lukket formatbeholder som kun er kjent for CA-programvareutvikleren. Følgelig, for å få tilgang til beholderen med nøkler, må du kjøpe en kryptografisk leverandør fra samme utvikler. Og omfanget av EDS vil være begrenset av mulighetene til programvaren til en spesifikk utvikler. I dette tilfellet gir det ingen mening å kjøpe et maskinvaretoken - du kan klare deg med en programvare. I dette tilfellet vil tokenet definitivt måtte bæres til CA.

Hvis sertifiseringsmyndigheten der vi planlegger å få et sertifikat er klar til å jobbe med signeringsforespørsler i PKCS # 10-formatet, spiller det ingen rolle for oss hva slags programvare som brukes i denne CA. Vi vil kunne bruke den kryptografiske leverandøren som er kompatibel med målapplikasjonene våre. For eksempel med elektroniske handelsplattformer eller nettstedet til Statens tjenester. I dette tilfellet trenger du ikke bære tokenet til CA, det er nok å generere en signaturforespørsel og presentere den der sammen med papirdokumentene dine; skaff deg et sertifikat, og lagre det på tokenet selv ved hjelp av den valgte kryptoleverandøren.

Dessverre er det svært få CAer som for øyeblikket (sent 2016) er klare til å jobbe med en signeringsforespørsel. Denne situasjonen skyldes delvis mangelen på teknisk trening brukere som ikke er i stand til å sikre at signaturforespørselen blir riktig utført - med alle nødvendige attributter og deres verdier. Denne veiledningen er ment å løse dette problemet.

Maskinvare

Blant de presentert på russisk marked tokens inkluderer følgende:

Maskinvaremedier med støtte for russisk kryptografi: Rutoken EDS, JaСarta GOST, MS_KEY K.

La oss som et eksempel vurdere listene over støttede kryptografiske mekanismer for maskinvare Rutoken EDS og programvare Rutoken_Lite:

$ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Støttede mekanismer: RSA-PKCS-KEY-PAIR-GEN, keySize=(512,2048), hw, gener_key_pair RSA-PKCS, keySize=( 512,2048), hw, krypter, dekrypter, signer, verifiser RSA-PKCS-OAEP, keySize=(512,2048), hw, krypter, dekrypter MD5, digest SHA-1, digest GOSTR3410-KEY-PAIR-GEN, hw , generere_nøkkelpar GOSTR3410, hw, signere, verifisere mechtype-0x1204, hw, utlede GOSTR3411, hw, digest GOSTR3410-WITH-GOSTR3411, hw, digest, signere mechtype-0x1224, hw, wrap-0, mech2type, decrypt, mech2type, decrypt, hx1 mechtype-0x1222, hw, krypter, dekrypter mechtype-0x1220, hw, generer mechtype-0x1223, hw, signer, verifiser $ pkcs11-tool --module /usr/local/lib64/librtpkcs11ecp.so -M Støttede mekanismer:

Som du kan se, er listene over støttede kryptografiske mekanismer Rutoken Lite tomme, i motsetning til Rutoken EDS, som inkluderer GOST- og RSA-algoritmer.

Maskinvaretokens uten støtte for russisk kryptografi, som nevnt ovenfor, inkluderer spesielt JaCarta PKI og eToken.

Gitt de relativt lave prisene for maskinvaretokens med støtte for russisk kryptografi, kan vi trygt anbefale å bruke dem. I tillegg til den åpenbare fordelen i form av en hemmelig nøkkel som ikke kan gjenopprettes, inkluderer maskinvaretokenet også en sertifisert kryptoleverandør. Det vil si at det er mulig å organisere arbeidet med tokenet på en slik måte at du ikke trenger å kjøpe dyr programvare i tillegg.

Av nyere utviklinger vil jeg merke meg Rutoken EDS 2.0 med støtte for GOST R 34.10-2012-standarden.

applikasjon

Brukerverktøy

Åpne Verktøy

Programvare med åpen kildekode lar deg for øyeblikket implementere en nesten komplett programvarestabel for arbeid med EDS.

PCSC lite

PC/SC-implementeringen utviklet innenfor rammen av PCSC lite-prosjektet er en referanse for Linux OS-familien. Den er inkludert i alle variantene av programvarestabelen som vurderes i dette dokumentet for arbeid med EDS. I fremtiden, hvis et spesifikt implementeringsalternativ ikke er spesifisert, vil vi vurdere det som aktivert som standard.

OpenSC

Biblioteket som implementerer PKCS#11-grensesnittet, samt et sett med applikasjonsverktøy som bruker funksjonaliteten, ble utviklet som en del av OpenSC-prosjektet. Verktøysettet støtter mange maskinvare-tokens, inkludert Rutoken EDS, støtten som ble lagt til av spesialistene til Aktiv-selskapet, som utvikler tokens fra Rutoken-familien.

Ved å bruke OpenSC-verktøyene kan du spesielt utføre følgende handlinger på et maskinvaretoken:

• initialiser tokenet - tilbakestill innstillingene til den opprinnelige tilstanden;
• angi administrator- og bruker-PIN-er (hvis støttet);
• generere et nøkkelpar (hvis det støttes av PKCS#11-biblioteket);
• importere et sertifikat signert av en sertifiseringsmyndighet til tokenet.

PKCS # 11-biblioteket fra OpenSC-settet lar deg kjøre på støttede tokens fult sett elektroniske signaturtransaksjoner. Støttede tokens inkluderer også Rutoken EDS.

Det er viktig å forstå her at for Rutoken EDS er det to forskjellige programvarestøttealternativer som ikke er kompatible med hverandre når det gjelder formatet for lagring av nøkler på tokenet. Når vi bruker PKCS # 11-biblioteket fra OpenSC, kan vi bruke den åpne programvarestabelen, og når vi bruker det gratis distribuerte lukkede biblioteket produsert av Aktiv, kan vi bruke den lukkede Aktiva-stabelen.

OpenSSL

For å kunne utnytte funksjonene til EDS fullt ut, i tillegg til selve PKCS # 11-biblioteket, må brukerapplikasjoner implementeres som gir operatøren tilgang til bibliotekfunksjonene og token-funksjonene. Et godt eksempel på en slik implementering er åpen kildekode-programvare fra OpenSSL-prosjektet. Den støtter spesielt følgende funksjoner:

• datakryptering;
• data dekryptering;
• dokument signatur;
• signaturverifisering;
• generering av en sertifikatsigneringsforespørsel;
• sertifikat import;
• sertifikateksport.

I tillegg, ved å bruke OpenSSL, kan du implementere funksjonaliteten til en fullverdig sertifiseringsinstans, inkludert:

• utstede klientsertifikater ved å signere signeringsforespørsler i PKCS#10-format;
• tilbakekall av klientsertifikater;
• registrering av utstedte og tilbakekalte sertifikater.

Den eneste mangelen på OpenSSL for øyeblikket, som ennå ikke tillater implementering av en fullverdig versjon av EDS-programvarestabelen basert på åpen kildekode-programvare, er mangelen på en åpen modul for samhandling med PKCS # 11-biblioteker med støtte for GOST-algoritmer. Det er en lukket implementering av en slik modul, laget av Aktiv, men den er ikke inkludert i den grunnleggende OpenSSL-distribusjonen, og derfor, med utgivelsen av nye versjoner av OpenSSL, blir kompatibiliteten periodisk ødelagt. Den åpne implementeringen av denne modulen støtter ennå ikke GOST-algoritmer.

Firefox

I tillegg til OpenSSL kan den velkjente Firefox html-nettleseren også samhandle med PKCS # 11-bibliotekene. For å koble til PKCS # 11-biblioteket, må du gå til i"Preferanser", velg deretter "Avansert" i den vertikale listen til venstre, velg "Sertifikater" i den horisontale listen, klikk på knappen "Sikkerhetsenheter" , i dialogboksen som vises, klikk på "Last inn"-knappen ". Et annet vindu vises med muligheten til å velge banen til filen med PKCS#11-biblioteket og muligheten til å angi det lokale navnet for det aktuelle biblioteket. Du kan laste inn flere forskjellige PKCS#11-moduler på denne måten forskjellige typer fysiske og virtuelle enheter.

Dessverre er funksjonaliteten til Firefox ennå ikke nok til å signere dokumenter i nettsidegrensesnittet. Derfor, for en fullverdig åpen EDS-programvarestabel med GOST-støtte, er det fortsatt ikke nok plug-in (plug-in) som lar deg få tilgang til objekter på token fra nettstedsprogramvaren. Vi håper at en slik plugin vil bli skrevet i nær fremtid. Eller åpne.

CryptoPro

I versjoner av CryptoPro CSP til og med 4.0, brukes manuell administrasjon av lokale cacher for å lagre brukersertifikater og CA-sertifikater. For fullverdig arbeid med et brukersertifikat, er det nødvendig at kopien er i en lokal cache, og hele kjeden av CA-sertifikater opp til og inkludert roten - i en annen. Teknologisk er denne funksjonen til CryptoPro strengt tatt ikke fullt ut berettiget: det er fornuftig å sjekke kjeden under autentisering; det faktiske faktumet om sertifikatets gyldighet påvirker ikke muligheten for signering. Spesielt hvis det er vårt eget sertifikat og vi vet hvor det kom fra. I ferske i skrivende stund er betaversjonene av CryptoPro CSP, ifølge utviklerne, implementert automatisk lasting av CA-sertifikatkjeden. Men å sikre at bare den som for øyeblikket er i bruk er i den lokale hurtigbufferen til brukersertifikater, ser ut til å fortsatt måtte overvåkes manuelt.

Tredjepartsutviklere gjør forsøk på å skrive grafiske grensesnitt for CryptoPro CSP, noe som letter rutinemessige brukeroperasjoner. Et eksempel på et slikt verktøy er rosa-crypto-tool , som automatiserer signering og kryptering av dokumenter. Pakke i ALT-distribusjoner.

CryptoPro CA

Lissi SOFT programvare er preget av streng overholdelse standarder og tekniske spesifikasjoner. Krypto-leverandører, inkludert unike, er utformet som PKCS#11-biblioteker. Ifølge utviklerne passer de godt med åpen kildekode-programvare, som også er fokusert på å støtte standarder. For eksempel med html-nettlesere og verktøy fra OpenSSL-settet.

Når det gjelder organisering av tilgang til offentlige tjenestesider, er også Lissy SOFT-produkter av interesse. Først av alt - kompatibilitet med "IFCPlugin" - en nettleserplugin som implementerer EDS-mekanismer på State Services-portalen. For det andre evnen til sertifiseringsinstansens programvare til å arbeide med sertifikatsigneringsforespørsler i PKCS#10-formatet.

Nettlesere

Noen ganger, for å få tilgang til nettsteder der vi planlegger å bruke elektroniske signaturmekanismer, må vi bruke andre teknologier som bruker russisk kryptografi. For eksempel kan GOST-algoritmer brukes til å organisere en kryptert dataoverføringskanal. I dette tilfellet kreves støtte for de riktige algoritmene i nettleseren. Dessverre støtter de offisielle versjonene av Firefox og Chromium ennå ikke fullt ut russisk kryptografi. Derfor må du bruke alternative sammenstillinger. Slike forsamlinger er for eksempel i arsenalet av kryptomidler til selskapene "CryptoPro" og "Lissy SOFT", så vel som i Alt-distribusjoner.

Nettsteder

Blant nettstedene som krever bruk av elektroniske signaturteknologier, er vi først og fremst interessert i nettsteder som leverer offentlige tjenester, samt elektroniske handelsplattformer (ETP). Noen ETP-er støtter dessverre ikke arbeid med OS fra Register of Russian Software ennå. Men situasjonen endrer seg gradvis til det bedre.

Bruken av EDS for nettsteder kommer vanligvis ned til autentisering og signering av dokumenter generert i nettstedets grensesnitt. I prinsippet ser autentisering ut på samme måte som signaturen til ethvert annet dokument: nettstedet som klienten ønsker å autentisere på, genererer en sekvens av tegn som den sender til klienten. Klienten sender tilbake signaturen til denne sekvensen laget ved hjelp av dens private nøkkel og sertifikatet (sertifikatet er litt tidligere). Nettstedet tar den offentlige nøkkelen fra klientsertifikatet og verifiserer signaturen til den opprinnelige sekvensen. Det samme gjelder signering av dokumenter. Her, i stedet for en vilkårlig sekvens, vises selve dokumentet.

offentlige tjenester

Som et resultat av studien viste det seg at fra og med 14. desember 2016 er de fleste av de føderale handelsplattformene - "", "RTS-tender" og "Sberbank-AST" klare til bruk på arbeidsplasser som kjører Linux-familiens OS . De resterende to nettstedene gir ennå ikke engang muligheten til å logge på med et klientsertifikat. Om utviklerne deres planlegger noen tiltak for å sikre kompatibilitet, er dessverre ikke funnet ut.

Samtidig, i de offisielle instruksjonene for alle nettsteder, bortsett fra "Unified Electronic Trading Platform", er den eneste støttede operativsystem Windows. Offisielle svar fra tekniske støttetjenester bekrefter denne informasjonen. Instruksjonene på nettstedet til United Electronic Trading Platform beskriver nettleserinnstillingene uten å spesifisere et spesifikt operativsystem.

I en oppsummert form er resultatene av studien gitt i tabellen:

For ETP-er som gir kompatibilitet med Linux, er det eneste støttede kryptoverktøyet for øyeblikket Cades-plugin, som kun kan bruke CryptoPro CSP som kryptoleverandør. Dermed er den gode nyheten at det er veldig enkelt å få et token for tilgang til elektroniske handelsplattformer – de fleste CA-er utsteder dem. Dårlige nyheter - tokenet vil være programvarebasert og vil ikke være kompatibelt med nettstedet til Statens tjenester.

For andre handelsplattformer er den eneste måten å få tilgang til EDS-funksjonaliteten på Windows OS-komponenten kalt CAPICOM. Etersoft-spesialister utførte forskningsarbeid, som et resultat av at den teoretiske muligheten for å lansere CAPICOM i vinmiljøet ble avklart.

Andre nettsteder

I tillegg til de listede nettstedene som bruker EDS direkte - for å gå inn på nettstedet og signere dokumenter generert i nettstedets grensesnitt, er det en rekke nettsteder som gir muligheten til å laste ned dokumenter som tidligere er signert med en kvalifisert elektronisk signatur. Et eksempel er stedet for hovedradiofrekvenssenteret. Tilgang til nettstedet utføres med pålogging og passord, og dokumenter er utarbeidet og signert på forhånd - i brukergrensesnittet for OS. For å jobbe med slike nettsteder er det derfor kun nødvendig med funksjonaliteten til lokal dokumentsignering. Det vil si at det praktisk talt ikke er noen begrensninger på valg av kryptoleverandør i dette tilfellet.

Eksempel på nøkkelferdig løsning

Dessverre, for øyeblikket, vet ikke forfatterne av dette dokumentet hvordan de skal bruke samme token samtidig på nettstedet til statens tjenester og på elektroniske handelsplattformer. Derfor må du lage to tokens med henholdsvis to nøkkelpar og to sertifikater. Det er ikke lovlig forbudt, teknisk sett er det gjennomførbart. Økonomisk er det også ganske realistisk: en token vil for eksempel være en hardware Rutoken EDS, den andre vil være en gammel eToken-modell, som nå kan finnes for en nominell avgift.

Tilgang til Statens tjenesters nettsted

For å få tilgang til statstjenestene, ta Rutoken EDS og utfør følgende trinn:

1. last ned Rutoken-plugin-programvaren fra siden på lenken;
2. installer Rutoken-pluginen - kopier plugin-filene (npCryptoPlugin.so og librtpkcs11ecp.so) til ~/.mozilla/plugins/ ;
3. gå til nettstedet med Registration Center-programvaren og følg instruksjonene for å utføre følgende handlinger - initialiser tokenet, generer et nøkkelpar, generer og lagre en lokal fil med en forespørsel om en signatur i PKCS # 10-formatet;
4. vi vil kontakte CA, som er klar til å utstede oss et sertifikat ved forespørsel om en signatur, vi vil motta et sertifikat i form av en fil;
5. i grensesnittet "Registreringssenter", lagre sertifikatet fra den mottatte filen på tokenet;
6. last ned "deb"-formatpakken fra lenken - filen IFCPlugin-x86_64.deb ;
7. bruke programvaren "Midnight Commander" (command mc ) "gå" inn i pakkefilen som inn i en katalog;
8. kopier innholdet i katalogen INNHOLD/usr/lib/mozilla/plugins til den lokale ~/.mozilla/plugins-katalogen;
9. i Firefox nettleser på nettsiden til Statens tjenester vil vi gå gjennom lenkene "Logg inn" og "Logg inn med elektroniske midler" i rekkefølge.

Hovedproblemet med å implementere denne instruksjonen er å finne en sertifiseringsinstans som er klar til å jobbe med en signaturforespørsel.

Tilgang til elektroniske handelsplattformer

For å få tilgang til nettstedene til elektroniske handelsplattformer som støtter arbeid i Linux, utfør følgende trinn:

1. med ethvert token som offisielt selges i den russiske føderasjonen, vil vi kontakte ethvert sertifiseringssenter som bruker CryptoPro CA, og vi vil motta brukersertifikatet og den hemmelige nøkkelen som er lagret på tokenet i en beholder med formatet som støttes av CryptoPro-programvaren;
2. i samsvar med instruksjonene, installer programvaren "CryptoPro CSP" og "Cades-plugin" for Chromium-nettleseren;
3. Ved å bruke Chromium-nettleseren går vi til nettstedene til elektroniske handelsplattformer og begynner å jobbe med dem i henhold til de offisielle instruksjonene.

Muligheten til å signere dokumenter i form av filer vil være tilgjengelig gjennom CryptoPro-konsollverktøyene og gjennom tredjeparts wrapper-applikasjoner som det allerede nevnte rosa-crypto-tool .

Systemkrav

• Internettilgang
• Operativsystem: Windows 8, 7, XP SP 3/2
• Prosessor: 1,6 GHz eller høyere
• RAM: 512 MB
• Tilgjengelighet av en av de støttede kryptoleverandørene: CryptoPro CSP 3.6 eller høyere, LISSI CSP, VIPNet CSP, Signal-COM CSP
• Skjermoppløsning: minst 800x600 px

Bruk en sertifisert kryptoleverandør

For driften av Ekey.Signature-programmet er tilstedeværelsen på arbeidsplassen av et kryptografisk informasjonsbeskyttelsesverktøy (CIPF) som krypterer dokumenter i samsvar med GOST-algoritmer obligatorisk. CryptoPro CSP-systemer ikke lavere enn 3.6, LISSI CSP, VIPNet CSP, Signal-COM CSP kan brukes som CIPF.

Kryptografiske informasjonsbeskyttelsesverktøy er kompatible med Ekey.Signature, men de er inkompatible med hverandre. Kun én CIPF kan installeres på én arbeidsplass.

Bruk et antivirus

Installer et populært antivirus på arbeidsplassen din og oppdater det regelmessig. Antivirus beskytter mot virus, spionprogrammer og eliminerer de fleste sikkerhetstrusler alene.

Beskytt tilgangen til din elektroniske signatur og arbeidsplass med et passord

Ved å bruke Ekey.Signature og kryptografiske beskyttelsesverktøy, beskytt datamaskinen din mot fysisk tilgang av fremmede. Bruk passordtilgang.

For å få tilgang til den elektroniske signaturen, bruk et komplekst passord. Et godt passord er en garantert sikkerhet for dataene dine. En god måte å huske et passord på er å skrive det inn hele tiden når du utfører elektroniske signaturoperasjoner.

Et flott sted å lagre passordet ditt er minnet ditt. Det er ikke tilrådelig å skrive ned passordet noe sted. Ikke lagre passordet ved siden av den fysiske elektroniske signaturbæreren, ikke lagre passordet i systemet.

Bruk kun lisensierte og oppdaterte programmer

Med jevne mellomrom oppdateres programmene som er installert på arbeidsplassen din for å forbedre stabiliteten og sikkerheten til arbeidet ditt.

Installer programvareoppdateringer kun fra offisielle nettsteder, sjekk nettstedsadresser og informasjon om programutgiveren før du installerer.

Ekey installasjon.Signatur

1. Last ned

2. For å begynne å installere programmet, kjør installasjonsfilen. Hvis UAC er lansert, må du tillate endringer i Ekey Transfer-programmet.

Utarbeidelse av filer for Rosreestr

1. Velg operasjonstypen "Rosreestr" i hovedprogramvinduet eller i kontekstmenyen til filen.

Forbereder en beholder for FFMS i Russland, tjenesten til Bank of Russia, sentralbanken

1. Velg transaksjonstypen "FFMS of Russia".

2. Velg et personlig sertifikat.

3. Legg til en rapport med xtdd- eller smcl-utvidelse ved å bruke knappen "Legg ved fil(er)" eller dra og slipp filen med musen.

5. Om nødvendig, skriv inn passordet for den private nøkkelbeholderen

7. For å legge til en signatur, legg ved den tidligere genererte beholderen, velg det nødvendige sertifikatet og klikk på Generer-knappen.

8. For å sende rapporter til portalen til Bank of Russia Service (FFMS), klikk på legg til-knappen, i menyen som vises, velg ønsket beholder med rapporten og klikk på last opp til portal-knappen.

FSIS TP Ministeriet for regional utvikling i Russland

1. Velg operasjonstype "FSIS TP".

2. Velg et personlig sertifikat.

3. Legg til en rapport ved å bruke knappen "Legg ved fil(er)" eller dra og slipp en fil med musen.

4. Klikk på Generer-knappen.

5. Om nødvendig, skriv inn passordet for den private nøkkelbeholderen

6. I lagringsmenyen som vises, velg en plassering for å lagre resultatet av operasjonen.

Roskomnadzor-registeret (zapret-info.gov.ru)

1. Velg operasjonen Roskomnadzor-registeret

2. Velg et personlig sertifikat

3. For å finne ut tidspunktet for siste oppdatering av registeret, klikk "Tidspunkt for siste oppdatering av utlasting fra registeret"

4. For å sende en forespørsel, klikk "send forespørsel"

Fyll ut feltene for å generere en forespørsel.

5. For å få resultatet av behandlingen av forespørselen, klikk "Be om å få resultatet"

For å laste ut registret automatisk, må du krysse av i boksen "Last av automatisk", angi den nødvendige perioden for lossing og spesifisere katalogen for å lagre resultatene av lossingen.

ISED

1. Velg operasjonstypen "ISED".

2. Legg til en rapport ved å bruke knappen "Legg ved fil(er)" eller dra og slipp en fil med musen.

3. Velg mottakersertifikater

4. Klikk på Generer-knappen.

5. I lagringsmenyen som vises, velg et sted for å lagre resultatet av operasjonen.

Filsignatur

1. Velg operasjonstypen "Signer manuelt".

2. Velg et personlig sertifikat.

4. Velg de ønskede signaturalternativene.

5. Klikk på "Sign"-knappen.

6. Om nødvendig, skriv inn passordet for den private nøkkelbeholderen

Forklaringer:

Lagre signaturen i en egen fil

Når flagget er satt, vil det opprettes en ikke-festet elektronisk signatur Hvis flagget ikke er til stede, vil signaturen bli lagt til på slutten av filen (i dette tilfellet vil dokumentet og den elektroniske signaturen bli lagret sammen)

Arkiver filer

Trenger jeg å arkivere filer etter signering

Utvidelse - Standard signaturfiltype er sig, du kan også spesifisere din egen filtype

Koding - Velg kodingen du trenger Der eller Base-64

Deaktiver tjenesteoverskrifter- Når Base-64-koding er valgt (overskrifter brukes for kompatibilitet med tredjepartsprogramvare).

Filkryptering

1. Velg operasjonstypen "Krypter manuelt".

2. Velg et personlig sertifikat.

3. Legg til en fil ved å bruke "Legg ved fil(er)"-knappen eller dra og slipp en fil med musen.

4. Velg de nødvendige krypteringsalternativene.

5. Legg til eller velg fra de tilgjengelige mottakersertifikatene (som filen skal krypteres til)

6. Klikk på "Krypter"-knappen.

7. Om nødvendig, skriv inn passordet for den private nøkkelbeholderen

8. I lagringsmenyen som vises, velg en plassering for å lagre resultatet av operasjonen. Forklaringer:

Koding

Velg Der eller Base-64-koding du trenger

Utvidelse

Utvidelsen som den endelige filen vil ha (enc som standard), kan du også spesifisere din egen filtype. Deaktiver tjenestehoder - Hvis Base-64-koding er valgt (påkrevd for kompatibilitet med tredjepartsprogramvare).

Arkiver filer før kryptering

Hvis du trenger å arkivere filer før kryptering, merk av i den aktuelle boksen.

Hvis du legger til flere filer, vil alle filene bli pakket i ett arkiv.

Fildekryptering

1. Velg operasjonstypen "Dekrypter".

2. Velg et personlig sertifikat.

3. Legg til en fil ved å bruke "Legg ved fil(er)"-knappen eller dra og slipp en fil med musen.

4. Klikk på "Dekrypter"-knappen.

5. Om nødvendig, skriv inn passordet for den private nøkkelbeholderen

6. I lagringsmenyen som vises, velg en plassering for å lagre resultatet av operasjonen.

Signaturbekreftelse

1. For å begynne å bekrefte signaturen, bruk bekreftelsesmetoden som er praktisk for deg.

• Ved å dobbeltklikke på filen som inneholder signaturen.
• Velg type operasjon "Bekreft signatur" i hovedmenyen til programmet.
• Gjennom kontekstmenyen til filen som skal sjekkes.

2. Legg til en fil ved å bruke "Legg ved fil(er)"-knappen eller dra og slipp en fil med musen.

3. Klikk på Sjekk-knappen.

Etter å ha klikket på "Sjekk"-knappen, vises et vindu med resultatet av signaturverifiseringen. I den kan du se signaturtreet, skrive ut bekreftelsesresultatet og åpne kildefilen for visning.

Under skanningen kan du også se innholdet i filer med filtypen: doc xls csv pdf html htm txt xml zip png jpeg jpg bmp gif.

Forklaringer:

Avsign filer

Hvis en vedlagt signatur er opprettet, kan dette alternativet brukes til å få en kildefil som ikke inneholder noen signaturer.

Legg til signatur

1. Velg operasjonstypen "Legg til signatur".

2. Velg et personlig sertifikat.

4. Klikk på "Sign"-knappen.

5. Om nødvendig, skriv inn passordet for den private nøkkelbeholderen

6. I lagringsmenyen som vises, velg en plassering for å lagre resultatet av operasjonen.

Bekreft signatur

1. Velg operasjonstypen "Sertifiser signatur".

2. Velg et personlig sertifikat.

3. Legg til en signaturfil ved å bruke knappen "Legg ved fil(er)" eller dra og slipp filen med musen.

4. Klikk på Bekreft-knappen.

5. Om nødvendig, skriv inn passordet for den private nøkkelbeholderen

6. I menyen som vises, velg signaturen du vil sertifisere

7. I lagringsmenyen som vises, velg en plassering for å lagre resultatet av operasjonen.

Automatisk oppdatering

Når en oppdatering blir tilgjengelig, vises en tilsvarende inskripsjon i øvre høyre hjørne av den lanserte Ekey Signature-applikasjonen. For å starte en oppdatering, klikk på den med venstre museknapp.

Etter at oppdateringsprosessen er fullført, klikker du "OK" ved meldingen om at noen endringer først trer i kraft etter en omstart. Klikk på "Fullfør"-knappen. Etter det anbefales det å starte datamaskinen på nytt. En omstart er først og fremst nødvendig for at oppdateringene knyttet til arbeidet med Windows-kontekstmenyen skal tre i kraft.

Automatisk installasjon av rotsertifikater

Hvis det ikke er noe rotsertifikat i butikken, vises en tilsvarende feil i brukerloggen når Ekey Signature-applikasjonen startes. I dette tilfellet bør du signere en fil med et "problematisk" personlig sertifikat. Når du utfører signeringsoperasjonen, vises en dialogboks som ber deg installere det manglende rotsertifikatet. Klikk Ja for å installere det manglende rotsertifikatet.

Sertifiseringsinstans CAFL63 opprettet på grunnlag av. SQLite3 DBMS brukes til å lagre data (forespørsler, sertifikater, innstillinger osv.). Sertifiseringsmyndigheten har et grafisk grensesnitt utviklet i Tcl/Tk.

CAFL63 CA ble utviklet under hensyntagen til kravene føderal lov 6. april 2011 nr. 63-FZ "Om elektronisk signatur", samt "Krav til form av et kvalifisert sertifikat for verifiseringsnøkkelen for elektronisk signatur", godkjent etter ordre fra Federal Security Service of Russia datert 27. desember 2011 nr. 795.

CA inkluderer registreringssenteret (CR), som er ansvarlig for å motta søknader om sertifikater fra innbyggere. I dag utstedes sertifikater for juridiske personer, enkeltpersoner og individuelle gründere. Søknader aksepteres elektronisk i PKCS#10, CSR (Certificate Signing Request) eller SPKAC-format. Merk at CSR-formatet er en PKCS#10 PEM-kodet forespørsel med -----BEGIN REQUEST CERTIFICATE----- overskriften.

Forespørselen er et utfylt spørreskjema, formålene et sertifikat er nødvendig for, brukerens offentlige nøkkel, påskrevet (signert) med brukerens private nøkkel. Videre, med en pakke med dokumenter som spesielt beviser søkerens identitet, og med et elektronisk medium som forespørselen er lagret på (jeg understreker at forespørselen, det er bedre å lagre den private nøkkelen et annet sted), kommer borgeren til CR av CA.

CR sjekker dokumentene, forespørselen (utfylte data, riktigheten av den elektroniske signaturen osv.), og hvis alt gikk bra, godtar de forespørselen, godkjenner den og overfører den til sertifiseringssenteret (CA).

I tilfelle at søkeren kom uten klar forespørsel, så går han sammen med den CR-ansatte til en egen arbeidsplass, hvor det utarbeides en forespørsel om sertifikat. Den utarbeidede forespørselen på elektroniske medier, som allerede nevnt, sendes til CR. Hva må søkeren huske her? Først og fremst: søkeren må hente mediet med den genererte private nøkkelen!

Den godkjente forespørselen på elektroniske medier sendes til CA, hvor et sertifikat utstedes på grunnlag av det.

Dette er et grunnleggende diagram over arbeidet til UC. Detaljene vil bli tydelige nedenfor. En merknad, for enkelhets skyld ved å demonstrere forespørselsforberedelsesverktøyet, er CR og CA kombinert til ett demokompleks. Men det er ingen problemer med separasjonen av funksjonalitet. Den enkleste løsningen er å ha en kopi av CAFL63 på hver arbeidsplass og kun bruke den nødvendige funksjonaliteten.

Da prosjektet var i full gang, fanget SimpleCA-prosjektet meg. Studiet av dette prosjektet var svært nyttig i den endelige implementeringen av CAFL63 CA.

Last ned CAFL63-distribusjon for plattformene Win32/Win64, Linux_x86/Linux_x86_64.

Så vi starter CAFL63-verktøyet - CAFL63-startsiden vises på skjermen:

Vi starter arbeidet ved å trykke på knappen "Opprett DB". CA-databasen er opprettet ved hjelp av SQLite3 DBMS på tvers av plattformer. CA-databasen inneholder flere tabeller. Hovedtabellen - mainDB - inneholder bare én oppføring, som lagrer rotsertifikatet, en privat nøkkel kryptert med et passord og CA-innstillinger. Det er to tabeller knyttet til sertifikatforespørsler: reqDB gjeldende forespørsler og reqDBArc-forespørslerarkiv. Tre tabeller opprettes for sertifikater: den nye sertifikattabellen certDBNew, sertifikatarkivtabellen CertDB og sertifikatopphevelsestabellen CertDBRev. Alle forespørsels- og sertifikattabeller bruker hash-verdien (sha1) til den offentlige nøkkelen som primærnøkkel. Dette viste seg å være veldig praktisk, for eksempel når du søkte etter et sertifikat på forespørsel eller omvendt. Det er en annen crlDB-tabell i databasen, som lagrer lister over tilbakekalte sertifikater. Så vi klikket på "Opprett DB"-knappen:

Oppretting av en CA begynner med å velge en katalog der vi skal lagre databasen og angi et passord for å få tilgang til den private nøkkelen til CA. Ved å trykke på "Neste"-tasten går vi til siden for valg av type og parametere for nøkkelparet for CA:

Etter å ha bestemt oss for nøkkelparet for rotsertifikatet til sertifiseringsmyndigheten som opprettes, fortsetter vi å fylle ut skjemaet med informasjon om eieren (vi hoppet over det første skjermbildet):

Merk at CAFL63-verktøyet har en viss "intelligens" og kontrollerer derfor ikke bare tilstedeværelsen av data i feltene, men også riktigheten (rød markering - feil) for å fylle ut felter som TIN, OGRN, SNILS, OGRNIP, adresse E-post og så videre.

Etter å ha fylt ut feltene med informasjon om eieren av CA, vil du bli bedt om å bestemme systeminnstillingene til CA:

Hvis du ikke skal jobbe med russisk kryptografi, kan du bruke vanlig OpenSSL. For å jobbe med russisk kryptografi, må du spesifisere riktig versjon, modifikasjon av OpenSSL. Les README.txt i den nedlastede distribusjonen for mer informasjon. I samsvar med FZ-63 foreslås det også å angi informasjon om sertifiseringen av selve CA og CIPF som brukes av den.

Etter å ha fylt ut alle feltene riktig, vil du igjen bli bedt om å sjekke gyldigheten og klikke på "Fullfør"-knappen:

Etter å ha klikket på "Fullfør"-knappen, vil en CA-database bli opprettet, der følgende vil bli lagret: CA-rotsertifikatet, privat nøkkel, systeminnstillinger. Og startsiden til CAFL63-verktøyet vil dukke opp igjen på skjermen. Nå som vi har opprettet databasen til den nyopprettede CA, trykker vi på "Åpne DB"-knappen, velger katalogen med databasen og kommer inn i hovedvinduet til CA:

Ved å klikke på "Se CA CA"-knappen forsikrer vi oss om at dette er rotsertifikatet vårt.

Neste steg er å utarbeide søknadsmaler/profiler for juridisk enhet, enkeltpersoner og individuelle gründere ( Verktøy->Innstillinger->Sertifikattyper->Ny ):

Etter å ha angitt navnet på den nye profilen, vil du bli bedt om å definere sammensetningen:

Etter å ha utarbeidet profilene er CA klar til å motta søkere og søknader fra dem. Som nevnt ovenfor kan søkeren komme med eller uten utfylt søknad om sertifikat.

Hvis søkeren kom med en fullført søknad, importeres søknaden til databasen til CA etter å ha sjekket dokumentene hans. For å gjøre dette, i hovedvinduet, velg kategorien "Sertifikatforespørsler", klikk på "Importer forespørsel / CSR" -knappen og velg filen med forespørselen. Etter det vil et vindu med informasjon om forespørselen vises:

Etter å ha gjennomgått forespørselen og forsikret deg om at den er fylt ut riktig, kan du klikke på "Importer"-knappen for å legge den inn i databasen. Vi merker umiddelbart at når du prøver å legge inn forespørselen på nytt i CA-databasen, vil en melding vises:

Forespørsler i CA-databasen merkes (kolonnen "Type") enten som "Lokal", opprettet av CA, eller som "Import", opprettet av søkeren selv, og tidspunktet for mottak av søknaden av CA er også innspilt. Dette kan være nyttig i håndtering av konfliktsituasjoner.

Hvis søkeren kom uten søknad og ber om å opprette den, er det først og fremst nødvendig å bestemme ( Innstillinger->Sertifikattyper->Individuell->Rediger ) med nøkkelpartype ( ->Nøkkelpar ), for hvilket formål ( -> Nøkkelbruk ) sertifikat kreves:

Nøkkelparet kan opprettes enten ved hjelp av CIPF "LIRSSL-CSP" (OpenSSL-knappen) og lagres i en fil, eller på et PKCS#11-token (PKCS#11-knappen). I sistnevnte tilfelle må du også spesifisere biblioteket for tilgang til tokenet (for eksempel rtpkcs11ecp for RuToken ECP-token eller ls11cloud for ).

Etter at du har bestemt deg for profilen og klikket på "Neste"-knappen, er den videre prosedyren ikke mye forskjellig fra å utstede et rotsertifikat. En viktig merknad: husk hvor du lagrer den private nøkkelen og passordet for å få tilgang til nøkkelen. Hvis et PKCS#11-token/smartkort brukes som en CIPF for å generere et nøkkelpar, må det kobles til en datamaskin:

Den opprettede eller importerte applikasjonen ligger i CA-databasen og vises i hovedvinduet på fanen "Sertifikatforespørsler". Mottatte forespørsler er under "overveielse" ("Status"-kolonnen i fanene "Sertifikatforespørsler" og "Forespørslerarkiv"). For hver nylig mottatt forespørsel må en avgjørelse tas (kontekstmeny når du høyreklikker på den valgte forespørselen):

Hver forespørsel kan avvises eller godkjennes:

Hvis forespørselen avvises, flyttes den fra den gjeldende reqDB-forespørselstabellen til reqDBArc-forespørselsarkivtabellen og forsvinner følgelig fra kategorien Sertifikatforespørsler og vises på nytt på fanen Request Archive.

Den godkjente søknaden forblir i reqDB-tabellen og på fanen "Sertifikatforespørsler" til sertifikatet er utstedt, og kommer da også inn i arkivet.

Prosedyren for å utstede et sertifikat, menypunktet "Utstede et sertifikat") skiller seg lite fra prosedyren for å opprette en søknad:

Det utstedte sertifikatet vises umiddelbart på fanen "Sertifikater". I dette tilfellet går selve sertifikatet inn i certDBNew-tabellen i CA-databasen og forblir der til det publiseres. Et sertifikat anses som publisert etter at det er eksportert til en SQL-dump av nye sertifikater, som overføres til en offentlig tjeneste. Publisering av et sertifikat flytter det fra certDBNew-tabellen til certDB-tabellen.

Hvis du trykker høyre museknapp på den valgte linjen i kategorien "Sertifikater", vil en meny vises med følgende funksjoner:

Hvis forespørselen ble opprettet ved CA med nøkkelen generert og lagret i en fil, må du opprette en PKCS # 12-beholder og sende den til søkeren:

Du bør være oppmerksom på det "vennlige navnet" - sitatene i det må unnslippes:

Etter at den sikre PKCS#12-beholderen er opprettet, blir søkerens private nøkkelfil ødelagt.

Så, CA begynte sitt liv, utstedte det første sertifikatet. En av oppgavene til CA er å organisere fri tilgang til utstedte sertifikater. Publisering av sertifikater går som regel gjennom webtjenester. CAFL63 har også en slik tjeneste:

For å publisere sertifikater og lister over tilbakekalte sertifikater på en offentlig tjeneste, laster CA enten foreløpig opp sertifikater til filer (Sertifikater->Eksporter sertifikater), eller lager en SQL-dump av hele tabellen med sertifikater, hvorfra du kan opprette en database med sertifikater og last opp en liste over sertifikater til den, og lag deretter en SQL-dump av nye sertifikater, hvorfra de vil bli lagt til offentlig tjenestedatabase:

Den grunnleggende funksjonen til CA er publisering av en liste over tilbakekalte sertifikater, på samme måte som innenriksdepartementet gjør med hensyn til utløpte pass. Sertifikatet kan tilbakekalles på forespørsel fra eier. Hovedårsaken til tilbakekall er tap av den private nøkkelen eller tap av tillit til den.

For å tilbakekalle et sertifikat, velg det på "Sertifikater", høyreklikk og velg menyelementet "Sertifikattilbakekalling":

Prosedyren for tilbakekall er den samme som for å opprette en forespørsel eller utstede et sertifikat. Det tilbakekalte sertifikatet går inn i cerDBRev-tabellen i CA-databasen og vises i fanen Tilbakekalte sertifikater.

Det gjenstår å vurdere den siste funksjonen til CA - utgivelsen av CRL - en liste over tilbakekalte sertifikater. CRL-listen genereres på fanen "Opphevede sertifikater" ved å klikke på knappen "Opprett COS/CRL". Alt som kreves her fra administratoren er å skrive inn passordet til CA og bekrefte hans intensjon om å utstede en CRL:

Den utstedte CRL-en går inn i crlDB-tabellen i databasen og vises på CRL/COS-fanen. For å se CRL eller eksportere den med det formål å publisere på en offentlig tjeneste, må du som alltid velge ønsket linje, trykke på høyre museknapp og velge menypunktet:

Last ned CAFL63-distribusjon for plattformer Win32/Win64, Linux_x86/Linux_x86_64 . Dessuten fungerer det hele vellykket på Android-plattformen.