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 à la bibliothèque PKCS \$111 pour AWS CloudHSM
Les problèmes suivants ont un impact sur la bibliothèque PKCS \$111 pour AWS CloudHSM.
**Topics**
+ [
## Problème : l'encapsulation de la clé AES dans la version 3.0.0 de la bibliothèque PKCS \$111 n'est pas validée avant utilisation IVs
](#ki-pkcs11-1)
+ [
## Problème : Le kit SDK PKCS \$111 2.0.4 et versions antérieures utilisaient toujours le vecteur d'initialisation par défaut de `0xA6A6A6A6A6A6A6A6` pour l'encapsulage et le désencapsulage des clés AES.
](#ki-pkcs11-2)
+ [
## Problème : l'attribut `CKA_DERIVE` n'est pas pris en charge et n'est pas géré.
](#ki-pkcs11-3)
+ [
## Problème : l'attribut `CKA_SENSITIVE` n'est pas pris en charge et n'est pas géré.
](#ki-pkcs11-4)
+ [
## Problème : Le hachage et la signature en plusieurs parties ne sont pas pris en charge.
](#ki-pkcs11-5)
+ [
## Problème : `C_GenerateKeyPair` ne gère pas `CKA_MODULUS_BITS` ou `CKA_PUBLIC_EXPONENT` dans le modèle privé d'une manière conforme aux normes.
](#ki-pkcs11-6)
+ [
## Problème : Les mémoires tampons des opérations d'API `C_Encrypt` et `C_Decrypt` ne doivent pas avoir une taille de plus de 16 Ko lors de l'utilisation du mécanisme `CKM_AES_GCM`.
](#ki-pkcs11-8)
+ [
## Problème : La dérivation de clé Diffie-Hellman à courbe elliptique (ECDH) est exécutée partiellement dans le HSM.
](#ki-pkcs11-9)
+ [
## Problème : la vérification des signatures secp256k1 échoue sur des EL6 plateformes telles que Cent et RHEL 6 OS6
](#ki-pkcs11-10)
+ [
## Problème : une séquence incorrecte d'appels de fonction donne des résultats indéfinis au lieu d'échouer
](#ki-pkcs11-11)
+ [
## Problème : la session en lecture seule n'est pas prise en charge dans le SDK 5
](#ki-pkcs11-13)
+ [
## Problème : le fichier `cryptoki.h` d'en-tête est réservé à Windows
](#ki-pkcs11-14)
## Problème : l'encapsulation de la clé AES dans la version 3.0.0 de la bibliothèque PKCS \$111 n'est pas validée avant utilisation IVs
Si vous spécifiez un vecteur d’initialisation d'une longueur inférieure à 8 octets, celui-ci est complété par des octets imprévisibles avant utilisation.
**Note**
Cela a un impact sur `C_WrapKey` uniquement avec un mécanisme `CKM_AES_KEY_WRAP`.
+ **Impact :** Si vous spécifiez un vecteur d’initialisation d’une longueur inférieure à 8 octets dans la version 3.0.0 de la bibliothèque PKCS\$111, vous risquez de ne pas pouvoir désencapsuler la clé.
+ **Solutions de contournement :**
+ Nous vous recommandons fortement de procéder à une mise à niveau vers la version 3.0.1 ou ultérieure de la bibliothèque PKCS\$111, qui applique correctement la longueur des vecteurs d'initialisation pendant l'encapsulage des clés AES. Modifiez votre code d'encapsulage pour transmettre un vecteur d'initialisation NULL, ou spécifiez le vecteur d'initialisation par défaut de `0xA6A6A6A6A6A6A6A6`. Pour plus d'informations, voir [Personnaliser IVs avec une longueur non conforme pour l'encapsulation des clés AES](troubleshooting-aes-keys.md).
+ Si vous avez encapsulé des clés avec la version 3.0.0 de la bibliothèque PKCS \$111 en utilisant un vecteur d'initialisation d'une longueur inférieure à 8 octets, contactez-nous pour obtenir de l'[aide](https://aws.amazon.com/support).
+ **Statut de la résolution :** ce problème a été résolu dans la version 3.0.1 de la bibliothèque PKCS \$111. Pour encapsuler des clés à l'aide de l'encapsulage de clés AES, spécifiez un vecteur d'initialisation de valeur NULL ou d'une longueur égale à 8 octets.
## Problème : Le kit SDK PKCS \$111 2.0.4 et versions antérieures utilisaient toujours le vecteur d'initialisation par défaut de `0xA6A6A6A6A6A6A6A6` pour l'encapsulage et le désencapsulage des clés AES.
Les informations fournies par l'utilisateur IVs ont été ignorées en silence.
**Note**
Cela a un impact sur `C_WrapKey` uniquement avec un mécanisme `CKM_AES_KEY_WRAP`.
+ **Impact :**
+ Si vous avez utilisé le kit SDK PKCS \$111 2.0.4 ou version antérieure et un vecteur d'initialisation fourni par l'utilisateur, vos clés sont encapsulées avec le vecteur d'initialisation par défaut de `0xA6A6A6A6A6A6A6A6`.
+ Si vous avez utilisé le kit PKCS \$111 3.0.0 ou version ultérieure et un vecteur d'initialisation fourni par l'utilisateur, vos clés sont encapsulées avec le vecteur d'initialisation fourni par l'utilisateur.
+ **Solutions de contournement :**
+ Pour désencapsuler des clés encapsulées avec le kit SDK PKCS \$111 2.0.4 ou version antérieure, utilisez le vecteur d’initialisation par défaut de `0xA6A6A6A6A6A6A6A6`.
+ Pour désencapsuler des clés encapsulées avec le kit SDK PKCS \$111 3.0.0 ou version ultérieure, utilisez le vecteur d’initialisation fourni par l’utilisateur.
+ **État de résolution :** Nous vous recommandons fortement de modifier votre code d'encapsulage et de désencapsulage pour transmettre un vecteur d'initialisation NULL, ou de spécifier le vecteur d'initialisation par défaut de `0xA6A6A6A6A6A6A6A6`.
## Problème : l'attribut `CKA_DERIVE` n'est pas pris en charge et n'est pas géré.
+ **Statut de résolution : **nous avons implémenté des correctifs pour accepter `CKA_DERIVE` s'il a la valeur `FALSE`. `CKA_DERIVE` défini sur `TRUE` ne sera pas pris en charge tant que nous n'aurons pas ajouté la prise en charge de la fonction de dérivation de clés à AWS CloudHSM. Vous devez mettre à jour votre client et les kits SDK vers la version 1.1.1 ou ultérieur pour tirer parti du correctif.
## Problème : l'attribut `CKA_SENSITIVE` n'est pas pris en charge et n'est pas géré.
+ **État de résolution : **nous avons implémenté les correctifs pour accepter et honorer correctement l'attribut `CKA_SENSITIVE`. Vous devez mettre à jour votre client et les kits SDK vers la version 1.1.1 ou ultérieur pour tirer parti du correctif.
## Problème : Le hachage et la signature en plusieurs parties ne sont pas pris en charge.
+ **Impact : **`C_DigestUpdate` et `C_DigestFinal` ne sont pas implémentés. `C_SignFinal` n'est pas implémenté non plus et échoue avec l'erreur `CKR_ARGUMENTS_BAD` pour un tampon non-`NULL`.
+ **Solution : hachez** vos données dans votre application et utilisez-les AWS CloudHSM uniquement pour signer le hachage.
+ **État de la résolution :** nous sommes en train de corriger le client et d' SDKsimplémenter correctement le hachage 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 : `C_GenerateKeyPair` ne gère pas `CKA_MODULUS_BITS` ou `CKA_PUBLIC_EXPONENT` dans le modèle privé d'une manière conforme aux normes.
+ **Impact : **`C_GenerateKeyPair` doit renvoyer `CKA_TEMPLATE_INCONSISTENT` lorsque le modèle privé contient `CKA_MODULUS_BITS` ou `CKA_PUBLIC_EXPONENT`. Au lieu de cela, il génère une clé privée dont tous les champs d'utilisation sont définis sur `FALSE`. La clé ne peut pas être utilisée.
+ **Solution : **Nous recommandons que votre application vérifie les valeurs des champs d'utilisation en plus du code d'erreur.
+ **État de résolution : **Nous sommes en train de mettre en place des correctifs pour renvoyer le message d'erreur adéquat lorsqu'un modèle de clé privée incorrect est utilisé. La bibliothèque PKCS \$111 utilisée sera annoncée sur la page d'historique des versions.
## Problème : Les mémoires tampons des opérations d'API `C_Encrypt` et `C_Decrypt` ne doivent pas avoir une taille de plus de 16 Ko lors de l'utilisation du mécanisme `CKM_AES_GCM`.
AWS CloudHSM ne prend pas en charge le chiffrement AES-GCM en plusieurs parties.
+ **Impact : **Vous ne pouvez pas utiliser le mécanisme `CKM_AES_GCM` pour chiffrer des données de plus de 16 Ko.
+ **Solution :** vous pouvez utiliser un autre mécanisme tel que `CKM_AES_CBC``CKM_AES_CBC_PAD`, ou vous pouvez diviser vos données en plusieurs parties et chiffrer chaque élément individuellement. `AES_GCM` Si vous en utilisez`AES_GCM`, vous devez gérer la division de vos données et le chiffrement ultérieur. AWS CloudHSM n'effectue pas de chiffrement AES-GCM en plusieurs parties pour vous. Notez que FIPS nécessite que le vecteur d'initialisation (IV) `AES-GCM` soit généré sur le HSM. Par conséquent, le vecteur d'initialisation de chaque portion de données AES GCM chiffré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 retournons `CKR_MECHANISM_INVALID` pour les opérations d'API `C_EncryptUpdate` et `C_DecryptUpdate`. 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 AWS CloudHSM forum et sur la page d'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.
+ **Conséquence :** dans le SDK client 3, la clé dérivée à l'aide du `CKM_ECDH1_DERIVE` mécanisme 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 SSL/TLS déchargement 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 : le** SDK 5.16 prend désormais en charge l'ECDH avec dérivation de clés, qui est entièrement effectuée dans le HSM.
## Problème : la vérification des signatures secp256k1 échoue sur des EL6 plateformes telles que Cent et RHEL 6 OS6
En effet, la bibliothèque PKCS \$111 CloudHSM permet d'éviter un appel réseau lors de l'initialisation de l'opération de vérification en utilisant OpenSSL pour vérifier les données de courbe EC. Comme SECP256k1 n'est pas pris en charge par le package OpenSSL par défaut sur les plateformes, l'initialisation échoue. EL6
+ **Conséquence :** la vérification de signature SECP256k1 échouera sur les plateformes. EL6 L’appel de vérification échoue avec une erreur `CKR_HOST_MEMORY`.
+ **Solution :** nous vous recommandons d'utiliser Amazon Linux 1 ou n'importe quelle EL7 plateforme si votre application PKCS \$111 doit vérifier les signatures secp256k1. Vous pouvez également effectuer une mise à niveau vers une version du package OpenSSL qui prend en charge la courbe secp256k1.
+ **État de résolution : **Nous implémentons des correctifs pour revenir au HSM si la validation de courbe locale n’est pas disponible. La bibliothèque PKCS \$111 mise à jour sera annoncée sur la page de l’ [historique des versions](client-history.md).
## Problème : une séquence incorrecte d'appels de fonction donne des résultats indéfinis au lieu d'échouer
+ **Conséquence** : si vous appelez une séquence de fonctions incorrecte, le résultat final est incorrect même si chaque appel de fonction renvoie un résultat positif. Par exemple, les données déchiffrées peuvent ne pas correspondre au texte brut d'origine ou les signatures peuvent ne pas être vérifiées. Ce problème concerne à la fois les opérations en une seule partie et en plusieurs parties.
Exemples de séquences de fonctions incorrectes :
+ `C_EncryptInit`/`C_EncryptUpdate` suivi de `C_Encrypt`
+ `C_DecryptInit`/`C_DecryptUpdate` suivi de `C_Decrypt`
+ `C_SignInit`/`C_SignUpdate` suivi de `C_Sign`
+ `C_VerifyInit`/`C_VerifyUpdate` suivi de `C_Verify`
+ `C_FindObjectsInit` suivi de `C_FindObjectsInit`
+ **Solution** : Votre application doit, conformément à la spécification PKCS \$111, utiliser la bonne séquence d'appels de fonction pour les opérations en une ou plusieurs parties. Dans ce cas, votre application ne doit pas s'appuyer sur la bibliothèque CloudHSM PKCS \$111 pour renvoyer une erreur.
## Problème : la session en lecture seule n'est pas prise en charge dans le SDK 5
+ **Problème :** le SDK 5 ne prend pas en charge l'ouverture de sessions en lecture seule avec `C_OpenSession`.
+ **Conséquence :** si vous tentez d'appeler `C_OpenSession` sans fournir `CKF_RW_SESSION`, l'appel échouera avec le message d'erreur `CKR_FUNCTION_FAILED`.
+ **Solution :** Lorsque vous ouvrez une session, vous devez transmettre les indicateurs `CKF_SERIAL_SESSION | CKF_RW_SESSION` à l'appel de fonction `C_OpenSession`.
## Problème : le fichier `cryptoki.h` d'en-tête est réservé à Windows
+ **Problème :** avec les versions 5.0.0 à 5.4.0 du SDK AWS CloudHSM client 5 sous Linux, le fichier d'en-tête n'`/opt/cloudhsm/include/pkcs11/cryptoki.h`est compatible qu'avec les systèmes d'exploitation Windows.
+ **Conséquence :** vous pouvez rencontrer des problèmes lorsque vous essayez d'inclure ce fichier d'en-tête dans votre application sur des systèmes d'exploitation basés sur Linux.
+ **État de résolution :** mise à niveau vers la version 5.4.1 ou supérieure du SDK AWS CloudHSM client 5, qui inclut une version compatible avec Linux de ce fichier d'en-tête.