Bekannte Probleme in der PKCS #11 -Bibliothek für AWS CloudHSM - AWS CloudHSM
Problem: AES Der Schlüsselumbruch in Version 3.0.0 der PKCS #11 -Bibliothek wird IVs vor der Verwendung nicht validiert Problem: PKCS #11 SDK 2.0.4 und frühere Versionen verwendeten immer die Standard-IV von 0xA6A6A6A6A6A6A6A6 für den Zeilenumbruch und das Entpacken von AES SchlüsselnProblem: 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: Die Puffer für die C_Decrypt API Operationen C_Encrypt und dürfen 16 KB nicht überschreiten, wenn der Mechanismus verwendet wird CKM_AES_GCMProblem: Die Diffie-Hellman (ECDH) -Schlüsselableitung mit elliptischen Kurven wird teilweise innerhalb von ausgeführt HSM Problem: Die Überprüfung von secp256k1-Signaturen schlägt auf EL6 Plattformen wie Cent und 6 fehl OS6 RHELProblem: Eine falsche Reihenfolge von Funktionsaufrufen führt zu undefinierten Ergebnissen, anstatt dass sie fehlschlagenProblem: Die schreibgeschützte Sitzung wird in SDK Version 5 nicht unterstütztProblem: Die cryptoki.h-Header-Datei ist nur für Windows verfügbar

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 in der PKCS #11 -Bibliothek für AWS CloudHSM

Die folgenden Probleme betreffen die PKCS #11 -Bibliothek für AWS CloudHSM.

Problem: AES Der Schlüsselumbruch in Version 3.0.0 der PKCS #11 -Bibliothek wird IVs vor der Verwendung nicht validiert

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.

Problem: PKCS #11 SDK 2.0.4 und frühere Versionen verwendeten immer die Standard-IV von 0xA6A6A6A6A6A6A6A6 für den Zeilenumbruch und das Entpacken von AES Schlüsseln

Vom Benutzer bereitgestellte Daten 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 eine vom Benutzer bereitgestellte IV verwendet haben, werden Ihre Schlüssel mit der Standard-IV von umschlossen. 0xA6A6A6A6A6A6A6A6

    • Wenn Sie PKCS #11 SDK 3.0.0 oder höher und eine vom Benutzer bereitgestellte IV verwendet haben, sind Ihre Schlüssel mit der vom Benutzer bereitgestellten IV verpackt.

  • Problemumgehungen:

    • Um Schlüssel zu entpacken, die mit PKCS #11 SDK 2.0.4 oder früher umschlossen wurden, verwenden Sie die Standardeinstellung IV von. 0xA6A6A6A6A6A6A6A6

    • Verwenden Sie das vom Benutzer bereitgestellte IV, um Schlüssel zu entpacken, die mit PKCS #11 SDK 3.0.0 oder höher umschlossen wurden.

  • Lösungsstatus: Wir empfehlen dringend, dass Sie Ihren Wrapping- und Unpacking-Code so ändern, dass eine NULL IV übergeben wird, oder dass Sie die Standard-IV von angeben. 0xA6A6A6A6A6A6A6A6

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 auf FALSE festgelegt ist. Wenn CKA_DERIVE auf TRUE eingestellt ist, wird es erst dann unterstützt, wenn wir die Schlüsselableitungsfunktion AWS CloudHSM hinzufügen. Sie müssen Ihren Client und SDK (s) auf Version 1.1.1 oder höher aktualisieren, um von der Lösung zu profitieren.

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 SDK (s) auf Version 1.1.1 oder höher aktualisieren, um von dem Update zu profitieren.

Problem: Mehrteiliges Hashing und Signatur werden nicht unterstützt.

  • Auswirkung: C_DigestUpdate und C_DigestFinal werden nicht implementiert. C_SignFinal ist ebenfalls nicht implementiert und schlägt mit CKR_ARGUMENTS_BAD für einen Nicht-NULL-Puffer fehl.

  • Umgehung: Hashen Sie Ihre Daten innerhalb Ihrer Anwendung und verwenden Sie sie AWS CloudHSM nur zum Signieren des Hashs.

  • Status der Lösung: Wir sind dabei, den Client zu reparieren und das mehrteilige Hashing korrekt SDKs zu implementieren. 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 sollte CKA_TEMPLATE_INCONSISTENT zurückgeben, wenn die private Vorlage CKA_MODULUS_BITS oder CKA_PUBLIC_EXPONENT enthält. Stattdessen generiert es einen privaten Schlüssel, für den alle Nutzungsfelder auf FALSE 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 mit dem Versionsverlauf bekannt gegeben.

Problem: Die Puffer für die C_Decrypt API Operationen C_Encrypt und dürfen 16 KB nicht überschreiten, wenn der Mechanismus verwendet wird CKM_AES_GCM

AWS CloudHSM unterstützt keine mehrteilige VerschlüsselungAES. GCM

  • 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 wieCKM_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 AES mehrteilige GCM Verschlüsselung durch. Beachten Sie, FIPS dass der Initialisierungsvektor (IV) auf dem generiert AES-GCM werden muss. HSM Daher wird die IV für jeden Teil Ihrer AES GCM verschlüsselten Daten unterschiedlich sein.

  • Auflösungsstatus: Wir korrigieren das Problem soSDK, dass es explizit fehlschlägt, wenn der Datenpuffer zu groß ist. Wir kehren CKR_MECHANISM_INVALID für die C_DecryptUpdate API Operationen C_EncryptUpdate und 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 angekündigt.

Problem: Die Diffie-Hellman (ECDH) -Schlüsselableitung mit elliptischen Kurven wird teilweise innerhalb von ausgeführt HSM

Ihr privater EC-Schlüssel verbleibt HSM zu jeder Zeit innerhalb von, aber die Schlüsselableitung erfolgt in mehreren Schritten. Dies hat zur Folge, dass auf dem Client Zwischenergebnisse eines jeden Schritts verfügbar sind.

  • Auswirkung: In Client SDK 3 ist der mit dem CKM_ECDH1_DERIVE Mechanismus abgeleitete Schlüssel zuerst auf dem Client verfügbar und wird dann in den HSM importiert. Ein Schlüssel-Handle wird dann an Ihre Anwendung zurückgegeben.

  • Umgehung: Wenn SieSSL/TLSOffload in implementieren AWS CloudHSM, stellt diese Einschränkung möglicherweise kein Problem dar. Wenn Ihre Anwendung erfordert, dass Ihr Schlüssel jederzeit innerhalb einer bestimmten FIPS Grenze bleibt, sollten Sie die Verwendung eines alternativen Protokolls in Betracht ziehen, das nicht auf der ECDH Schlüsselableitung basiert.

  • Status der Lösung: Wir entwickeln derzeit die Option, die ECDH Schlüsselableitung vollständig innerhalb von durchzuführen. HSM 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 Cent und 6 fehl OS6 RHEL

Dies liegt daran, dass die Cloud HSM PKCS #11 -Bibliothek einen Netzwerkaufruf während der Initialisierung des Überprüfungsvorgangs vermeidet, indem sie Open SSL zur Überprüfung der EC-Kurvendaten verwendet. Da Secp256k1 vom SSL Standard-Open-Paket auf EL6 Plattformen nicht unterstützt wird, schlägt die Initialisierung fehl.

  • Auswirkung: Die Überprüfung der Secp256k1-Signatur schlägt auf Plattformen fehl. EL6 Der Überprüfungsaufruf schlägt fehl und es wird eine CKR_HOST_MEMORY-Fehlermeldung angezeigt.

  • Umgehung: Wir empfehlen, entweder Amazon Linux 1 oder eine andere EL7 Plattform zu verwenden, wenn Ihre PKCS #11 -Anwendung secp256k1-Signaturen verifizieren muss. Alternativ können Sie auf eine Version des SSL Open-Pakets aktualisieren, die die secp256k1-Kurve unterstützt.

  • Status der Lösung: Wir implementieren Korrekturen, um auf die Methode zurückgreifen zu können, HSM falls die lokale Kurvenvalidierung nicht verfügbar ist. Die aktualisierte PKCS #11 -Bibliothek wird auf der Seite mit dem Versionsverlauf bekannt gegeben.

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 von C_Encrypt

    • C_DecryptInit/C_DecryptUpdate gefolgt von C_Decrypt

    • C_SignInit/C_SignUpdate gefolgt von C_Sign

    • C_VerifyInit/C_VerifyUpdate gefolgt von C_Verify

    • C_FindObjectsInit gefolgt von C_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 Cloud HSM PKCS #11 -Bibliothek unter diesen Umständen einen Fehler zurückgibt.

Problem: Die schreibgeschützte Sitzung wird in SDK Version 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 von CKF_RW_SESSION zu tätigen, schlägt der Aufruf mit der folgenden Fehlermeldung CKR_FUNCTION_FAILED fehl.

  • Problemumgehung: Wenn Sie eine Sitzung öffnen, müssen Sie die CKF_SERIAL_SESSION | CKF_RW_SESSION-Flags an den C_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 /opt/cloudhsm/include/pkcs11/cryptoki.h ist die Header-Datei nur mit Windows-Betriebssystemen kompatibel.

  • 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.