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.
Die folgenden Probleme betreffen das JCE SDK für. AWS CloudHSM
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.
-
Auswirkung: Dieses Problem kann dazu führen HSMs , dass Ihnen unerwartet der Schlüsselspeicher ausgeht. Es tritt auf, wenn Ihre Anwendung statt eines Objekts ein Standard-JCE-Schlüsselobjekt für Kryptooperationen verwendet.
CaviumKeyWenn Sie ein JCE-Standardschlüsselobjekt verwenden, importiertCaviumProviderdiesen Schlüssel implizit in das HSM, da ein Sitzungsschlüssel diesen Schlüssel erst löscht, 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 Klasse
CaviumSignature,CaviumCipher,CaviumMacoderCaviumKeyAgreementverwenden, sollten Sie den Schlüssel alsCaviumKeyund nicht als JCE-Standardschlüsselobjekt bereitstellen.Sie können mithilfe der
ImportKey-Klasse einen normalen Schlüssel manuell in einen CaviumKeyumwandeln 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
-
Auswirkungen: Derzeit können im JCE KeyStore nur Objekttypen gespeichert werden, die von HSM unterstützt werden. 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 die AES-GCM-Verschlüsselung dürfen nicht größer sein als 16.000 Byte.
Es wird keine mehrteilige AES-GCM-Verschlüsselung unterstützt.
-
Auswirkung: Sie können AES-GCM nicht zum Verschlüsseln von Daten verwenden, die größer als 16.000 Byte sind.
-
Problemumgehung: Sie können einen alternativen Mechanismus verwenden, wie beispielsweise AES-CBC, oder Sie können Ihre Daten unterteilen und jeden Teil einzeln verschlüsseln. Wenn Sie die Daten unterteilen, müssen Sie den unterteilten Verschlüsselungstext und dessen Entschlüsselung verwalten. Da FIPS erfordert, dass der Initialisierungsvektor (IV) für AES-GCM auf dem HSM generiert wird, ist der IV für jedes AES-GCM-encrypted Datenelement unterschiedlich.
-
Stand der Lösung: Wir korrigieren das SDK, sodass es explizit fehlschlägt, wenn der Datenpuffer zur 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: 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. Ein ECDH-Schlüsselableitungsbeispiel ist in den Java-Codebeispielenverfügbar.
-
Auswirkung: Das Client-SDK 3 erweitert das JCE um ECDH-Funktionalität. Wenn Sie die
KeyAgreementKlasse verwenden, um eine abzuleiten SecretKey, ist sie 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 SSL/TLS Offload in implementieren AWS CloudHSM, 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. 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 Attributs der AWS CloudHSM KeyAttribute Enumeration erwartet die API fälschlicherweise, dass das Argument die Anzahl der Schlüsselbytes ist, obwohl es stattdessen die Anzahl der Schlüsselbits sein sollte.
-
Auswirkung: Die Client-SDK-Versionen 5.4.0 bis 5.4.2 erwarten fälschlicherweise, dass die Schlüsselgröße in Byte angegeben APIs wird.
-
Umgehung: Wenn Sie die Client-SDK-Versionen 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 Client-SDK-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 die Enumeration zum Generieren von Schlüsseln verwenden. KeyAttribute
Problem: Das Client-SDK 5 gibt die Warnung „Es ist ein illegaler Reflective Access-Vorgang aufgetreten“ aus
Bei Verwendung von Client-SDK 5 mit Java 11 gibt CloudHSM 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 in JCE ausführen, wenn 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
Lösungsstatus: Wir haben dieses Problem in Client SDK 5.9.0 und höher behoben. Um dieses Problem zu beheben, aktualisieren Sie Ihr Client-SDK auf eine dieser Versionen.
Problem: Speicherverlust im Client-SDK 5 bei GetKey-Vorgängen
-
Auswirkung: Bei der
getKeyAPI-Operation ist in JCE in den Client-SDK-Versionen 5.10.0 und früher ein Speicherverlust aufgetreten. Wenn Sie diegetKeyAPI in Ihrer Anwendung mehrfach 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 erfordern. -
Problemumgehung: Wir empfehlen ein Upgrade auf Client SDK 5.11.0. Wenn dies nicht möglich ist, empfehlen wir, die
getKeyAPI in Ihrer Anwendung nicht mehrmals aufzurufen. Verwenden Sie stattdessen den zuvor zurückgegebenen Schlüssel aus der vorherigengetKeyOperation so oft wie möglich wieder. -
Lösungsstatus: Aktualisieren Sie Ihre Client-SDK-Version auf 5.11.0 oder höher, was eine Lösung für dieses Problem beinhaltet.
