Problèmes connus relatifs à la bibliothèque PKCS #11

Problème : le AES key wrap dans la version 3.0.0 de la bibliothèque PKCS #11 n'est pas validé IVs avant utilisation

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.

• Conséquence : si vous fournissez un IV de moins de 8 octets dans la version 3.0.0 de la bibliothèque PKCS #11, il se peut que vous ne puissiez pas déballer la clé.

• Solutions de contournement :

  • Nous vous recommandons vivement de passer à la version 3.0.1 ou supérieure de la bibliothèque PKCS #11, qui applique correctement la longueur de l'IV lors de la saisie des AES touches. Modifiez votre code d'emballage pour transmettre un NULL IV, ou spécifiez le IV par défaut de0xA6A6A6A6A6A6A6A6. Pour plus d'informations, voir Personnalisation IVs avec une longueur non conforme pour l'emballage des AES clés.

  • Si vous avez encapsulé des clés avec la version 3.0.0 de la bibliothèque PKCS #11 en utilisant un IV inférieur à 8 octets, contactez-nous pour obtenir de l'aide.

• État de la résolution : ce problème a été résolu dans la version 3.0.1 de la bibliothèque PKCS #11. Pour encapsuler les clés à l'aide AES de l'encapsulation des touches, spécifiez un IV d'une longueur de 2 NULL ou 8 octets.

Problème : PKCS #11 SDK 2.0.4 et les versions antérieures utilisaient toujours l'IV par défaut 0xA6A6A6A6A6A6A6A6 pour l'enroulement et le AES déballage des clés

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é PKCS #11 SDK 2.0.4 ou une version antérieure et un IV fourni par l'utilisateur, vos clés sont encapsulées avec le IV par défaut de. 0xA6A6A6A6A6A6A6A6

  • Si vous avez utilisé PKCS #11 SDK 3.0.0 ou une version ultérieure et un IV fourni par l'utilisateur, vos clés sont enveloppées dans le IV fourni par l'utilisateur.

• Solutions de contournement :

  • Pour déballer les clés encapsulées avec PKCS #11 SDK 2.0.4 ou une version antérieure, utilisez l'IV par défaut de. 0xA6A6A6A6A6A6A6A6

  • Pour déballer les clés encapsulées avec PKCS #11 SDK 3.0.0 ou version ultérieure, utilisez le code IV fourni par l'utilisateur.

• État de résolution : nous vous recommandons vivement de modifier votre code d'emballage et de déballage pour transmettre un NULL IV, ou de spécifier le IV par défaut de0xA6A6A6A6A6A6A6A6.

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 ou vos clients vers la version 1.1.1 ou supérieure pour bénéficier du correctif. SDK

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 ou vos clients vers la version 1.1.1 ou supérieure pour bénéficier du correctif. SDK

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 #11 mise à jour sera annoncée sur la page de l'historique des versions.

Problème : les tampons pour les C_Decrypt API opérations C_Encrypt et ne peuvent pas dépasser 16 Ko lors de l'utilisation du mécanisme CKM_AES_GCM

AWS CloudHSM ne prend pas en charge le GCM chiffrement en plusieurs partiesAES.

• 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_CBCCKM_AES_CBC_PAD, ou vous pouvez diviser vos données en plusieurs parties et chiffrer chaque élément individuellement. AES_GCM Si vous en utilisezAES_GCM, vous devez gérer la division de vos données et le chiffrement ultérieur. AWS CloudHSM n'effectue pas de GCM chiffrement en plusieurs parties AES à votre place. Notez que cela FIPS nécessite que le vecteur d'initialisation (IV) AES-GCM soit généré sur leHSM. Par conséquent, le IV pour chaque élément de vos AES données GCM cryptées sera différent.

• État de la résolution : nous corrigeons explicitement le problème SDK pour qu'il échoue si la mémoire tampon est trop grande. Nous revenons CKR_MECHANISM_INVALID pour les C_DecryptUpdate API opérations C_EncryptUpdate et. 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 la clé Diffie-Hellman (ECDH) à courbe elliptique est partiellement exécutée dans le 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.

• Conséquence : dans le client SDK 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 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 à l'intérieur d'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. L'implémentation mise à jour sera annoncée sur la page de l'historique des versions.

Problème : La vérification des signatures secp256k1 échoue sur des EL6 plateformes telles que Cent et 6 OS6 RHEL

Cela est dû au fait que la bibliothèque Cloud HSM PKCS #11 évite un appel réseau lors de l'initialisation de l'opération de vérification en utilisant Open SSL pour vérifier les données de la courbe EC. Comme SECP256k1 n'est pas pris en charge par le SSL package Open par défaut sur les EL6 plateformes, l'initialisation échoue.

• 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 #11 doit vérifier les signatures secp256k1. Vous pouvez également passer à une version du SSL package Open qui prend en charge la courbe secp256k1.

• État de la résolution : nous mettons en œuvre des correctifs pour revenir à la solution HSM si la validation de la courbe locale n'est pas disponible. La bibliothèque PKCS #11 mise à jour sera annoncée sur la page de l'historique des versions.

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 #11, 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 Cloud HSM PKCS #11 pour renvoyer une erreur.

Problème : la session en lecture seule n'est pas prise en charge dans SDK 5

• Problème : 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 de AWS CloudHSM Client SDK 5 sous Linux, le fichier d'en-tête n'/opt/cloudhsm/include/pkcs11/cryptoki.hest 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 la résolution : mise à niveau vers AWS CloudHSM Client SDK 5 version 5.4.1 ou supérieure, qui inclut une version compatible avec Linux de ce fichier d'en-tête.