Geekly articles weekly

PKCS # 11-Token: Schlüsselpaargenerierung und Nichtextrahierbarkeit des privaten Schlüssels (Fortsetzung)

BildIm vorherigen Artikel „PKCS # 11-Token: Zertifikate und private Schlüssel “ haben wir untersucht, wie das auf dem Token / der Smartcard gespeicherte Trio- Zertifikat x Öffentlicher Schlüssel x Privater Schlüssel eindeutig mit der PKCS # 11 v.2.40-Schnittstelle verknüpft werden kann. In diesem Artikel werden wir über die Schlüsselpaargenerierung sprechen. Wir werden uns wie beim letzten Mal auf „GOST R 34.10-2012 Information Technology. Kryptografische Informationssicherheit. Die Prozesse der Bildung und Überprüfung elektronischer digitaler Signaturen . “

Was ist ein Schlüsselpaar?


Das Schlüsselpaar enthält zwei Schlüssel:

  • / /Private key — , . / ;

  • / / Public key — , , .

Es ist zu beachten, dass der private und der öffentliche Schlüssel nicht nur ihre Werte sind (für den öffentlichen Schlüssel GOST R 34.10-2001 sind es 512 Bit), sondern auch die Parameter des digitalen Signaturschemas ( Abschnitt 5.2 von GOST R 34.10-2012 ). In Zukunft werden wir der Einfachheit halber die Parameter des digitalen Signaturschemas die Parameter (Kryptoparameter) des Schlüsselpaars nennen.

Der öffentliche Schlüssel der Signatur wird als Wert einer Funktion des privaten Schlüssels berechnet, aber die Kenntnis des öffentlichen Schlüssels macht es unmöglich, den privaten Schlüssel zu bestimmen.

Für Schlüsselpaare GOST R 34.10-2001 und GOST R 34.10-2012 mit einer privaten Schlüssellänge von 256 Bit (ein öffentlicher Schlüssel ist 512 Bit) werden die folgenden kryptografischen Parameter definiert:
  1. id-GostR3410-2001-CryptoPro-A-ParamSet;
  2. id-GostR3410-2001-CryptoPro-B-ParamSet;
  3. id-GostR3410-2001-CryptoPro-C-ParamSet;
  4. id-GostR3410-2001-CryptoPro-XchA-ParamSet;
  5. id-GostR3410-2001-CryptoPro-XchB-ParamSet.

Für Schlüsselpaare GOST R 34.10-2012 mit einer privaten Schlüssellänge von 512 Bit (ein öffentlicher Schlüssel ist 1024 Bit) werden die folgenden kryptografischen Parameter definiert ("Informationstechnologie. Kryptografischer Schutz von Informationen. Elliptische Kurvenparameter für kryptografische Algorithmen und Protokolle"):
  1. id-tc26-gost-3410-2012-512-paramSetA;
  2. id-tc26-gost-3410-2012-512-paramSetB.

Die Zusammensetzung der Kryptoparameter ist in Abschnitt 5.2 von GOST R 34.10-2012 definiert . Diese Struktur enthält eine Primzahl q - die Reihenfolge der Untergruppe der Punktgruppe der elliptischen Kurve:

Bild

Und es bestimmt die Länge des privaten / öffentlichen Schlüssels und die Richtigkeit des privaten Schlüssels:

Bild- Die Länge des privaten Schlüssels beträgt 256 Bit;

Bild- Die Länge des privaten Schlüssels beträgt 512 Bit.
Der öffentliche Schlüssel wird also vom privaten Schlüssel erhalten.

Und woher kommt der private Schlüssel?


Um einen privaten Schlüssel zu erhalten, müssen Sie zunächst entscheiden, wie lang der private Schlüssel sein soll (256 oder 512 Bit), und dann die kryptografischen Parameter des Schlüsselpaars festlegen. Nun nehmen wir den Zufallszahlensensor und erhalten eine Zufallszahl der entsprechenden Länge. Eigentlich sollte diese Zufallszahl der Wert d des privaten Schlüssels (Signaturschlüssel d) werden. Dieser Wert sollte die folgende Regel erfüllen:

0 <d <q , wobei q eine Primzahl aus Kryptoparametern ist.

Was ist, wenn diese Bedingung nicht erfüllt ist? Wenn d == 0 , dann generiere einfach eine neue Zufallszahl. Andernfalls reicht es aus, den Rest der Division des Wertes von d , der q überschreitet , durch eine ganze Zahl durch zu teilenq (d% q) . Der Rest wird zum Wert des privaten Schlüssels.

Deshalb stellt die Regulierungsbehörde (FSB von Russland) besondere Anforderungen an den Zufallszahlensensor.

Als Beispiel für die Hauptquelle zum Füllen des Puffers:

  • Zufallszahlen umfassen:
  • Prozessor-TSC-Register - Prozessortaktzähler;
  • AGB-Zeitzähler
  • Auto-Inkrement-Zähler in einem separaten Thread;
  • Standardfunktion rand ();
  • Mauskoordinaten.

Als zusätzliche Quellen zum Füllen dieses Puffers können:

  • Der Prozesszähler im Benutzermodus;
  • Hochauflösender Windows-Timer.

Damit das PKCS # 11-Token / die Smartcard ein Schlüsselpaar in sich selbst generieren kann, muss ein Token / eine Smartcard des integrierten Hardware-Zufallszahlensensors vorhanden sein, die den Anforderungen des Controllers entspricht. Und nur dann können wir über die Nichtentfernbarkeit des privaten Schlüssels sprechen.

Um ein Schlüsselpaar zu generieren, wird die Funktion C_GenerateKeyPair verwendet . Abhängig davon, welches Schlüsselpaar (mit welcher privaten Schlüssellänge 256 oder 512 Bit) wir generieren, wird der entsprechende Mechanismus verwendet:

  • CKM_GOSTR3410_KEY_PAIR_GEN für ein Schlüsselpaar mit einem privaten 256-Bit-Schlüssel;
  • CKM_GOSTR3410_512_KEY_PAIR_GEN für ein Schlüsselpaar mit einem privaten 512-Bit-Schlüssel.

Beim Generieren eines Schlüsselpaars werden dessen Attribute festgelegt, z. B. Kryptoparameter:

Bild

Wir sind an Attributen zum Abrufen privater Schlüssel interessiert.


Dies war früher das Attribut CKA_SENSITIVE, das für das Abrufen des Werts des privaten Schlüssels verantwortlich ist. Wenn der Wert des Attributs CKA_SENSITIVE auf CK_TRUE festgelegt ist, kann der private Schlüssel nicht aus dem Token im Clear extrahiert werden. Mit dem zweiten Attribut CKA_EXTRACTABLE können Sie den privaten Schlüssel in verschlüsselter Form abrufen. Dazu muss es auf CK_TRUE gesetzt sein.

Wenn Sie das Attribut CKA_SENSITIVE auf CK_TRUE und das Attribut CKA_EXTRACTABLE auf CK_FALSE setzen, wenn Sie das Schlüsselpaar generieren, kann der private Schlüssel nicht wiederhergestellt werden. Die Möglichkeit, festzustellen, ob der Schlüssel exportierbar ist, ist im Redfox-Browser verfügbar:

Bild

Jemand wird sagen - was ist, wenn wir die Werte dieser Attribute ändern. Dies ist in der Regel nicht möglich, der Schutz kann nicht gesenkt werden, genauso wie „Sie können den Grad nicht senken“. Auf die gleiche Weise können Sie den privaten Schlüssel nach dem Import in das Token nicht wiederherstellbar machen (es sei denn, der Token / die Smartcard erlaubt natürlich den Import). Nach dem Erstellen (oder während der Erstellung) des Objekts CKO_PRIVATE_KEY müssen Sie CKA_SENSITIVE = CK_TRUE und das Attribut CKA_EXTRACTABLE = CK_FALSE festlegen .

Im letzteren Fall (beim Import) sollte berücksichtigt werden, dass der private Schlüssel zwar nicht mehr wiederherstellbar war, jedoch von der Seite (z. B. von PKCS # 12 ) angezeigt wurde und es keine Garantie dafür gibt, dass es an anderer Stelle kein Duplikat davon gibt.

Und hier würde es nicht schaden, Sie daran zu erinnern, lieber LeserSicherheit wird nur durch KOMPLEX organisatorische und technische Maßnahmen gewährleistet . Daher wird es nicht funktionieren, Lücken in der organisatorischen Sicherheit auf Kosten technischer Mittel zu schließen und umgekehrt - alles sollte organisch koordiniert werden. Einschließlich beim Zugriff auf den Wert des privaten Schlüssels.

Stellen Sie sicher, dass das Token / die Smartcard vollwertige PKCS # 11-Objekte (CKO_PRIVATE_KEY, CKO_PUBLIC_KEY, CKO_CERTIFICATE) enthält, die an kryptografischen Operationen am Token selbst beteiligt sind. Verwenden Sie dazu das Dienstprogramm p11conf, das kostenlos heruntergeladen werden kann:

$ /usr/local/bin64/p11conf -h
usage:  /usr/local/bin64/p11conf [-hitsmIupPred] -A APIpath [-c slotID -U userPin -S SOPin -n newPin -L label]
        -h display usage
        -i display PKCS#11 library info
        -s display slot(s) info (-c slotID is optional)
        -t display token(s) info (-c slotID is optional)
Others must use -c slotID
        -m display mechanism list
        -I initialize token 
        -u initialize user PIN
        -p set the user PIN
        -P set the SO PIN
        -r remove all objects
        -e enumerate objects
        -d dump all object attributes
Copyright(C) 2011-2016
$

Um zu sehen, welche Objekte sich auf dem Token befinden, reicht es aus, einen Befehl des Formulars auszuführen:

bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 -e
Enter user PIN: ********
Token objects:
1: CKO_PRIVATE_KEY
         label: 'LS11SW2016:; ..;0x23855(145493)'
2: CKO_PUBLIC_KEY
         label: 'LS11SW2016:; ..;0x23855(145493)'
3: CKO_CERTIFICATE
         label: 'LS11SW2016:; ..;0x23855(145493)'
…
OK
bash-4.3$

Wenn solche Objekte auf dem Token fehlen und sie sagen, dass das PKCS # 11-Token mit dem nicht abrufbaren Schlüssel verwendet wird, ist dies höchstwahrscheinlich nicht der Fall. Höchstwahrscheinlich wird das Token einfach als Flash-Laufwerk mit einem PIN-Code verwendet, und das Zertifikat und die Schlüssel werden als CKO_DATA- Objekte gespeichert .

Um nicht nur zu sehen, welche Objekttypen auf dem Token gespeichert sind, sondern auch Objekte mit allen Attributen, müssen Sie zusätzlich das Flag –d verwenden :

bash-4.3$ /usr/local/bin64/p11conf -A /usr/local/lib64/libls11sw2016.so -c 0 –e -d
Enter user PIN: ********
Token objects:
1: CKO_PRIVATE_KEY
	 label: 'LS11SW2016:; ..;0x23855(145493)'
==================================
Object handle: 0x1
----------------------------------
CKA_CLASS
0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
CKA_TOKEN
0x01, 
CKA_PRIVATE
0x01, 
CKA_LABEL
0x4c, 0x53, 0x31, 0x31, 0x53, 0x57, 0x32, 0x30, 
0x31, 0x36, 0x3a, 0xd0, 0x9e, 0xd0, 0x9e, 0xd0, 
0x9e, 0x20, 0xd0, 0x9b, 0xd0, 0x98, 0xd0, 0xa1, 
0xd0, 0xa1, 0xd0, 0x98, 0x2d, 0xd0, 0xa1, 0xd0, 
0xbe, 0xd1, 0x84, 0xd1, 0x82, 0x3b, 0xd0, 0x9c, 
0xd0, 0xb0, 0xd1, 0x81, 0xd0, 0xbb, 0xd0, 0xbe, 
0x20, 0xd0, 0x90, 0x2e, 0xd0, 0x90, 0x2e, 0x3b, 
0x30, 0x78, 0x32, 0x33, 0x38, 0x35, 0x35, 0x28, 
0x31, 0x34, 0x35, 0x34, 0x39, 0x33, 0x29, 
CKA_VALUE: attribute sensitive
CKA_KEY_TYPE
0x03, 0x10, 0x32, 0xd4, 0x00, 0x00, 0x00, 0x00, 
CKA_SUBJECT
0x30, 0x81, 0x9b, 0x31, 0x0b, 0x30, 0x09, 0x06, 
0x03, 0x55, 0x04, 0x06, 0x13, 0x02, 0x52, 0x55, 
0x31, 0x1a, 0x30, 0x18, 0x06, 0x03, 0x55, 0x04, 
0x03, 0x0c, 0x11, 0xd0, 0x9c, 0xd0, 0xb0, 0xd1, 
0x81, 0xd0, 0xbb, 0xd0, 0xbe, 0x20, 0xd0, 0x90, 
0x2e, 0xd0, 0x90, 0x2e, 0x31, 0x1c, 0x30, 0x1a, 
0x06, 0x03, 0x55, 0x04, 0x0a, 0x0c, 0x13, 0xd0, 
0x9b, 0xd0, 0x98, 0xd0, 0xa1, 0xd0, 0xa1, 0xd0, 
0x98, 0x2d, 0xd0, 0xa1, 0xd0, 0xbe, 0xd1, 0x84, 
0xd1, 0x82, 0x31, 0x1f, 0x30, 0x1d, 0x06, 0x09, 
0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x09, 
0x01, 0x16, 0x10, 0x61, 0x6d, 0x61, 0x73, 0x6c, 
0x6f, 0x76, 0x40, 0x6c, 0x69, 0x73, 0x73, 0x69, 
0x2e, 0x72, 0x75, 0x31, 0x31, 0x30, 0x2f, 0x06, 
0x03, 0x55, 0x04, 0x08, 0x0c, 0x28, 0x35, 0x30, 
0x20, 0x20, 0xd0, 0x9c, 0xd0, 0xbe, 0xd1, 0x81, 
0xd0, 0xba, 0xd0, 0xbe, 0xd0, 0xb2, 0xd1, 0x81, 
0xd0, 0xba, 0xd0, 0xb0, 0xd1, 0x8f, 0x20, 0xd0, 
0xbe, 0xd0, 0xb1, 0xd0, 0xbb, 0xd0, 0xb0, 0xd1, 
0x81, 0xd1, 0x82, 0xd1, 0x8c, 0x20, 
CKA_ID
0x97, 0x46, 0x4e, 0xcc, 0x7c, 0xa9, 0xea, 0xb1, 
0x0a, 0xda, 0xec, 0x10, 0xf4, 0x49, 0x7e, 0x7f, 
0x2d, 0x71, 0x4b, 0xa7, 
CKA_SENSITIVE
0x01, 
. . .
CKA_GOSTR3410_PARAMS
0x06, 0x09, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x02, 
0x01, 0x02, 0x01, 
CKA_GOSTR3411_PARAMS
0x06, 0x08, 0x2a, 0x85, 0x03, 0x07, 0x01, 0x01, 
0x02, 0x03, 
CKA_GOST28147_PARAMS
0x06, 0x07, 0x2a, 0x85, 0x03, 0x02, 0x02, 0x1f, 
0x01, 
…
OK
bash-4.3$

Alles, was hier gesagt wird, gilt für ein Token / eine Smartcard mit PKCS # 11-Schnittstelle, einschließlich eines Cloud-Tokens.

Zusammenfassend erinnern wir daran, dass Token / Smartcards mit der PKCS # 11-Oberfläche in Mozilla-Projekten (Browser, E-Mail-Clients), in Chrome-Browsern von Google und anderen Projekten häufig verwendet werden. Wenn wir über Russland sprechen, werden Token / Smartcards mit PKCS # 11-Schnittstelle erfolgreich für den Zugriff auf das State Services-Portal verwendet.

Source: https://habr.com/ru/post/de400943/

More articles:


All Articles