Erfahrungen mit der Technologie Rutoken zur Registrierung und Authentifizierung von Benutzern im System (Teil 1)

Guten Tag! Ich möchte meine Erfahrungen zu diesem Thema teilen.

Routoken ist eine Hardware- und Softwarelösung im Bereich Authentifizierung, Schutz von Informationen und elektronischer Unterschrift. Im Grunde genommen handelt es sich um einen USB-Stick, der Authentifizierungsdaten speichern kann, die der Benutzer für den Zugang zum System verwendet.

In diesem Beispiel wird Routoken ECP 2.0 verwendet.

Um mit diesem Routoken zu arbeiten, ist es notwendig, den Treiber unter Windows zu installieren..

Für Windows sorgt die Installation nur des Treibers dafür, dass alles, was benötigt wird, installiert wird, sodass das OS Ihren Routoken erkennt und Sie damit arbeiten können.

Mit Routoken kann auf verschiedene Weise interagiert werden. Man kann von der Server-Seite der Anwendung darauf zugreifen, oder direkt von der Client-Seite. In diesem Beispiel wird die Interaktion mit Routoken aus der Client-Seite der Anwendung betrachtet.

Die Client-Seite der Anwendung interagiert mit dem Routoken über das Routoken-Plugin. Dies ist ein Programm, das separat für jeden Browser installiert wird. Für Windows müssen Sie einfach das Plugin herunterladen und installieren, das sich unter diesem Link befindet..

Alles klar, jetzt können wir von der Client-Seite der Anwendung mit Routoken interagieren.

In diesem Beispiel wird die Idee der Implementierung eines Benutzer-Authentifizierungsalgorithmus im System unter Verwendung des Challenge-Response-Schemas betrachtet.

Der Kern der Idee ist folgender:

1. Der Client sendet eine Authentifizierungsanforderung an den Server.
2. Der Server sendet im Gegenzug eine zufällige Zeichenfolge als Antwort auf die Anfrage des Clients.
3. Der Client ergänzt diese Zeichenfolge um zufällige 32 Bit.
4. Der Client signiert die erhaltene Zeichenfolge mit seinem Zertifikat.
5. Der Client sendet die erhaltene kodierte Nachricht an den Server.
6. Der Server überprüft die Signatur und erhält die ursprüngliche nicht kodierte Nachricht.
7. Der Server trennt die letzten 32 Bit von der erhaltenen nicht kodierten Nachricht.
8. Der Server vergleicht das erhaltene Ergebnis mit der Nachricht, die bei der Authentifizierungsanfrage gesendet wurde.
9. Wenn die Nachrichten identisch sind, gilt die Authentifizierung als erfolgreich.

Im obigen Algorithmus gibt es ein Konzept namens Zertifikat. Im Rahmen dieses Beispiels ist es notwendig, eine gewisse kryptografische Theorie zu verstehen. Auf Habr gibt es einen ausgezeichneten Artikel zu diesem Thema..

In diesem Beispiel verwenden wir asymmetrische Verschlüsselungsalgorithmen. Für die Umsetzung asymmetrischer Algorithmen ist es notwendig, ein Schlüsselpaar und ein Zertifikat zu haben.

Das Schlüsselpaar besteht aus zwei Teilen: einem privaten Schlüssel und einem öffentlichen Schlüssel. Der private Schlüssel, wie der Name schon sagt, sollte geheim bleiben. Wir verwenden ihn zur Entschlüsselung von Informationen. Der öffentliche Schlüssel kann überall verteilt werden. Er wird zum Verschlüsseln von Daten verwendet. So kann jeder Benutzer Daten verschlüsseln, indem er den öffentlichen Schlüssel nutzt, aber nur der Besitzer des privaten Schlüssels kann diese Informationen entschlüsseln.

Ein Zertifikat ist ein elektronisches Dokument, das Informationen über den Benutzer enthält, dem das Zertifikat gehört, sowie den öffentlichen Schlüssel. Mit einem Zertifikat kann der Benutzer beliebige Daten signieren und an den Server senden, der diese Signatur überprüfen und die Daten entschlüsseln kann.

Um eine Nachricht korrekt mit dem Zertifikat zu signieren, muss es richtig erstellt werden. Dazu wird zunächst ein Schlüsselpaar auf dem RuToken erstellt, und dann muss das Zertifikat an den öffentlichen Schlüssel dieses Schlüsselpaares gebunden werden. Das Zertifikat muss genau den öffentlichen Schlüssel enthalten, der sich auf dem RuToken befindet; das ist wichtig. Wenn wir einfach ein Schlüsselpaar und ein Zertifikat direkt auf der Client-Seite der Anwendung erstellen, wie kann der Server dann diese verschlüsselte Nachricht entschlüsseln? Er weiß ja nichts über das Schlüsselpaar oder das Zertifikat.

Wenn man tiefer in dieses Thema eintaucht, findet man interessante Informationen im Internet. Es gibt einige Zertifizierungsstellen, denen wir von vornherein vertrauen. Diese Zertifizierungsstellen können den Benutzern Zertifikate ausstellen, die sie auf ihren Servern installieren. Danach, wenn der Client diesen Server anruft, sieht er dieses Zertifikat und erkennt, dass es von der Zertifizierungsstelle ausgestellt wurde, was bedeutet, dass man diesem Server vertrauen kann. Mehr Informationen dazu, wie man alles richtig einrichtet, sind ebenfalls reichlich im Internet zu finden. Man kann zum Beispiel mit diesem Beispiel anfangen..

Wenn wir zu unserer Aufgabe zurückkehren, erscheint die Lösung offensichtlich. Wir müssen irgendwie unsere eigene Zertifizierungsstelle einrichten. Aber zuerst müssen wir klären, auf welcher Grundlage die Zertifizierungsstelle dem Benutzer ein Zertifikat ausstellen sollte, denn er weiß nichts über ihn. (Zum Beispiel seinen Namen, Nachnamen usw.) Es gibt eine Sache, die als Zertifikatsanfrage bezeichnet wird. Weitere Informationen zu diesem Standard finden Sie beispielsweise auf Wikipedia. de.wikipedia.org/wiki/PKCS
Wir werden Version 1.7 — PKCS#10 verwenden.

Wir beschreiben den Algorithmus zur Erstellung eines Zertifikats auf RuToken (Ursprung — Dokumentation):

1. Auf dem Client erstellen wir ein Schlüsselpaar und speichern es auf RuToken. (Die Speicherung erfolgt automatisch.)
2. Auf dem Client erstellen wir eine Zertifikatsanfrage.
3. Von dem Client senden wir diese Anfrage an den Server.
4. Beim Empfang der Zertifikatsanfrage auf dem Server stellen wir ein Zertifikat von unserer Zertifizierungsstelle aus.
5. Wir senden dieses Zertifikat an den Client.
6. Auf dem Client speichern wir das Zertifikat auf RuToken.
7. Das Zertifikat muss mit dem Schlüsselpaar verknüpft werden, das im ersten Schritt erstellt wurde.

Jetzt ist klar, wie der Server die Unterschrift des Clients entschlüsseln kann, denn er hat das Zertifikat selbst ausgestellt.

Im nächsten Teil werden wir detailliert ansehen, wie man seine eigene Zertifizierungsstelle auf der Grundlage einer vollständigen Open-Source-Kryptografiebibliothek openSSL einrichtet.

Quelle: habr.com