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 JCE SDK
Themen
- Problem: Bei der Arbeit mit asymmetrischen Schlüsselpaaren wird die belegte Schlüsselkapazität auch dann angezeigt, wenn Sie Schlüssel nicht explizit erstellen oder importieren.
- Problem: Das JCE KeyStore ist schreibgeschützt
- Problem: Puffer für AES — GCM Verschlüsselung dürfen 16.000 Byte nicht überschreiten
- Problem: Die Diffie-Hellman (ECDH) -Schlüsselableitung mit elliptischen Kurven wird teilweise innerhalb von ausgeführt HSM
- Problem: KeyGenerator und interpretiert den Schlüsselgrößenparameter KeyAttribute fälschlicherweise als Anzahl von Bytes statt als Bits
- Problem: Client SDK 5 gibt die Warnung „Ein illegaler Reflective Access-Vorgang ist aufgetreten“ aus
- Problem: Der JCE Sitzungspool ist erschöpft
- Problem: Speicherverlust bei Client SDK 5 bei getKey Vorgängen
Problem: Bei der Arbeit mit asymmetrischen Schlüsselpaaren wird die belegte Schlüsselkapazität auch dann angezeigt, wenn Sie Schlüssel nicht explizit erstellen oder importieren.
-
Auswirkung: Dieses Problem kann dazu führenHSMs, dass Ihnen unerwartet der Schlüsselspeicher ausgeht. Es tritt auf, wenn Ihre Anwendung statt eines Objekts ein JCE
CaviumKey
Standardschlüsselobjekt für Kryptooperationen verwendet. Wenn Sie ein JCE Standardschlüsselobjekt verwenden, importiert es diesen SchlüsselCaviumProvider
implizit HSM als Sitzungsschlüssel in das und löscht diesen Schlüssel erst, wenn die Anwendung beendet wird. Infolgedessen sammeln sich Schlüssel an, während die Anwendung ausgeführt wird, und dies kann dazu führen, dass Ihnen HSMs der freie Schlüsselspeicher ausgeht, sodass Ihre Anwendung einfriert. -
Problemumgehung: Wenn Sie die
CaviumSignature
CaviumCipher
Klasse,CaviumMac
Klasse, Klasse oder dieCaviumKeyAgreement
Klasse verwenden, sollten Sie den SchlüsselCaviumKey
statt als JCE Standardschlüsselobjekt angeben.Sie können mithilfe der
ImportKey
-Klasse einen normalen Schlüssel manuell in einen CaviumKey
umwandeln und den Schlüssel dann nach Abschluss des Vorgangs manuell löschen. -
Stand der Lösung: Wir aktualisieren den
CaviumProvider
, um implizite Importe ordnungsgemäß zu verwalten. Diese Fehlerbehebung wird auf der Seite des Versionsverlaufs bekanntgegeben, sobald sie verfügbar ist.
Problem: Das JCE KeyStore ist schreibgeschützt
-
Auswirkung: Sie können heute keinen Objekttyp im Keystore speichern, der HSM nicht vom JCE Keystore unterstützt wird. Insbesondere ist es nicht möglich, Zertifikate im Schlüsselspeicher zu speichern. Dadurch wird die Interoperabilität mit Tools wie jarsigner, die im Schlüsselspeicher ein Zertifikat erwarten, verhindert.
-
Problemumgehung: Sie können Änderungen am Code vornehmen, sodass Zertifikate anstatt aus dem Schlüsselspeicher aus lokalen Dateien oder aus einem S3-Bucket-Speicherort geladen werden.
-
Stand der Lösung: Wir arbeiten daran, Unterstützung für die Zertifikatspeicherung im Schlüsselspeicher hinzuzufügen. Diese Funktion wird auf der Seite des Versionsverlaufs bekanntgegeben, sobald sie verfügbar ist.
Problem: Puffer für AES — GCM Verschlüsselung dürfen 16.000 Byte nicht überschreiten
Mehrteilige GCM Verschlüsselung AES wird nicht unterstützt.
-
Auswirkung: Sie können AES - nicht verwenden, um Daten GCM zu verschlüsseln, die größer als 16.000 Byte sind.
-
Umgehung: Sie können einen alternativen Mechanismus verwenden, z. B. AES -CBC, oder Sie können Ihre Daten in Teile aufteilen und jeden Teil einzeln verschlüsseln. Wenn Sie die Daten unterteilen, müssen Sie den unterteilten Verschlüsselungstext und dessen Entschlüsselung verwalten. Weil es FIPS erfordert, dass der Initialisierungsvektor (IV) für AES - auf dem generiert GCM wirdHSM, wird der IV für jedes AES GCM - verschlüsselte Datenelement unterschiedlich sein.
-
Auflösungsstatus: Wir korrigieren das Problem soSDK, dass es explizit fehlschlägt, wenn der Datenpuffer zu groß ist. Wir werten Alternativen zur Unterstützung größerer Puffer aus, ohne eine mehrteilige Verschlüsselung verwenden zu müssen. Aktualisierungen werden im AWS CloudHSM -Forum und auf der Seite des Versionsverlaufs bekanntgegeben.
Problem: Die Diffie-Hellman (ECDH) -Schlüsselableitung mit elliptischen Kurven wird teilweise innerhalb von ausgeführt HSM
Ihr privater EC-Schlüssel bleibt zu jeder HSM 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. Ein Beispiel für die ECDH Schlüsselableitung ist in den Java-Codebeispielen verfügbar.
-
Auswirkung: Client SDK 3 erweitert den JCE um ECDH Funktionen. Wenn Sie die
KeyAgreement
Klasse verwenden, um eine abzuleiten SecretKey, ist sie zunächst auf dem Client verfügbar und wird dann in die 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 Wenn verfügbar, werden wir die aktualisierte Implementierung auf der Seite des Versionsverlaufs bekanntgeben.
Problem: KeyGenerator und interpretiert den Schlüsselgrößenparameter KeyAttribute fälschlicherweise als Anzahl von Bytes statt als Bits
Beim Generieren eines Schlüssels mithilfe der init
Funktion der KeyGenerator KlasseSIZE
AWS CloudHSM KeyAttribute Enum-Attributs erwartet der API fälschlicherweise, dass das Argument die Anzahl der Schlüsselbytes ist, obwohl es stattdessen die Anzahl der Schlüsselbits sein sollte.
-
Auswirkung: Die SDK Clientversionen 5.4.0 bis 5.4.2 erwarten fälschlicherweise, dass die Schlüsselgröße in Byte angegeben APIs wird.
-
Umgehung: Wenn Sie die SDK Clientversionen 5.4.0 bis 5.4.2 verwenden, konvertieren Sie die Schlüsselgröße von Bits in Byte, bevor Sie die KeyGenerator Klasse oder die KeyAttribute Enumeration verwenden, um Schlüssel mithilfe des AWS CloudHSM JCE Anbieters zu generieren.
-
Lösungsstatus: Führen Sie ein Upgrade Ihrer SDK Client-Version auf Version 5.5.0 oder höher durch. Dies beinhaltet einen Fix, mit dem Schlüsselgrößen in Bits korrekt erwartet werden, wenn Sie die KeyGenerator Klasse oder KeyAttribute die Enumeration zum Generieren von Schlüsseln verwenden.
Problem: Client SDK 5 gibt die Warnung „Ein illegaler Reflective Access-Vorgang ist aufgetreten“ aus
Wenn Sie Client SDK 5 mit Java 11 verwenden, gibt Cloud HSM die folgende Java-Warnung aus:
``` WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore (file:/opt/cloudhsm/java/cloudhsm-jce-5.6.0.jar) to field java.security .KeyStore.keyStoreSpi WARNING: Please consider reporting this to the maintainers of com.amazonaws.cloudhsm.jce.provider.CloudHsmKeyStore WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release ```
Diese Warnungen haben keine Auswirkungen. Wir sind uns dieses Problems bewusst und arbeiten daran, es zu lösen. Es ist weder eine Lösung noch eine Problemumgehung erforderlich.
Problem: Der JCE Sitzungspool ist erschöpft
Auswirkung: Sie können möglicherweise keine Operationen ausführen, wenn JCE die folgende Meldung angezeigt wird:
com.amazonaws.cloudhsm.jce.jni.exception.InternalException: There are too many operations happening at the same time: Reached max number of sessions in session pool: 1000
Problemumgehungen:
Starten Sie Ihre JCE Anwendung neu, falls Probleme auftreten.
Wenn Sie einen Vorgang ausführen, müssen Sie den JCE Vorgang möglicherweise abschließen, bevor Sie den Bezug zu dem Vorgang verlieren.
Anmerkung
Je nach Vorgang ist möglicherweise eine Abschlussmethode erforderlich.
Operation Vervollständigungsmethode Verschlüsselungsverfahren doFinal()
im Verschlüsselungs- oder Entschlüsselungsmoduswrap()
im Wrap-Modusunwrap()
im Unwrap-ModusKeyAgreement generateSecret()
odergenerateSecret(String)
KeyPairGenerator generateKeyPair()
,genKeyPair()
oderreset()
KeyStore Keine Methode erforderlich MAC doFinal()
oderreset()
MessageDigest digest()
oderreset()
SecretKeyFactory Keine Methode erforderlich SecureRandom Keine Methode erforderlich Signatur sign()
im Signiermodusverify()
im Überprüfungsmodus
Status der Lösung: Wir haben dieses Problem in Client SDK 5.9.0 und höher behoben. Um dieses Problem zu beheben, aktualisieren Sie Ihren Client SDK auf eine dieser Versionen.
Problem: Speicherverlust bei Client SDK 5 bei getKey Vorgängen
-
Auswirkung: Bei dem API
getKey
Vorgang ist JCE in den SDK Client-Versionen 5.10.0 und früher ein Speicherverlust aufgetreten. Wenn Sie dengetKey
API mehrfach in Ihrer Anwendung verwenden, führt dies zu einem erhöhten Speicherwachstum und damit zu einer Erhöhung des Speicherbedarfs in Ihrer Anwendung. Im Laufe der Zeit kann dies zu Drosselungsfehlern führen oder einen Neustart der Anwendung erforderlich machen. -
Problemumgehung: Wir empfehlen ein Upgrade auf Client 5.11.0. SDK Wenn dies nicht möglich ist, empfehlen wir, den in Ihrer Anwendung nicht
getKey
API mehrmals aufzurufen. Verwenden Sie stattdessen den zuvor zurückgegebenen Schlüssel aus der vorherigengetKey
Operation so oft wie möglich wieder. -
Status der Lösung: Führen Sie ein Upgrade Ihrer SDK Client-Version auf 5.11.0 oder höher durch, was eine Lösung für dieses Problem beinhaltet.