Bekannte Probleme für JCE SDK - AWS CloudHSM
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ütztProblem: 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 HSMProblem: KeyGenerator und interpretiert den Schlüsselgrößenparameter KeyAttribute fälschlicherweise als Anzahl von Bytes statt als BitsProblem: Client SDK 5 gibt die Warnung „Ein illegaler Reflective Access-Vorgang ist aufgetreten“ ausProblem: Der JCE Sitzungspool ist erschöpftProblem: Speicherverlust bei Client SDK 5 bei getKey Vorgängen

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

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üssel CaviumProvider 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 die CaviumKeyAgreement Klasse verwenden, sollten Sie den Schlüssel CaviumKey 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 Klasse oder des SIZE 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üsselungsmodus

    wrap() im Wrap-Modus

    unwrap() im Unwrap-Modus
    KeyAgreement

    generateSecret() oder generateSecret(String)
    KeyPairGenerator

    generateKeyPair() , genKeyPair() oder reset()
    KeyStore Keine Methode erforderlich
    MAC

    doFinal() oder reset()
    MessageDigest

    digest() oder reset()
    SecretKeyFactory Keine Methode erforderlich
    SecureRandom Keine Methode erforderlich
    Signatur

    sign() im Signiermodus

    verify() 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 den getKey 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 vorherigen getKey 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.