Erfarenhet av att använda Rutoken-teknik för att registrera och auktorisera användare i systemet (del 1)

God eftermiddag Jag vill dela med mig av mina erfarenheter om detta ämne.

Rutoken är hård- och mjukvarulösningar inom området autentisering, informationssäkerhet och elektronisk signatur. I huvudsak är detta en flash-enhet som kan lagra autentiseringsdata som användaren använder för att logga in i systemet.

I det här exemplet används Rutoken EDS 2.0.

För att arbeta med denna Rutoken behöver du installera drivrutinen på windows.

För Windows, installation av bara en drivrutin säkerställer att allt som behövs är installerat så att operativsystemet ser din Rutoken och kan arbeta med den.

Du kan interagera med Rutoken på olika sätt. Du kan komma åt den från applikationens serversida eller direkt från klientsidan. Detta exempel kommer att titta på interaktion med Rutoken från klientsidan av applikationen.

Klientdelen av applikationen interagerar med rutoken genom insticksprogrammet rutoken. Detta är ett program som installeras separat på varje webbläsare. För Windows behöver du bara ladda ner och installera plugin, finns på denna länk.

Det är det, nu kan vi interagera med Rutoken från klientsidan av applikationen.

Det här exemplet diskuterar idén om att implementera en användarauktoriseringsalgoritm i systemet med hjälp av utmaningssvarsschemat.

Kärnan i idén är som följer:

1. Klienten skickar en auktoriseringsbegäran till servern.
2. Servern svarar på en begäran från klienten genom att skicka en slumpmässig sträng.
3. Klienten fyller denna sträng med slumpmässiga 32 bitar.
4. Klienten signerar den mottagna strängen med sitt certifikat.
5. Klienten skickar det mottagna krypterade meddelandet till servern.
6. Servern verifierar signaturen genom att ta emot det ursprungliga okrypterade meddelandet.
7. Servern tar bort de sista 32 bitarna från det mottagna okrypterade meddelandet.
8. Servern jämför det mottagna resultatet med meddelandet som skickades när auktorisering begärdes.
9. Om meddelandena är desamma anses auktoriseringen vara framgångsrik.

I ovanstående algoritm finns något sådant som ett certifikat. För det här exemplet måste du förstå någon kryptografisk teori. På Habré finns bra artikel om detta ämne.

I det här exemplet kommer vi att använda asymmetriska krypteringsalgoritmer. För att implementera asymmetriska algoritmer måste du ha ett nyckelpar och ett certifikat.

Ett nyckelpar består av två delar: en privat nyckel och en publik nyckel. Den privata nyckeln måste, som namnet antyder, vara hemlig. Vi använder den för att dekryptera information. Den publika nyckeln kan distribueras till vem som helst. Denna nyckel används för att kryptera data. Således kan vilken användare som helst kryptera data med hjälp av den publika nyckeln, men endast ägaren av den privata nyckeln kan dekryptera denna information.

Ett certifikat är ett elektroniskt dokument som innehåller information om användaren som äger certifikatet, samt en publik nyckel. Med ett certifikat kan användaren signera vilken data som helst och skicka den till servern, som kan verifiera signaturen och dekryptera data.

För att korrekt signera ett meddelande med ett certifikat måste du skapa det korrekt. För att göra detta skapas först ett nyckelpar på Rutoken, och sedan måste ett certifikat kopplas till den publika nyckeln för detta nyckelpar. Certifikatet måste ha exakt den publika nyckeln som finns på Rutoken, detta är viktigt. Om vi ​​helt enkelt skapar ett nyckelpar och ett certifikat direkt på klientsidan av applikationen, hur kan servern då dekryptera detta krypterade meddelande? Han vet ju ingenting alls om varken nyckelparet eller certifikatet.

Om du dyker djupare in i detta ämne kan du hitta intressant information på Internet. Det finns vissa certifieringsmyndigheter som vi självklart litar på. Dessa certifikatutfärdare kan utfärda certifikat till användare, de installerar dessa certifikat på sin server. Efter detta, när klienten kommer åt den här servern, ser han just detta certifikat och ser att det utfärdades av en certifieringsmyndighet, vilket betyder att denna server kan litas på. Det finns också gott om information på Internet om hur man ställer in allt på rätt sätt. Du kan till exempel börja med detta.

Om vi ​​återgår till vårt problem verkar lösningen uppenbar. Du måste på något sätt skapa ditt eget certifieringscenter. Men innan det måste du ta reda på på vilken grund certifieringscentret ska utfärda ett certifikat till användaren, eftersom han inte vet något om det. (T.ex. hans förnamn, efternamn, etc.) Det finns något som kallas en certifikatbegäran. Mer information om denna standard finns till exempel på Wikipedia ru.wikipedia.org/wiki/PKCS
Vi kommer att använda version 1.7 - PKCS#10.

Låt oss beskriva algoritmen för att generera ett certifikat på Rutoken (ursprunglig källa: dokumentationen):

1. Vi skapar ett nyckelpar på klienten och sparar det på Rutoken. (sparandet sker automatiskt)
2. Vi skapar en certifikatbegäran på klienten.
3. Från klienten skickar vi denna begäran till servern.
4. När vi får en begäran om ett certifikat på servern utfärdar vi ett certifikat från vår certifieringsmyndighet.
5. Vi skickar detta certifikat till kunden.
6. Vi sparar Rutoken-certifikatet på klienten.
7. Certifikatet måste vara bundet till nyckelparet som skapades i det första steget.

Nu blir det klart hur servern kommer att kunna dekryptera klientens signatur, eftersom den själv utfärdade certifikatet till honom.

I nästa del ska vi titta närmare på hur du ställer in din certifikatutfärdare baserat på det fullfjädrade kryptografibiblioteket med öppen källkod openSSL.

Källa: will.com