Problèmes connus relatifs au JCE SDK pour AWS CloudHSM - AWS CloudHSM
Problème : lorsque vous utilisez des paires de clés asymétriques, vous voyez la capacité de clé occupée même lorsque vous ne créez pas ou n'importez pas explicitement des clésProblème : Le JCE KeyStore est en lecture seuleProblème : les tampons pour le AES GCM chiffrement ne peuvent pas dépasser 16 000 octets Problème : La dérivation de la clé Diffie-Hellman (ECDH) à courbe elliptique est partiellement exécutée dans HSMProblème : KeyGenerator et interprète KeyAttribute incorrectement le paramètre de taille de clé en nombre d'octets au lieu de bitsProblème : le client SDK 5 lance l'avertissement « Une opération d'accès réflexive illégale s'est produite »Problème : le pool de JCE sessions est épuiséProblème : fuite de mémoire SDK liée aux getKey opérations du client 5

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Problèmes connus relatifs au JCE SDK pour AWS CloudHSM

Les problèmes suivants ont un impact sur JCE SDK le formulaire AWS CloudHSM.

Problème : lorsque vous utilisez des paires de clés asymétriques, vous voyez la capacité de clé occupée même lorsque vous ne créez pas ou n'importez pas explicitement des clés

  • Conséquence : ce problème peut vous empêcher HSMs de manquer d'espace clé de manière inattendue et se produit lorsque votre application utilise un objet JCE clé standard pour les opérations de chiffrement au lieu d'un CaviumKey objet. Lorsque vous utilisez un objet JCE clé standard, il importe CaviumProvider implicitement cette clé dans le en HSM tant que clé de session et ne supprime pas cette clé tant que l'application ne se ferme pas. Par conséquent, les clés s'accumulent pendant l'exécution de l'application et peuvent vous HSMs faire manquer d'espace libre pour les clés, bloquant ainsi votre application.

  • Solution : Lorsque vous utilisez la CaviumSignature classe, la CaviumCipher classe, la CaviumMac classe ou la CaviumKeyAgreement classe, vous devez fournir la clé en tant qu'objet clé CaviumKey au lieu d'un objet JCE clé standard.

    Vous pouvez convertir manuellement une clé normale en une clé CaviumKey à l'aide de la classe ImportKey, puis supprimer manuellement la clé une fois l'opération terminée.

  • Statut de résolution : nous mettons à jour CaviumProvider pour gérer correctement les importations implicites. Une fois disponible, la mise à jour sera annoncée sur la page de l'historique des versions.

Problème : Le JCE KeyStore est en lecture seule

  • Conséquence : vous ne pouvez pas stocker un type d'objet qui n'est pas pris HSM en charge par le JCE keystore aujourd'hui. Plus particulièrement, vous ne pouvez pas stocker des certificats dans le magasin de clés. Cela empêche l'interopérabilité avec des outils tels que jarsigner qui s'attendent à trouver le certificat dans le keystore.

  • Solution : Vous pouvez retravailler votre code pour charger des certificats à partir de fichiers locaux ou d'un emplacement du compartiment S3 plutôt que depuis le magasin de clés.

  • Statut de résolution : Nous ajoutons actuellement la prise en charge du stockage de certificats dans le magasin de clés. Une fois disponible, la fonction sera annoncée sur la page de l'historique des versions.

Problème : les tampons pour le AES GCM chiffrement ne peuvent pas dépasser 16 000 octets

En plusieurs parties AES : GCM le chiffrement n'est pas pris en charge.

  • Conséquence : vous ne pouvez pas utiliser AES - GCM pour chiffrer des données de plus de 16 000 octets.

  • Solution : vous pouvez utiliser un autre mécanisme, tel que AES -CBC, ou vous pouvez diviser vos données en plusieurs parties et chiffrer chaque élément individuellement. Si vous divisez les données, vous devez gérer le texte chiffré divisé et son déchiffrement. Étant donné FIPS que le vecteur d'initialisation (IV) pour AES - GCM doit être généré sur leHSM, le vecteur IV pour chaque AES-GCM-encrypted donnée sera différent.

  • État de la résolution : nous corrigeons explicitement le SDK problème pour qu'il échoue si la mémoire tampon de données est trop grande. Nous évaluons les alternatives possibles pour prendre en charge des mémoires tampons de plus grande taille sans devoir s'appuyer sur le chiffrement en plusieurs parties. Les mises à jour seront annoncées sur le forum AWS CloudHSM et sur la page de l'historique des versions.

Problème : La dérivation de la clé Diffie-Hellman (ECDH) à courbe elliptique est partiellement exécutée dans HSM

Votre clé privée EC est conservée à tout HSM moment, mais le processus de dérivation de la clé s'effectue en plusieurs étapes. Par conséquent, les résultats intermédiaires de chaque étape sont disponibles sur le client. Un exemple de dérivation ECDH clé est disponible dans les exemples de code Java.

  • Conséquence : le client SDK 3 ajoute des ECDH fonctionnalités auJCE. Lorsque vous utilisez la KeyAgreement classe pour dériver un SecretKey, elle est d'abord disponible sur le client, puis importée dans leHSM. Un handle de clé est ensuite retourné à votre application.

  • Solution : si vous implémentezSSL/TLSOffload in AWS CloudHSM, cette limitation ne posera peut-être aucun problème. Si votre application exige que votre clé reste dans une FIPS limite à tout moment, envisagez d'utiliser un protocole alternatif qui ne repose pas sur la dérivation de ECDH clés.

  • État de résolution : Nous développons l'option permettant d'effectuer la dérivation des ECDH clés entièrement dans leHSM. Lorsqu'elle sera disponible, nous annoncerons l'implémentation mise à jour sur la page de l'historique des versions.

Problème : KeyGenerator et interprète KeyAttribute incorrectement le paramètre de taille de clé en nombre d'octets au lieu de bits

Lors de la génération d'une clé à l'aide de la init fonction de la KeyGenerator classe ou de l'SIZEattribut de l'AWS CloudHSM KeyAttribute énumération, on s'attend à API tort à ce que l'argument soit le nombre d'octets clés, alors qu'il devrait plutôt être le nombre de bits de clé.

  • Conséquence : SDK les versions client 5.4.0 à 5.4.2 s'attendent à tort à ce que la taille de clé soit fournie à la taille spécifiée APIs en octets.

  • Solution : convertissez la taille de la clé en bits en octets avant d'utiliser la KeyGenerator classe ou KeyAttribute l'énumération pour générer des clés à l'aide du AWS CloudHSM JCE fournisseur si vous utilisez les SDK versions client 5.4.0 à 5.4.2.

  • État de résolution : mettez à niveau votre SDK version client vers la version 5.5.0 ou ultérieure, qui inclut un correctif permettant de s'attendre correctement à la taille des clés en bits lors de l'utilisation de la KeyGenerator classe ou de l' KeyAttribute énumération pour générer des clés.

Problème : le client SDK 5 lance l'avertissement « Une opération d'accès réflexive illégale s'est produite »

Lorsque vous utilisez Client SDK 5 avec Java 11, Cloud HSM émet l'avertissement Java suivant : 

```
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
```

Ces avertissements n'ont aucun impact. Nous sommes conscients de ce problème et nous nous efforçons de le résoudre. Aucune résolution ni solution de contournement n'est nécessaire.

Problème : le pool de JCE sessions est épuisé

Conséquence : il se peut que vous ne puissiez pas effectuer d'opérations JCE après avoir reçu le message suivant :

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

Solutions de contournement :

  • Redémarrez votre JCE application en cas de problème.

  • Lorsque vous effectuez une opération, il se peut que vous deviez terminer l'JCEopération avant de perdre toute référence à l'opération.

    Note

    En fonction de l'opération, une méthode de complétion peut être nécessaire.

    Opération Méthode(s) de complétion
    Chiffrement

    doFinal() en mode chiffrement ou déchiffrement

    wrap() en mode d’encapsulage

    unwrap() en mode de désencapsulage
    KeyAgreement

    generateSecret() ou generateSecret(String)
    KeyPairGenerator

    generateKeyPair(), genKeyPair() ou reset()
    KeyStore Aucune méthode n'est nécessaire
    MAC

    doFinal() ou reset()
    MessageDigest

    digest() ou reset()
    SecretKeyFactory Aucune méthode n'est nécessaire
    SecureRandom Aucune méthode n'est nécessaire
    Signature

    sign() en mode signature

    verify() en mode vérification

État de la résolution : nous avons résolu ce problème dans Client SDK 5.9.0 et versions ultérieures. Pour résoudre ce problème, mettez à niveau votre client SDK vers l'une de ces versions.

Problème : fuite de mémoire SDK liée aux getKey opérations du client 5

  • Conséquence : l'APIgetKeyopération présente une fuite de mémoire JCE dans les SDK versions 5.10.0 et antérieures du client. Si vous l'utilisez getKey API plusieurs fois dans votre application, cela entraînera une augmentation de la mémoire et, par conséquent, une augmentation de l'empreinte mémoire de votre application. Au fil du temps, cela peut provoquer des erreurs de régulation ou nécessiter le redémarrage de l'application.

  • Solution : nous recommandons la mise à niveau vers le client SDK 5.11.0. Si cela n'est pas possible, nous vous recommandons de ne pas les appeler getKey API plusieurs fois dans votre application. Réutilisez plutôt autant que possible la clé précédemment renvoyée getKey lors de l'opération précédente.

  • État de la résolution : mettez à niveau votre SDK version client vers la version 5.11.0 ou ultérieure, qui inclut un correctif pour ce problème.