Problèmes connus liés à la bibliothèque PKCS #11 pour AWS CloudHSM

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#11, vous risquez de ne pas pouvoir désencapsuler la clé.

Solutions de contournement :

Statut 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 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.

Impact :

Solutions de contournement :

É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.

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.

É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.

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 résolution : Nous corrigeons actuellement le client et les kits SDK afin qu'ils mettent en œuvre 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.

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 utilisée sera annoncée sur la page d'historique des versions.

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 diviser vos données en morceaux et chiffrer chaque élément individuellement. AES_GCM Si vous utilisezAES_GCM, vous devez gérer la division de vos données et le cryptage ultérieur. AWS CloudHSM n'effectue pas le AES-GCM chiffrement partitionné 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, l'IV pour chaque élément de vos données AES-GCM crypté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.

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 SSL/TLS Offload dans AWS CloudHSM, cette limitation ne pose peut-être pas de 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 la résolution : le SDK 5.16 prend désormais en charge l'ECDH avec une dérivation de clé qui est entièrement réalisée dans le HSM.

Impact : La vérification de signature Secp256k1 échoue sur les plateformes EL6. L’appel de vérification échoue avec une erreur CKR_HOST_MEMORY.

Solution de contournement : Nous vous conseillons d'utiliser Amazon Linux 1 ou une plateforme EL7 si votre application PKCS #11 a besoin de vérifier des 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 #11 mise à jour sera annoncée sur la page de l’ historique des versions.

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.

Les tableaux suivants présentent les séquences d'appels de fonction correctes pour les opérations PKCS #11.

Séquences correctes pour les opérations sur une seule pièce :

Séquences correctes pour les opérations en plusieurs parties :

Solution  : votre application doit, conformément à la spécification PKCS #11, utiliser la séquence correcte d'appels de fonction pour les opérations en une seule partie et en plusieurs parties, comme indiqué dans les tableaux ci-dessus. Dans ce cas, votre application ne doit pas s'appuyer sur la bibliothèque CloudHSM PKCS #11 pour renvoyer une erreur.

Problème : le SDK 5 ne prend pas en charge l'ouverture de Read-Only sessions avecC_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 : avec les versions 5.0.0 à 5.4.0 du SDK AWS CloudHSM client 5 sous Linux, le fichier d'en-tête /opt/cloudhsm/include/pkcs11/cryptoki.h est uniquement compatible avec les systèmes d'exploitation Windows.

Conséquence : vous pouvez rencontrer des problèmes lorsque vous tentez d'inclure ce fichier d'en-tête dans votre application sur les systèmes Linux-based d'exploitation.

État de la résolution : passez à la version 5.4.1 ou supérieure du SDK AWS CloudHSM client 5, qui inclut une Linux-compatible version de ce fichier d'en-tête.

Conséquence : si votre application ne fait que réessayerCKR_FUNCTION_FAILED, elle ne réessaie pas ces requêtes limitées.

Solution : réessayez les opérations limitées avec un retard exponentiel à la fois sur et. CKR_DEVICE_ERROR CKR_FUNCTION_FAILED Si la limitation persiste, ajoutez d'autres HSM à votre cluster pour augmenter le taux total de lecture et d'écriture, ou réduisez votre taux de demandes. Pour de plus amples informations, veuillez consulter Limitation du HSM.

État de la résolution : ce problème a été résolu dans le SDK client 5.18.0. C_GetAttributeValuerenvoie désormais CKR_FUNCTION_FAILED pour les lectures limitées du magasin de certificats et des attributs clés. Passez à la version 5.18.0 ou ultérieure pour bénéficier du correctif.

Conséquence : une opération de stockage de certificats limitée renvoie une erreur à votre application au lieu d'être réessayée automatiquement.

Solution : réessayez les opérations de stockage de certificats limitées dans votre application en procédant à un arrêt exponentiel. Si la limitation persiste, ajoutez d'autres HSM à votre cluster pour augmenter le taux total de lecture et d'écriture, ou réduisez votre taux de demandes. Pour de plus amples informations, veuillez consulter Limitation du HSM.

État de la résolution : ce problème a été résolu dans le SDK client 5.18.0. La bibliothèque PKCS #11 réessaie désormais automatiquement les opérations de stockage de certificats limitées. Passez à la version 5.18.0 ou ultérieure pour bénéficier du correctif.