Verwenden von kryptografischen PKCS # 11-Token-Mechanismen in Skriptsprachen

In seinen Kommentaren zum Artikel „Ein englischsprachiges plattformübergreifendes Dienstprogramm zum Anzeigen russisch qualifizierter x509-Zertifikate“ stellte Pas PKCS # 11-Token sehr korrekt fest, dass sie „sich alle selbst zählen können“. Ja, Token sind eigentlich kryptografische Computer. Und es ist natürlich, diese Computer in Skriptsprachen verwenden zu wollen, sei es Python, Perl oder Ruby. Wir haben bereits die Verwendung von PKCS # 11-Token mit Unterstützung für die russische Kryptographie in Python zum Signieren und Verschlüsseln von Dokumenten in Betracht gezogen, um eine Zertifikatanforderung zu erstellen:



Hier setzen wir die Diskussion über die Tcl-Sprache fort. Im vorherigen Artikel haben wir beim Anzeigen und Überprüfen von Zertifikaten, die auf PKCS # 11-Token / Smartcards gespeichert sind, das Paket TclPKCS11 Version 0.9.9 verwendet , um darauf zuzugreifen (Zertifikate). Wie bereits erwähnt, wurde das Paket leider für die RSA-Kryptographie unter Berücksichtigung des PKCS # 11 v.2.20-Standards entwickelt. Heute wird bereits der PKCS # 11 v.2.40-Standard verwendet, und das technische Komitee für Kryptographie TK-26 orientiert sich daran und gibt Empfehlungen für inländische Hersteller von Token / Smartcards heraus, die die russische Kryptographie unterstützen. Und mit all dem ist ein neues Paket TclPKCS11 Version 1.0.1 erschienen . Wir werden sofort reservieren, dass alle kryptografischen Schnittstellen für RSA in der neuen Version des TclPKCS11 v.10.1-Pakets gespeichert werden. Die Paketbibliothek ist in C-Sprache geschrieben.

Also, was ist neu im Paket? Zunächst wurde ein Befehl hinzugefügt, mit dem Sie eine Liste der vom verbundenen Token unterstützten kryptografischen Mechanismen abrufen können:

::pki::pkcs11::listmechs <handl> <slotid> 

Hier erfahren Sie, wie Sie eine Liste der Slots mit verbundenen Token erhalten (procedure - proc :: slots_with_token):

 proc ::slots_with_token {handle} { set slots [pki::pkcs11::listslots $handle] # puts "Slots: $slots" array set listtok [] foreach slotinfo $slots { set slotid [lindex $slotinfo 0] set slotlabel [lindex $slotinfo 1] set slotflags [lindex $slotinfo 2] if {[lsearch -exact $slotflags TOKEN_PRESENT] != -1} { set listtok($slotid) $slotlabel } } #     parray listtok return [array get listtok] } 

Nehmen Sie ein einfaches Skript:

 #!/usr/bin/tclsh lappend auto_path . package require pki::pkcs11 #      RuToken set lib "/usr/local/lib64/librtpkcs11ecp_2.0.so" <source lang="bash">set handle [pki::pkcs11::loadmodule $lib] #    #       set labslot [::slots_with_token $handle] if {[llength $labslot] == 0} { puts "     " exit } set slotid 0 set lmech [pki::pkcs11::listmechs $handle $slotid] set i 0 foreach mm $lmech { #   if {[string first "GOSTR3410" $mm] != -1} { puts -nonewline "[lindex $mm 0] " if {$i == 2} {puts "";set i 0} else { incr i} } } puts "\n" exit 

Mit diesem Skript können Sie eine Liste der GOSTR3410-Kryptografiemechanismen abrufen, die von Token der RuToken-Familie unterstützt werden. Nehmen wir zunächst, wie Pas in dem Artikel schrieb, „Rutoken Light, das von allen Arten von EDOs geliebt wird“:

 $ tclsh TEST_for_HABR.tcl listtok(0) = ruToken Lite 0 {ruToken Lite } $ 

Und natürlich stellt sich heraus, dass er keinen GOST-Mezanismus unterstützt, der bewiesen werden sollte. Wir nehmen ein weiteres Token Rutoken EDS:

 $ tclsh TEST_for_HABR.tcl listtok(0) = ruToken ECP } 0 {ruToken ECP } CKM_GOSTR3410_KEY_PAIR_GEN CKM_GOSTR3410 CKM_GOSTR3410_DERIVE CKM_GOSTR3410_WITH_GOSTR3411 $ 

Ja, dieses Token unterstützt die russische Kryptografie, aber nur die Signatur von GOST R 34.10-2001, die fast nicht mehr verwendet wird . Wenn Sie jedoch das Rutoken EDS-2.0-Token verwenden, ist alles in Ordnung. Es unterstützt GOST R 34.10-2012 mit den Schlüsseln 256 und 512 Bit:

 $ tclsh TEST_for_HABR.tcl listtok(0) = RuTokenECP20 0 {RuTokenECP20 } CKM_GOSTR3410_KEY_PAIR_GEN CKM_GOSTR3410 CKM_GOSTR3410_DERIVE CKM_GOSTR3410_512_KEY_PAIR_GEN CKM_GOSTR3410_512 CKM_GOSTR3410_12_DERIVE CKM_GOSTR3410_WITH_GOSTR3411 CKM_GOSTR3410_WITH_GOSTR3411_12_256 CKM_GOS TR3410_WITH_GOSTR3411_12_512 $ 

Wenn wir über die Unterstützung der russischen Kryptographie, einschließlich Grasshopper- und Magma-Verschlüsselungsalgorithmen, mit dem einen oder anderen Token gesprochen haben, dann wird dies am besten von Software und Cloud- Token unterstützt, und dies ist natürlich:

 $ tclsh TEST_for_HABR.tcl listtok(0) = LS11SW2016_LIN_64 0 {LS11SW2016_LIN_64 } 

 $ 

Wir fahren mit der nächsten neuen Funktion fort, die dem Paket hinzugefügt wurde:

 set listcertsder [pki::pkcs11::listcertsder $handle $slotid] 

Diese Funktion gibt eine Liste von Zertifikaten zurück, die ohne Token gespeichert sind. Die Frage stellt sich natürlich, aber wie unterscheidet sie sich von der bestehenden Funktion pki :: pkcs11 :: listcerts?

Erstens verwendet die neue Funktion das Paket :: pki nicht. Eines der zurückgegebenen Elemente ist das Element cert_der, das das vollständige Zertifikat enthält. Dies ist beispielsweise praktisch, wenn Sie ein Zertifikat exportieren oder seinen Fingerabdruck empfangen. Zuvor musste ich das vollständige Zertifikat aus dem tbs-Zertifikat und seiner Signatur abholen. Eine vollständige Liste der zurückgegebenen Elemente für jedes Zertifikat ist beim Drucken des Inhalts eines Zertifikats deutlich sichtbar:

 . . . array set derc [[pki::pkcs11::listcertsder $handle $slotid] 0] parray derc derc(cert_der) = 3082064a … derc(pkcs11_handle) = pkcsmod0 derc(pkcs11_id) = 5882d64386211cf3a8367d2f87659f9330e5605d derc(pkcs11_label) = Thenderbird-60   derc(pkcs11_slotid) = 0 derc(type) = pkcs11 . . . 

Das Element pkcs11_id speichert das Attribut CKA_ID, den Wert des SHA-1-Hashs aus dem öffentlichen Schlüssel. Das cert_der-Element ist der CKA_VALUE des Zertifikats, pkcs11_label ist CKA_LABEL.

Das Element pkcs11_id (CKA_ID in der PKCS # 11-Standardterminologie) ist zusammen mit der Bibliothek pkcs11_handle und der Slot-ID mit dem Token pkcs11_slotid ein Schlüsselelement für den Zugriff auf Schlüssel und Zertifikate, die auf Token gespeichert sind.

Wenn wir also die Bezeichnung (pkcs11_label) des Zertifikats oder der Schlüssel ändern möchten, führen wir einen Befehl des Formulars aus:

 pki::pkcs11::rname <cert|key|all> <  > 

Um ein Zertifikat oder Schlüssel von einem Token zu entfernen, wird ein Befehl des Formulars ausgeführt:

 pki::pkcs11::delete <cert|key|all> <  > 

Die Liste der Schlüsselelemente kann wie folgt gebildet werden:

 set listparam {} lappend listparam pkcs11_handle lappend listparam $handle lappend listparam pkcs11_slotid lappend listparam $pkcs11_slotid lappend listparam pkcs11_id lappend listparam $pkcs11_id 

usw.
Der Funktionsaufruf sieht in diesem Fall folgendermaßen aus (wir löschen das Zertifikat und die damit verbundenen Schlüssel):

 pki::pkcs11::delete all $listparam 

Der Leser hat wahrscheinlich bereits vermutet, dass diese Liste als Diktatwörterbuch angeordnet werden kann:

 set listparam [dict create pkcs11_handle $pkcs11_handle] dict set listparam pkcs11_slotid $pkcs11_slotid) dict set listparam pkcs11_id $pkcs11_id 

Es gibt andere Möglichkeiten, zum Beispiel durch ein Array.

Wir stellen erneut fest, dass die Elemente pkcs11_handle und pkcs11_slotid immer in der Liste der Schlüsselelemente vorhanden sein sollten, die das verbundene Token eindeutig identifizieren. Der Rest der Zusammensetzung wird durch eine bestimmte Funktion bestimmt.

Die folgende Funktion wird verwendet, um das Zertifikat auf dem Token zu installieren:

 set pkcs11_id_cert [::pki::pkcs11::importcert <cert_der_hex> <  > 

Die Funktion gibt den Wert CKA_ID hexadezimal zurück. Die Liste der Schlüsselparameter bestimmt das Token, auf dem sich das Zertifikat befindet:

 {pkcs11_handle <handle> pkcs11_slotid <slotid>} 

Als nächstes kommt unsere Hash-Berechnung. In der russischen Kryptographie werden heute drei Arten von Hash-Funktionen verwendet:
- GOST R 34.11-94
- GOST R 34 .11-2012 mit einem Hashwert von 256 Bit (stribog256)
- GOST R 34 .11-2012 mit einem Hashwert von 512 Bit (stribog512)
Um festzustellen, welcher Hash das Token unterstützt, haben wir die Funktion pki :: pkcs11 :: listmechs.

Die Hash-Berechnungsfunktion hat die folgende Form:

 set <> [pki::pkcs11::digest <gostr3411|stribog256|stribog512|sha1> <  > <  >] 

Beachten Sie, dass das Berechnungsergebnis der Berechnung hexadezimal dargestellt wird:

 . . . set listparam [dict create pkcs11_handle $pkcs11_handle] dict set listparam pkcs11_slotid $pkcs11_slotid set res_hex [pki::pkcs11::digest stribog256 0123456789 $listparam] puts $res_hex 086f2776f33aae96b9a616416b9d1fe9a049951d766709dbe00888852c9cc021 

Nehmen wir zur Überprüfung openssl mit Unterstützung für die russische Kryptographie :

 $ echo -n "0123456789"|/usr/local/lirssl_csp_64/bin/lirssl_s tatic dgst -md_gost12_256 (stdin)= 086f2776f33aae96b9a616416b9d1fe9a0499 51d766709dbe00888852c9 cc021 $ 

Wie Sie sehen können, ist das Ergebnis identisch.

Um eine elektronische Signatur zu überprüfen, sei es ein Zertifikat oder eine Liste widerrufener Zertifikate oder ein signiertes Dokument in einem Format, benötigen wir nur noch die Signaturüberprüfungsfunktion:

 set result [pki::pkcs11::verify < > < > <  >]] 

Wenn die Signatur die Überprüfung bestanden hat, wird 1 zurückgegeben, andernfalls 0. Zur Überprüfung der elektronischen Signatur sind die Dokumentensignatur selbst, der durch die Art der Signatur bestimmte Dokument-Hash und der öffentliche Schlüssel, mit dem die Signatur erstellt wurde, mit allen Parametern (Wert, Typ und Parameter) erforderlich. . Alle Informationen zum Schlüssel in Form der Struktur publickeyinfo asn1 sollten in die Liste der Schlüsselelemente aufgenommen werden:

lpkar (pkcs11_handle) = pkcsmod0
lpkar (pkcs11_slotid) = 0
lpkar (pubkeyinfo) = 301f06082a85030701010101301306072a85030202240
006082a8503070101020203430004407d9306687af5a8e63af4b09443ed2e03794be
10eba6627bf5fb3da1bb474a3507d2ce2cd24b63c727a02521897d1dd6edbdc7084d
8886a39289c3f81bdf2e179

Die öffentliche Schlüsselstruktur von ASN1 stammt aus dem Unterzeichnerzertifikat:

 proc ::pki::x509::parse_cert_pubkeyinfo {cert_hex} { array set ret [list] set wholething [binary format H* $cert_hex] ::asn::asnGetSequence wholething cert ::asn::asnPeekByte cert peek_tag if {$peek_tag != 0x02} { # Version number is optional, if missing assumed to be value of 0 ::asn::asnGetContext cert - asn_version ::asn::asnGetInteger asn_version ret(version) } ::asn::asnGetBigInteger cert ret(serial_number) ::asn::asnGetSequence cert data_signature_algo_seq ::asn::asnGetObjectIdentifier data_signature_algo_seq ret(data_signature_algo) ::asn::asnGetSequence cert issuer ::asn::asnGetSequence cert validity ::asn::asnGetUTCTime validity ret(notBefore) ::asn::asnGetUTCTime validity ret(notAfter) ::asn::asnGetSequence cert subject ::asn::asnGetSequence cert pubkeyinfo binary scan $pubkeyinfo H* ret(pubkeyinfo) return $ret(pubkeyinfo) } 

Der Skripttext zum Überprüfen der elektronischen Signatur von Zertifikaten aus einer Datei befindet sich
Speichern Sie das Skript in einer Datei und versuchen Sie es auszuführen:

 $./verify_cert_with_pkcs11.tcl Copyright(C) Orlov Vladimir (http://museum.lissi-crypto.ru/) Usage: verify_cert_with_pkcs11 <file with certificate> <file with CA certificate> $ 

Man fragt sich, was ist mit den Zertifikaten auf dem Token? Zunächst haben wir das Problem der Verwendung von PKCS # 11-Kryptografiemaschinen gelöst. Wir haben sie benutzt. Um ein Zertifikat mit einem Token auszustrahlen, gibt es eine Funktion des Pakets pki :: pkcs11 :: listcertsder, mit der Sie das gewünschte Zertifikat auswählen und überprüfen können. Dies kann als Hausaufgabe betrachtet werden.

Das Erscheinen einer neuen Version des TclPKCS11v.1.0.1-Pakets ermöglichte es, das Dienstprogramm zum Anzeigen von Zertifikaten zu verfeinern, indem die Funktionen zum Importieren eines Zertifikats für ein Token, Entfernen von Zertifikaten und zugehörigen Schlüsseln aus einem Token, Ändern der Bezeichnungen von Zertifikaten und Schlüsseln usw. hinzugefügt wurden.



Das wichtigste hinzugefügte Merkmal ist die Überprüfung der digitalen Signatur des Zertifikats:



Der aufmerksame Leser bemerkte richtig, dass nichts über die Erzeugung des Schlüsselpaars gesagt wurde. Diese Funktion wird auch dem TclPKCS11-Paket hinzugefügt:

 array set genkey [pki::pkcs11::keypair < > <> <  >] 

Wie die Funktionen aus dem TclPKCS11-Paket verwendet werden, erfahren Sie natürlich im Quellcode des Dienstprogramms.

Die Funktion zum Generieren eines Schlüsselpaars wird im nächsten Artikel ausführlich erläutert, wenn das Dienstprogramm eine Anforderung für ein qualifiziertes Zertifikat mit der Generierung eines Schlüsselpaars auf dem PKCS # 11-Token erstellt, dem Mechanismus zum Abrufen eines Zertifikats in einem Zertifizierungscenter ( CA ) und zum Importieren in ein Token:



Im selben Artikel wird die Funktion des Signierens eines Dokuments betrachtet. Dies wird der letzte Artikel in dieser Reihe sein. Als nächstes ist eine Reihe von Artikeln zur Unterstützung der russischen Kryptographie in der derzeit in Mode befindlichen Ruby-Skriptsprache geplant. Bis dann!