Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Bekannte Probleme für den PKCS#11-Bibliothek
Themen
- Problem: Der AES-Schlüsselumbruch in Version 3.0.0 der PKCS #11-Bibliothek validiert IVs nicht vor der Verwendung
- Problem: PKCS #11 SDK 2.0.4 und frühere Versionen verwenden immer den Standard-IV von 0xA6A6A6A6A6A6A6A6 für AES-Schlüsselumbruch und -entpacken.
- Problem: Das Attribut CKA_DERIVE wurde nicht unterstützt und nicht verarbeitet.
- Problem: Das Attribut CKA_SENSITIVE wurde nicht unterstützt und nicht verarbeitet.
- Problem: Mehrteiliges Hashing und Signatur werden nicht unterstützt.
- Problem: C_GenerateKeyPair verarbeitet CKA_MODULUS_BITS oder CKA_PUBLIC_EXPONENT in der privaten Vorlage nicht konform zu den Standards.
- Problem: Puffer für die API-Operationen C_Encrypt und C_Decrypt dürfen bei Verwendung des CKM_AES_GCM-Mechanismus 16 KB nicht überschreiten.
- Problem: Elliptic-Curve Diffie-Hellman- (ECDH) Schlüsselableitung wird teilweise innerhalb des HSM ausgeführt.
- Problem: Die Überprüfung von secp256k1-Signaturen schlägt auf EL6-Plattformen wie CentOS6 und RHEL 6 fehl
- Problem: Eine falsche Reihenfolge von Funktionsaufrufen führt zu undefinierten Ergebnissen, anstatt dass sie fehlschlagen
- Problem: Die schreibgeschützte Sitzung wird in SDK 5 nicht unterstützt
- Problem: Die cryptoki.h-Header-Datei ist nur für Windows verfügbar
Problem: Der AES-Schlüsselumbruch in Version 3.0.0 der PKCS #11-Bibliothek validiert IVs nicht vor der Verwendung
Wenn Sie einen IV angeben, der kürzer als 8 Byte ist, wird er vor der Verwendung mit unvorhersehbaren Bytes aufgefüllt.
Anmerkung
Dies wirkt sich nur C_WrapKey
mit CKM_AES_KEY_WRAP
-Mechanismus aus.
Auswirkung: Wenn Sie in der Version 3.0.0 der PKCS #11-Bibliothek eine IV angeben, die kürzer als 8 Byte ist, können Sie den Schlüssel möglicherweise nicht entpacken.
Problemumgehungen:
Wir empfehlen Ihnen dringend, auf die Version 3.0.1 oder höher der PKCS #11-Bibliothek zu aktualisieren, die die IV-Länge während des AES-Schlüsselumbruchs korrekt durchsetzt. Ändern Sie Ihren Umbruchcode, um einen NULL-IV zu übergeben, oder geben Sie den Standard-IV von
0xA6A6A6A6A6A6A6A6
an. Weitere Informationen finden Sie im Benutzerdefinierte IVs mit nicht-konformer Länge für AES Key Wrap.Wenn Sie mit der Version 3.0.0 der PKCS #11-Bibliothek Schlüssel mit einer IV von weniger als 8 Byte umgewandelt haben, wenden Sie sich bitte an uns, um Unterstützung
zu erhalten.
Auflösungsstatus: Dieses Problem wurde in Version 3.0.1 der PKCS #11-Bibliothek behoben. Um Schlüssel mit AES-Schlüsselumbruch zu umschließen, geben Sie einen IV an, der NULL oder 8 Byte lang ist.
Problem: PKCS #11 SDK 2.0.4 und frühere Versionen verwenden immer den Standard-IV von 0xA6A6A6A6A6A6A6A6
für AES-Schlüsselumbruch und -entpacken.
Vom Benutzer bereitgestellte IVs wurden stillschweigend ignoriert.
Anmerkung
Dies wirkt sich nur C_WrapKey
mit CKM_AES_KEY_WRAP
-Mechanismus aus.
Auswirkung:
Wenn Sie PKCS #11 SDK 2.0.4 oder eine frühere Version und ein vom Benutzer bereitgestelltes IV verwendet haben, werden Ihre Schlüssel mit dem Standard-IV von
0xA6A6A6A6A6A6A6A6
umgebrochen.Wenn Sie PKCS #11 SDK 3.0.0 oder höher und einen vom Benutzer bereitgestellten IV verwendet haben, werden Ihre Schlüssel mit dem vom Benutzer bereitgestellten IV umschlossen.
Problemumgehungen:
Um Schlüssel zu entpacken, die mit PKCS #11 SDK 2.0.4 oder früher umschlossen sind, verwenden Sie den Standard-IV von
0xA6A6A6A6A6A6A6A6
.Um Schlüssel zu entpacken, die mit PKCS #11 SDK 3.0.0 oder höher umschlossen sind, verwenden Sie den vom Benutzer bereitgestellten IV.
Auflösungsstatus: Wir empfehlen dringend, dass Sie Ihren Umbruch- und Entpackungscode so ändern, dass ein NULL-IV übergeben wird, oder geben Sie den Standard-IV von
0xA6A6A6A6A6A6A6A6
an.
Problem: Das Attribut CKA_DERIVE
wurde nicht unterstützt und nicht verarbeitet.
-
Stand der Lösung: Wir haben Fehlerbehebungen implementiert, um
CKA_DERIVE
zu akzeptieren, wenn es aufFALSE
festgelegt ist. WennCKA_DERIVE
aufTRUE
eingestellt ist, wird es erst dann unterstützt, wenn wir die Schlüsselableitungsfunktion AWS CloudHSM hinzufügen. Sie müssen Ihren Client und Ihr(e) SDK(s) auf Version 1.1.1 oder höher aktualisieren, um dieses Problem zu beheben.
Problem: Das Attribut CKA_SENSITIVE
wurde nicht unterstützt und nicht verarbeitet.
-
Stand der Lösung: Wir haben Korrekturen implementiert, mit denen das Attribut
CKA_SENSITIVE
akzeptiert und berücksichtigt wird. Sie müssen Ihren Client und Ihr(e) SDK(s) auf Version 1.1.1 oder höher aktualisieren, um dieses Problem zu beheben.
Problem: Mehrteiliges Hashing und Signatur werden nicht unterstützt.
-
Auswirkung:
C_DigestUpdate
undC_DigestFinal
werden nicht implementiert.C_SignFinal
ist ebenfalls nicht implementiert und schlägt mitCKR_ARGUMENTS_BAD
für einen Nicht-NULL
-Puffer fehl. -
Problemumgehung: Hashen Sie Ihre Daten innerhalb Ihrer Anwendung und verwenden Sie sie AWS CloudHSM nur zum Signieren des Hashs.
-
Stand der Lösung: Wir korrigieren den Client und die SDKs, sodass mehrteiliges Hashings korrekt implementiert wird. Aktualisierungen werden im AWS CloudHSM -Forum und auf der Seite des Versionsverlaufs bekanntgegeben.
Problem: C_GenerateKeyPair
verarbeitet CKA_MODULUS_BITS
oder CKA_PUBLIC_EXPONENT
in der privaten Vorlage nicht konform zu den Standards.
-
Auswirkung:
C_GenerateKeyPair
sollteCKA_TEMPLATE_INCONSISTENT
zurückgeben, wenn die private VorlageCKA_MODULUS_BITS
oderCKA_PUBLIC_EXPONENT
enthält. Stattdessen generiert es einen privaten Schlüssel, für den alle Nutzungsfelder aufFALSE
gesetzt sind. Der Schlüssel kann nicht verwendet werden. -
Problemumgehung: Wir empfehlen, dass Ihre Anwendung die Nutzungsfeldwerte zusätzlich zum Fehlercode auswertet.
-
Stand der Lösung: Wir implementieren Korrekturen, um die richtige Fehlermeldung zurückzugeben, wenn eine fehlerhafte private Schlüsselvorlage verwendet wird. Die aktualisierte PKCS#11-Bibliothek wird auf der Seite des Versionsverlaufs bekanntgegeben.
Problem: Puffer für die API-Operationen C_Encrypt
und C_Decrypt
dürfen bei Verwendung des CKM_AES_GCM
-Mechanismus 16 KB nicht überschreiten.
AWS CloudHSM unterstützt keine mehrteilige AES-GCM-Verschlüsselung.
-
Auswirkung: Sie können den
CKM_AES_GCM
-Mechanismus nicht zum Verschlüsseln von Daten verwenden, die größer als 16 KB sind. -
Problemumgehung: Sie können einen alternativen Mechanismus wie
CKM_AES_CBC
,CKM_AES_CBC_PAD
, verwenden oder Sie können Ihre Daten in Teile aufteilen und jedes Teil einzeln verschlüsseln.AES_GCM
Wenn Sie verwendenAES_GCM
, müssen Sie die Aufteilung Ihrer Daten und die anschließende Verschlüsselung verwalten. AWS CloudHSM führt für Sie keine mehrteilige AES-GCM-Verschlüsselung durch. Beachten Sie, dass FIPS erfordert, dass der Initialisierungsvektor (IV) auf dem HSM generiert wird.AES-GCM
Deshalb unterscheidet sich der IV für jeden Teil Ihrer mit AES-GCM verschlüsselten Daten. -
Stand der Lösung: Wir korrigieren das SDK, sodass es explizit fehlschlägt, wenn der Datenpuffer zur groß ist. Wir geben für die
C_EncryptUpdate
- undC_DecryptUpdate
-API-OperationenCKR_MECHANISM_INVALID
zurück. Wir werten Alternativen zur Unterstützung größerer Puffer aus, ohne dabei eine mehrteilige Verschlüsselung verwenden zu müssen. Updates werden im AWS CloudHSM Forum und auf der Seite mit dem Versionsverlauf bekannt gegeben.
Problem: Elliptic-Curve Diffie-Hellman- (ECDH) Schlüsselableitung wird teilweise innerhalb des HSM ausgeführt.
Der private EC-Schlüssel verbleibt zu jeder Zeit innerhalb des HSM, der Prozess zur Schlüsselableitung wird aber in mehreren Schritten durchgeführt. Dies hat zur Folge, dass auf dem Client Zwischenergebnisse eines jeden Schritts verfügbar sind.
-
Auswirkung: In Client SDK 3 ist der mithilfe des
CKM_ECDH1_DERIVE
Mechanismus abgeleitete Schlüssel zunächst auf dem Client verfügbar und wird dann in das HSM importiert. Ein Schlüssel-Handle wird dann an Ihre Anwendung zurückgegeben. -
Problemumgehung: Wenn Sie die SSL/TLS-Auslagerung in AWS CloudHSM implementieren, stellt diese Einschränkung möglicherweise kein Problem dar. Wenn Ihre Anwendung vorschreibt, dass Ihr Schlüssel zu jeder Zeit innerhalb einer FIPS-Begrenzung verbleibt, sollten Sie mit einem alternativen Protokoll ohne erforderliche ECDH-Schlüsselableitung arbeiten.
-
Stand der Lösung: Wir arbeiten derzeit an der Möglichkeit, die ECDH-Schlüsselableitung vollständig innerhalb des HSM auszuführen. Die aktualisierte Implementierung wird auf der Seite des Versionsverlaufs bekanntgegeben, sobald sie verfügbar ist.
Problem: Die Überprüfung von secp256k1-Signaturen schlägt auf EL6-Plattformen wie CentOS6 und RHEL 6 fehl
Der Grund hierfür ist, dass die PKCS #11-Bibliothek von CloudHSM während der Initialisierung des Überprüfungsvorgangs einen Netzwerkaufruf vermeidet, indem sie OpenSSL zur Überprüfung von EC-Kurvendaten verwendet. Da secp256k1 durch das Standard-OpenSSL-Paket auf EL6-Plattformen nicht unterstützt wird, schlägt die Initialisierung fehl.
-
Auswirkung: Die secp256k1-Signaturüberprüfung schlägt auf EL6-Plattformen fehl. Der Überprüfungsaufruf schlägt fehl und es wird eine
CKR_HOST_MEMORY
-Fehlermeldung angezeigt. -
Problemumgehung: Wir empfehlen die Verwendung von Amazon Linux 1 oder einer beliebigen EL7-Plattform, wenn Ihre PKCS #11-Anwendung secp256k1-Signaturen überprüfen soll. Alternativ können Sie ein Upgrade auf eine Version des OpenSSL-Pakets durchführen, das die secp256k1-Kurve unterstützt.
-
Stand der Lösung: Wir implementieren zurzeit Korrekturen, die es ermöglichen, auf das HSM zurückzugreifen, wenn die lokale Kurvenvalidierung nicht verfügbar ist. Die aktualisierte PKCS #11-Bibliothek wird auf der Seite des Versionsverlaufs bekanntgegeben.
Problem: Eine falsche Reihenfolge von Funktionsaufrufen führt zu undefinierten Ergebnissen, anstatt dass sie fehlschlagen
-
Auswirkung: Wenn Sie eine falsche Reihenfolge von Funktionen aufrufen, ist das Endergebnis falsch, obwohl die einzelnen Funktionsaufrufen erfolgreich sind. Beispielsweise stimmen entschlüsselte Daten möglicherweise nicht mit dem ursprünglichen Klartext überein oder Signaturen lassen sich möglicherweise nicht verifizieren. Dieses Problem betrifft sowohl einteilige als auch mehrteilige Operationen.
Beispiele für falsche Funktionssequenzen:
C_EncryptInit
/C_EncryptUpdate
gefolgt vonC_Encrypt
C_DecryptInit
/C_DecryptUpdate
gefolgt vonC_Decrypt
C_SignInit
/C_SignUpdate
gefolgt vonC_Sign
C_VerifyInit
/C_VerifyUpdate
gefolgt vonC_Verify
C_FindObjectsInit
gefolgt vonC_FindObjectsInit
Umgehung: Ihre Anwendung sollte gemäß der PKCS #11 -Spezifikation die richtige Reihenfolge von Funktionsaufrufen sowohl für einteilige als auch für mehrteilige Operationen verwenden. Ihre Anwendung sollte sich nicht darauf verlassen, dass die CloudHSM PKCS #11-Bibliothek unter diesen Umständen einen Fehler zurückgibt.
Problem: Die schreibgeschützte Sitzung wird in SDK 5 nicht unterstützt
-
Problem: SDK 5 unterstützt nicht das Öffnen von Nur-Lesesitzungen mit
C_OpenSession
. -
Auswirkung: Wenn Sie versuchen, einen Aufruf an
C_OpenSession
ohne Angabe vonCKF_RW_SESSION
zu tätigen, schlägt der Aufruf mit der folgenden FehlermeldungCKR_FUNCTION_FAILED
fehl. -
Problemumgehung: Wenn Sie eine Sitzung öffnen, müssen Sie die
CKF_SERIAL_SESSION | CKF_RW_SESSION
-Flags an denC_OpenSession
-Funktionsaufruf übergeben.
Problem: Die cryptoki.h
-Header-Datei ist nur für Windows verfügbar
-
Problem: Bei den AWS CloudHSM Client-SDK 5-Versionen 5.0.0 bis 5.4.0 unter Linux ist die Header-Datei nur mit Windows-Betriebssystemen kompatibel.
/opt/cloudhsm/include/pkcs11/cryptoki.h
-
Auswirkung: Unter Linux-basierten Betriebssystemen können Probleme auftreten, wenn Sie versuchen, diese Header-Datei in Ihre Anwendung aufzunehmen.
-
Lösungsstatus: Führen Sie ein Upgrade auf AWS CloudHSM Client SDK 5 Version 5.4.1 oder höher durch, die eine Linux-kompatible Version dieser Header-Datei enthält.