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.
Les problèmes suivants ont un impact sur le SDK JCE pour. AWS CloudHSM
Rubriques
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 clé JCE standard pour les opérations de chiffrement au lieu d'un
CaviumKeyobjet. Lorsque vous utilisez un objet de clé JCE standard,CaviumProviderimporte implicitement cette clé dans le HSM, car une clé de session ne supprime pas la clé tant que l'application n'est pas finie. 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 classe
CaviumSignature,CaviumCipher,CaviumMacouCaviumKeyAgreement, vous devez fournir la clé comme un objet de cléCaviumKeyau lieu d'un objet de clé JCE standard.Vous pouvez convertir manuellement une clé normale en une clé
CaviumKeyà l'aide de la classeImportKey, puis supprimer manuellement la clé une fois l'opération terminée. -
Statut de résolution : nous mettons à jour
CaviumProviderpour 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
-
Impact : À l'heure actuelle, vous ne pouvez pas stocker un type d'objet de type qui n'est pas pris en charge par le HSM dans le JCE Keystore. 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 mémoires tampons de chiffrement AES GCM ne peuvent pas dépasser 16 000 octets.
Le chiffrement AES GCM en plusieurs parties n'est pas pris en charge.
-
Impact : Vous ne pouvez pas utiliser AES-GCM pour chiffrer des données dont la taille est supérieure à 16 000 octets.
-
Solution : Vous pouvez utiliser un autre mécanisme tel que AES-CBC ou diviser vos données en plusieurs parties et chiffrer chaque partie individuellement. Si vous divisez les données, vous devez gérer le texte chiffré divisé et son déchiffrement. Comme FIPS exige que le vecteur d'initialisation (IV) pour AES-GCM soit généré sur le HSM, l'IV pour chaque AES-GCM-encrypted élément de données sera différent.
-
État de résolution : Nous sommes en train de corriger le kit SDK afin qu'il échoue de façon explicite si le tampon de données est trop volumineux. 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 clé Diffie-Hellman à courbe elliptique (ECDH) est exécutée partiellement dans le HSM.
Votre clé privée EC reste dans le HSM à tout moment, mais le processus de dérivation de clés est effectué en plusieurs étapes. Par conséquent, les résultats intermédiaires de chaque étape sont disponibles sur le client. Un exemple de dérivation de clé ECDH est disponible dans les exemples de code Java.
-
Conséquence : le SDK client 3 ajoute des fonctionnalités ECDH au JCE. Lorsque vous utilisez la
KeyAgreementclasse pour dériver un SecretKey, elle est d'abord disponible sur le client, puis importée dans le HSM. Un handle de clé est ensuite retourné à votre application. -
Solution : si vous implémentez le déchargement SSL/TLS dans AWS CloudHSM, cette limitation ne posera peut-être aucun problème. Si votre application nécessite que votre clé reste dans une limite FIPS à tout moment, envisagez d'utiliser un autre protocole qui ne s'appuie pas sur la dérivation de clés ECDH.
-
État de résolution : Nous développons actuellement la possibilité d'effectuer la dérivation de clés ECDH entièrement dans le HSM. 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 classeSIZEattribut de l'AWS CloudHSM KeyAttribute énumération, l'API s'attend à tort à ce que l'argument soit le nombre d'octets de clé, alors qu'il devrait plutôt être le nombre de bits de clé.
-
Conséquence : les versions 5.4.0 à 5.4.2 du SDK client s'attendent à tort à ce que la taille de clé soit fournie à la valeur 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 fournisseur AWS CloudHSM JCE si vous utilisez les versions 5.4.0 à 5.4.2 du SDK client.
-
État de résolution : mettez à niveau la version du SDK 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 SDK client 5 émet l'avertissement « Une opération d'accès réflexif illégale s'est produite »
Lorsque vous utilisez le SDK client 5 avec Java 11, CloudHSM é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 sessions JCE est épuisé
Conséquence : il se peut que vous ne puissiez pas effectuer d'opérations dans 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 application JCE en cas de problème.
Lorsque vous effectuez une opération, vous devrez peut-être terminer l'opération JCE 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échiffrementwrap()en mode d’encapsulageunwrap()en mode de désencapsulageKeyAgreement generateSecret()ougenerateSecret(String)KeyPairGenerator generateKeyPair(),genKeyPair()oureset()KeyStore Aucune méthode n'est nécessaire MAC doFinal()oureset()MessageDigest digest()oureset()SecretKeyFactory Aucune méthode n'est nécessaire SecureRandom Aucune méthode n'est nécessaire Signature sign()en mode signatureverify()en mode vérification
État de la résolution : nous avons résolu ce problème dans le SDK client 5.9.0 et versions ultérieures. Pour résoudre ce problème, mettez à niveau votre SDK client vers l'une de ces versions.
Problème : fuite de mémoire du SDK client 5 avec les opérations GetKey
-
Conséquence : l'
getKeyopération d'API présente une fuite de mémoire dans JCE dans les versions 5.10.0 et antérieures du SDK client. Si vous utilisez l'getKeyAPI 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 SDK client 5.11.0. Si cela n'est pas possible, nous vous recommandons de ne pas appeler l'
getKeyAPI plusieurs fois dans votre application. Réutilisez plutôt autant que possible la clé précédemment renvoyéegetKeylors de l'opération précédente. -
État de la résolution : mettez à niveau la version du SDK client vers la version 5.11.0 ou ultérieure, qui inclut un correctif pour ce problème.
