Goddag! Jeg vil gerne dele mine erfaringer om dette emne.
RUTOKEN er hardware- og softwarelÞsninger inden for autentificering, informationsbeskyttelse og elektronisk signatur. I bund og grund er det sÄdan et USB-drev, der kan gemme autentificeringsdata, som brugeren anvender til at logge ind i systemet.
I dette eksempel bruges RUTOKEN ECDSA 2.0.
For at arbejde med denne RUTOKEN skal du.
For Windows, installationen af kun driveren sikrer, at systemet kan se din RUTOKEN, og at du kan arbejde med den.
RUTOKEN kan interagere pÄ forskellige mÄder. Man kan fÄ adgang til den fra server- eller klientdelen af applikationen. I dette eksempel vil vi se pÄ interaktionen med RUTOKEN fra klientdelen af applikationen.
Klientdelen af applikationen interagerer med RUTOKEN gennem RUTOKEN-plugin. Det er et program, der installeres sÊrskilt pÄ hver browser. For Windows skal du blot downloade og installere plugin'en, .
Alt er nu klar, sÄ vi kan interagere med RUTOKEN fra klientdelen af applikationen.
I dette eksempel vil vi se pÄ ideen om at implementere en brugerautentificering algoritme i systemet ved hjÊlp af challenge-response skemaet.
Essensen af ideen er som fĂžlger:
- Klienten sender en autentificeringsanmodning til serveren.
- Serveren sender i svar pÄ anmodningen fra klienten en tilfÊldig streng.
- Klienten tilfĂžjer denne streng med tilfĂŠldige 32 bits.
- Klienten underskriver den modtagne streng med sit certifikat.
- Klienten sender det modtagne kodede meddelelse til serveren.
- Serveren kontrollerer signaturen ved at modtage den originale, ikke-kodede meddelelse.
- Serveren adskiller de sidste 32 bits fra den modtagne, ikke-kodede meddelelse.
- Serveren sammenligner det modtagne resultat med den meddelelse, der blev sendt ved anmodningen om autentificering.
- Hvis meddelelserne er ens, betragtes autentificeringen som succesfuld.
I den ovenfor nÊvnte algoritme er der et begreb kaldet certifikat. I denne sammenhÊng skal man forstÄ noget kryptografisk teori. PÄ Habr er der .
I dette eksempel vil vi bruge asymmetrisk krypteringsalgoritmer. For at implementere asymmetrisk algoritmer er det nĂždvendigt at have et nĂžglepar og et certifikat.
NÞgleparret bestÄr af to dele: en privat nÞgle og en offentlig nÞgle. Den private nÞgle skal, som navnet antyder, vÊre hemmelig. Vi bruger den til at dekryptere information. Den offentlige nÞgle kan gives til enhver. Denne nÞgle bruges til at kryptere data. Derfor kan enhver bruger kryptere data ved hjÊlp af den offentlige nÞgle, men kun ejeren af den private nÞgle kan dekryptere disse oplysninger.
Et certifikat er et elektronisk dokument, der indeholder information om brugeren, som ejer certifikatet, samt den offentlige nĂžgle. Med et certifikat kan brugeren underskrive data og sende dem til serveren, som kan verificere denne underskrift og dekryptere dataene.
For korrekt at kunne underskrive en besked med certifikatet, skal det oprettes korrekt. Til dette oprettes et nÞglepar pÄ Rutoken, og derefter skal certifikatet knyttes til den offentlige nÞgle i dette nÞglepar. Certifikatet skal have lige prÊcis den offentlige nÞgle, der findes pÄ Rutoken, det er vigtigt. Hvis vi bare opretter et nÞglepar og certifikatet straks pÄ klientdelen af applikationen, hvordan kan serveren sÄ dekryptere denne krypterede besked senere? For den ved slet ikke noget om nÞgleparret eller certifikatet.
Hvis man dykker dybere ind i emnet, kan man finde interessant information pÄ internettet. Der er visse certificeringscentre, som vi giver forudbestemt tillid. Disse certificeringscentre kan udstede certifikater til brugere, og de installerer disse certifikater pÄ deres server. Derefter, nÄr klienten henvender sig til denne server, ser han netop dette certifikat og bemÊrker, at det er udstedt af et certificeringscenter, og at dette server derfor kan stole pÄ. Der er ogsÄ masser af information pÄ internettet om, hvordan man korrekt konfigurerer alt. .
Hvis vi vender tilbage til vores opgave, virker lÞsningen oplagt. Vi skal pÄ en eller anden mÄde oprette vores eget certifikatmyndighed. Men fÞr det er nÞdvendigt at forstÄ, hvad certifikatmyndigheden skal basere certifikatudstedelsen pÄ, for den ved jo ikke noget om brugeren. (For eksempel hans navn, efternavn osv.) Der findes en ting, der kaldes en certifikatforespÞrgsel. For mere information om denne standard kan man se pÄ Wikipedia.
Vi vil bruge version 1.7 â PKCS#10.
Lad os beskrive algoritmen for dannelse af certifikat pĂ„ Rutoken (oprindelig kilde â ):
- PÄ klienten opretter vi et nÞglepar og gemmer det pÄ Rutoken. (gemningen sker automatisk)
- PĂ„ klienten opretter vi en certifikatforespĂžrgsel.
- Vi sender denne forespĂžrgsel fra klienten til serveren.
- NĂ„r serveren modtager certifikatforespĂžrgslen, udsteder vi certifikatet fra vores certifikatmyndighed.
- Vi sender dette certifikat tilbage til klienten.
- PÄ klienten gemmer vi certifikatet pÄ Rutoken.
- Certifikatet skal knytte sig til det nĂžglepar, der blev oprettet i det fĂžrste trin.
Nu er det klart, hvordan serveren kan dekryptere klientens signatur, da den selv har udstedt certifikatet.
I den nÊste del vil vi se nÊrmere pÄ, hvordan man konfigurerer sin egen certifikatmyndighed baseret pÄ det fulde open source cryptografiske biblioteks openSSL.
Kilde: habr.com
