Erfaring med at bruge Rutoken teknologi til registrering og autorisering af brugere i systemet (del 1)

God eftermiddag Jeg vil gerne dele mine erfaringer om dette emne.

Rutoken er hardware- og softwareløsninger inden for autentificering, informationssikkerhed og elektronisk signatur. I det væsentlige er dette et flashdrev, der kan gemme godkendelsesdata, som brugeren bruger til at logge ind på systemet.

I dette eksempel er Rutoken EDS 2.0 brugt.

For at arbejde med denne Rutoken har du brug for installere driver på windows.

For Windows sikrer installation af kun én driver, at alt det nødvendige er installeret, så OS ser din Rutoken og kan arbejde med den.

Du kan interagere med Rutoken på forskellige måder. Du kan få adgang til det fra serversiden af ​​applikationen eller direkte fra klientsiden. Dette eksempel vil se på interaktion med Rutoken fra klientsiden af ​​applikationen.

Klientdelen af ​​applikationen interagerer med rutoken gennem rutoken plugin. Dette er et program, der installeres separat på hver browser. Til Windows skal du blot downloade og installere plugin, findes på dette link.

Det er det, nu kan vi interagere med Rutoken fra klientsiden af ​​applikationen.

Dette eksempel diskuterer ideen om at implementere en brugergodkendelsesalgoritme i systemet ved hjælp af challenge-response-skemaet.

Essensen af ​​ideen er som følger:

  1. Klienten sender en godkendelsesanmodning til serveren.
  2. Serveren svarer på en anmodning fra klienten ved at sende en tilfældig streng.
  3. Klienten udfylder denne streng med tilfældige 32 bits.
  4. Klienten signerer den modtagne streng med sit certifikat.
  5. Klienten sender den modtagne krypterede besked til serveren.
  6. Serveren verificerer signaturen ved at modtage den originale ukrypterede besked.
  7. Serveren fjerner de sidste 32 bits fra den modtagne ukrypterede besked.
  8. Serveren sammenligner det modtagne resultat med den besked, der blev sendt, da der blev anmodet om godkendelse.
  9. Hvis meddelelserne er de samme, betragtes godkendelsen som vellykket.

I ovenstående algoritme er der sådan noget som et certifikat. For dette eksempel skal du forstå noget kryptografisk teori. På Habré er der stor artikel om dette emne.

I dette eksempel vil vi bruge asymmetriske krypteringsalgoritmer. For at implementere asymmetriske algoritmer skal du have et nøglepar og et certifikat.

Et nøglepar 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 det til at dekryptere information. Den offentlige nøgle kan distribueres til alle. Denne nøgle bruges til at kryptere data. Enhver bruger kan således kryptere data ved hjælp af den offentlige nøgle, men kun ejeren af ​​den private nøgle kan dekryptere denne information.

Et certifikat er et elektronisk dokument, der indeholder oplysninger om den bruger, der ejer certifikatet, samt en offentlig nøgle. Med et certifikat kan brugeren signere alle data og sende dem til serveren, som kan verificere signaturen og dekryptere dataene.

For at kunne underskrive en meddelelse korrekt med et certifikat, skal du oprette den korrekt. For at gøre dette oprettes der først et nøglepar på Rutoken, og derefter skal et certifikat linkes til den offentlige nøgle for dette nøglepar. Certifikatet skal have præcis den offentlige nøgle, der er placeret på Rutoken, dette er vigtigt. Hvis vi blot opretter et nøglepar og et certifikat med det samme på klientsiden af ​​applikationen, hvordan kan serveren så dekryptere denne krypterede besked? Han ved jo intet som helst om hverken nøgleparret eller certifikatet.

Hvis du dykker dybere ned i dette emne, kan du finde interessant information på internettet. Der er visse certificeringsmyndigheder, som vi naturligvis har tillid til. Disse certificeringsmyndigheder kan udstede certifikater til brugere; de ​​installerer disse certifikater på deres server. Efter dette, når klienten tilgår denne server, ser han netop dette certifikat og ser, at det er udstedt af en certificeringsmyndighed, hvilket betyder, at denne server kan stole på. Der er også masser af information på Internettet om, hvordan du sætter alt op korrekt. Du kan for eksempel starte med dette.

Hvis vi vender tilbage til vores problem, synes løsningen indlysende. Du skal på en eller anden måde oprette dit eget certificeringscenter. Men før det skal du finde ud af, på hvilket grundlag certificeringscentret skal udstede et certifikat til brugeren, fordi han ikke ved noget om det. (For eksempel hans fornavn, efternavn osv.) Der er sådan noget, der hedder en certifikatanmodning. Mere information om denne standard findes for eksempel på Wikipedia ru.wikipedia.org/wiki/PKCS
Vi vil bruge version 1.7 - PKCS#10.

Lad os beskrive algoritmen til at generere et certifikat på Rutoken (original kilde: dokumentation):

  1. Vi opretter et nøglepar på klienten og gemmer det på Rutoken. (lagring sker automatisk)
  2. Vi opretter en certifikatanmodning på klienten.
  3. Fra klienten sender vi denne anmodning til serveren.
  4. Når vi modtager en anmodning om et certifikat på serveren, udsteder vi et certifikat fra vores certificeringsmyndighed.
  5. Vi sender dette certifikat til kunden.
  6. Vi gemmer Rutoken-certifikatet på klienten.
  7. Certifikatet skal være bundet til det nøglepar, der blev oprettet i det første trin.

Nu bliver det klart, hvordan serveren vil være i stand til at dekryptere klientens signatur, da den selv udstedte certifikatet til ham.

I den næste del vil vi se nærmere på, hvordan du opsætter din certifikatautoritet baseret på det fuldgyldige open-source kryptografibibliotek openSSL.

Kilde: www.habr.com

Tilføj en kommentar