Und jetzt, als ich der kryptografischen Workstation, die auf PKCS # 11 cryptoarmpkcs-Token basiert, beinahe die Generierung
selbstsignierter Zertifikate hinzugefügt hätte und bereit wäre, mit dem Schreiben des Artikels zu beginnen, erhielt ich einen Brief wie den folgenden:
Wir sind die UZNIREK-Zertifizierungsstelle. Wir hatten Schwierigkeiten, ES im pkcs # 11-Format für EGAIS auszugeben. Das Portal versteht die ES im Znamerek-CSP-Format nicht. Wir bitten Sie, bei diesem Problem zu helfen.
Ich kannte nicht alle Feinheiten der Arbeit mit EGAIS, aber da es sich um PKCS # 11 handelte, schlug ich vor, das Dienstprogramm cryptoarmpkcs zu verwenden,
um eine Anforderung zu
generieren und ein Zertifikat für ein Token zu installieren, nachdem es von der Zertifizierungsstelle empfangen wurde. Die Antwort, die ich erhielt, war etwas ablenkend:
Tatsache ist, dass wir ES auf RuToken 2.0 über CryptoPro CSP aufgezeichnet haben, aber mit allen richtigen Einstellungen hat das EGAIS-Portal die ES auf dem Schlüsselmedium nicht gesehen, der Client hat uns zur Unterstützung kontaktiert und wir haben festgestellt, dass das Problem nicht besteht Das Schlüsselzertifikat ist in diesem Format geschrieben. Hier finden Sie das Handbuch dev.rutoken.ru/display/KB/RU1051
.
Ich (und nicht nur ich) habe bereits viele Male geschrieben, dass viele kryptografische Token mit Unterstützung der russischen Kryptografie als
normale Flash-Laufwerke verwenden . Dies war nur dann der Fall, wenn der Schlüssel und das Zertifikat nicht als PKCS # 11-Objekte zum Token gelangten. Es war eine Schande, dass sie den Rat nicht befolgten und nicht einmal versuchten, eine Anfrage zu erstellen. Aber dann habe ich beschlossen, alles beiseite zu legen und herauszufinden, wie und auf welchen Zertifikaten für EGAIS Rosalkogolregulirovanie ausgestellt wird. Und wir werden nur kryptografische PKCS # 11-Token berücksichtigen. Die größte Enttäuschung ist der Zugriff auf EGAIS nur über Windows und den IE-Browser. Andererseits kann die Generierung einer Zertifikatanforderung und die Zertifikatinstallation auch unter jedem Betriebssystem durchgeführt werden, wenn Treiber / Bibliotheken für das entsprechende Token vorhanden sind.
Mindestens PKCS # 11-Token JaCarta, RutokenECP-2.0, das LS11SW2016-Software-Token und sogar das
Cloud-Token unterstützen MS Windows, Linux und OS X. Und nicht nur diese Betriebssysteme.
Tatsächlich müssen wir den Entwicklern von EGAIS Tribut zollen. Sie schlugen eine interessante Technologie vor, die den Zugriff auf die Verwendung persönlicher Zertifikate (Zertifikat plus Schlüsselpaar) ermöglicht, die auf kryptografischen Token mit Unterstützung der russischen Kryptografie gespeichert sind, und den Kanal auf RSA-Zertifikaten schützt. Obwohl, wenn sie A sagten, könnte man B sagen, d.h. Schützen Sie den Kanal mit GOST-ov-Algorithmen. Das einzig traurige ist, dass all dies nur für MS Windows (oder irre ich mich?) Oder besser gesagt für Internet Explorer zugeschnitten ist. Dienstprogramme zum Generieren von Zertifikatanforderungen für EGAIS sind an ein bestimmtes Token gebunden.
Das Dienstprogramm cryptoarmpkcs ist jedoch plattformübergreifend. Darüber hinaus kann es mit jedem kryptografischen PKCS # 11-Token arbeiten, das die russische Kryptografie unterstützt.
Was ist die Besonderheit der Zertifikatsanforderung für EGAIS? Das Hauptmerkmal ist das obligatorische Vorhandensein eines zusätzlichen Feldes unstucturedName (UN) (oid - 1.2.840.113549.1.9.2) im definierten Namen des Zertifikatsinhabers (DN-Betreff). Wenn der Inhaber des Zertifikats ein einzelner Unternehmer ist, wird in dieses Feld die Zeile „KPP =“ geschrieben. Wenn der Eigentümer eine juristische Person ist, wird in dieses Feld eine Zeile des folgenden Typs geschrieben:
PPC = reason_code_of_tax_account_account:
In diesem Zusammenhang wurde der Anforderung auf der ersten Seite der Registerkarte "Zertifikatanforderung" die Schaltfläche "EGAIS" hinzugefügt:
Ein weiteres Merkmal ist, dass Inhaber von Zertifikaten für EGAIS Lizenznehmer des FSRAP-Deklarationssystems sein können (oid - 1.2.643.3.6.78.4.4). Dies muss auch beim Erstellen einer Anfrage berücksichtigt werden:
Nachdem alle Felder der Zertifikatanforderung ausgefüllt wurden und Sie die Richtigkeit der Daten bestätigt haben, wird ein Schlüsselpaar generiert und die Anforderung erstellt:
Wenn Sie sich die Anfrage ansehen, sehen Sie darin die oid-s (Extetnded Key Usage), die für EGAIS Rosalkogolregulirovanie erforderlich sind:
Hier sollten Sie (im vorherigen Screenshot) auf die Bezeichnung des Schlüsselpaars achten. In der PKCS # 11-Terminologie ist dies das CKA_LABEL-Attribut für den öffentlichen und den privaten Schlüssel. Nach einem solchen Schema wird vom EGAIS-Abfragegenerator für JaCarta aus CenterInform FSUE eine Bezeichnung (Schlüsselname) erstellt:
Traditionell dreifaches
Zertifikat x public_key x privater Schlüssel
auf dem Token ist über das
Attribut CKA_ID verbunden
::
Die häufigste Methode zur Angabe von CKA_ID ist die Verwendung des Hash-Funktionswerts aus dem Wert des öffentlichen Schlüssels. Diese Methode zum Verknüpfen von drei Objekten wird im NSS-Projekt (Network Security Services) verwendet. Gleichzeitig wird der SHA1-Algorithmus als Hash-Funktion verwendet.
Leider können sowohl CKA_LABEL als auch CKA_ID jederzeit mit einem beliebigen Wert gesetzt / geändert werden. Somit besteht immer die Möglichkeit, dass das Zertifikat dem privaten Schlüssel einer anderen Person zugeordnet wird. Sie müssen nicht erklären, welche Konsequenzen dies haben wird.
Gibt es im Allgemeinen einen strengen mathematischen Algorithmus, mit dem Sie das Tripel CKO_CERTIFICATE x CKO_PRIVATE_KEY x CKO_PUBLIC_KEY zu einem Ganzen verbinden können?
Ja, ein solcher Algorithmus, der auf kryptografischen Mechanismen (CKM_) des Tokens basiert,
existiert .
Leider (obwohl es objektiv verstanden werden kann) wird ein Bündel in einem Tripel durch CKA_LABEL betrachtet, das durch die oben erwähnte Methode gebildet wird. Darüber hinaus wird für die privaten und öffentlichen Schlüssel SKA_ID auf ähnliche Weise gebildet. Für Schlüssel ist dies nur eine Katastrophe, weil Weder CKA_ID noch CKA_LABEL sind jedoch in irgendeiner Weise an den Schlüssel selbst gebunden. Dies gilt auch für das Zertifikat, nachdem es auf dem Token installiert wurde. Wenn bei der herkömmlichen Bildung von CKA_ID als Hash aus dem öffentlichen Schlüssel immer überprüft werden kann, ob einer mit dem anderen übereinstimmt, kann dies nicht durchgeführt werden, wenn CKA_ID und CKA_LABEL auf die oben beschriebene Weise festgelegt werden.
Es kann sich eine Frage stellen, aber wie kann die Konformität für einen privaten Schlüssel überprüft werden? Die Antwort ist einfach: Berechnen Sie den Wert des öffentlichen Schlüssels gegen den privaten. Das Zertifikat enthält natürlich den Wert seines öffentlichen Schlüssels. Darüber hinaus enthält das Zertifikat selbst den CKA_ID-Wert sowohl für den Zertifikatsinhaber (Certificate Subject Key Identifier) als auch für den Zertifikatsverleger (Certificate Authority Key Identifier):
Das Unangenehmste war, dass bei der Installation des Zertifikats nicht das Vorhandensein des privaten Schlüssels überprüft wird, sondern nur der öffentliche Schlüssel ausreicht. In diesem Fall wird das Zertifikat installiert, es befindet sich jedoch kein privater Schlüssel. Ein weiteres Problem. Dies ist eine Suche nach öffentlichen Schlüsseln nach TIN. Stellen Sie sich vor, eine Person hat eine TIN und mehrere Schlüssel für verschiedene Zertifikate. Zu welchem gehört? Danach wird klar, dass JaCarta
nur ein Zertifikat und ein Schlüsselpaar haben muss:
Dieser Fehler kann mit der Duplizierung von Zertifikaten zusammenhängen. Im JaCarta Single Client im Administratormodus auf der Registerkarte GOST Nach Eingabe des PIN-Codes sollten ein öffentlicher, ein privater Schlüssel und ein Zertifikat sichtbar sein. In diesem Fall ist die Schlüsselduplizierung sichtbar. Sie müssen die zusätzlichen entfernen. Setzen Sie das Medium erneut in den USB-Anschluss ein und versuchen Sie erneut, die UTM zu installieren. Wenn der Fehler weiterhin besteht, initialisieren Sie Jacarta gemäß Link 1 und führen Sie den Generierungsprozess erneut durch.
Hoffen wir, dass dieses Manko beseitigt wird. Möglicherweise fragen Sie, wie das Dienstprogramm cryptoarmpkcs für EGAIS das Zertifikat installiert. Aus Gründen der vollständigen Kompatibilität mit JaCarta haben wir die Ideologie beibehalten, dass CKA_ID und CKA_LABEL für Schlüssel identisch sind. Aber erst, nachdem das Zertifikat auf dem Token installiert und im Schlüsselpaar gebunden wurde. Bis dahin wird das Schlüsselpaar CKA_ID gleich dem Hashwert des öffentlichen Schlüssels gehalten.
Nach der Installation des Zertifikats können Sie damit
Dokumente signieren .
Informationen zu selbstsignierten Zertifikaten finden Sie
hier :
Verteilungen befinden sich am selben Ort.