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.
Mécanismes pris en charge pour AWS CloudHSM le SDK client 3
La bibliothèque PKCS #11 prend en charge les algorithmes suivants pour le SDK AWS CloudHSM client 3 :
-
Chiffrement et déchiffrement — AES-CBC, AES-CTR, AES-ECB, AES-GCM, -CBC, -ECB, RSA-OAEP et RSA-PKCS DES3 DES3
-
Signature et vérification : RSA, HMAC et ECDSA ; avec et sans hachage
-
Hash/digest — SHA1,, SHA224 SHA256, et SHA384 SHA512
-
Encapsulage de clés – AES Key Wrap,4 AES-GCM, RSA-AES et RSA-OAEP
-
Dérivation de clés — ECDH, 5 SP800-108 CTR KDF
Le tableau des mécanismes et des fonctions de la bibliothèque PKCS #11
La bibliothèque PKCS #11 est conforme à la version 2.40 de la spécification PKCS #11. Pour appeler une fonction de chiffrement utilisant PKCS #11, appelez une fonction à l'aide d'un mécanisme donné. Le tableau suivant résume les combinaisons de fonctions et de mécanismes prises en charge par AWS CloudHSM.
Interprétation du tableau de mécanismes/fonctions PKCS #11 pris en charge
La marque ✔ indique que le mécanisme de la fonction est pris en AWS CloudHSM charge. Nous ne prenons pas en charge toutes les fonctions possibles répertoriés dans la spécification PKCS #11. La marque ✖ indique qu' AWS CloudHSM elle ne prend pas encore en charge le mécanisme pour la fonction donnée, même si la norme PKCS #11 l'autorise. Les cellules vides indiquent que la norme PKCS #11 ne prend pas en charge le mécanisme pour la fonction donnée.
Mécanisme |
Fonctions |
||||||
|---|---|---|---|---|---|---|---|
|
Générer une clé ou une Paire de clés |
Connexion et vérification |
SR & VR |
Digest |
Chiffrement et déchiffrement |
Dérivation de clé |
Envelopper et UnWrap |
|
|
✔ |
|
|
|
|
|
|
|
✔2 |
|
|
|
|
|
|
|
|
✔ |
|
|
✔ |
|
|
|
✔1 | ✖ | ✔1 |
|
✔1 | ||
|
|
|
|
|
✔1 |
|
✔6 |
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔1 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
✔ |
|
|
|
|
|
|
|
|
✔1 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
✔3.2 |
|
|
|
|
|
|
|
|
|
|
|
✔5 |
|
|
|
|
|
|
|
✔ |
|
|
✔ |
|
|
|
|
|
|
|
✔ |
|
|
|
|
|
|
|
|
|
|
|
✔ |
|
✖ |
|
|
|
|
|
✔ |
|
✖ |
|
|
|
|
|
✔3.3 |
|
✖ |
|
|
|
|
|
✔ |
|
✖ |
|
✔ |
|
|
|
|
|
|
|
|
|
|
|
✔3.3 |
|
✖ |
|
|
|
|
|
✔ |
|
✖ |
|
|
|
|
|
✔ |
|
✖ |
|
|
|
|
|
|
✔7.1 |
|
|
|
|
|
|
✔7.1 |
|
✔7.1 |
|
|
|
|
✔3.1 |
|
|
|
|
|
✔3.3 |
|
|
|
|
|
|
|
|
|
✔3.1 |
|
|
|
|
|
✔3.3 |
|
|
|
|
|
|
|
|
|
✔3.1 |
|
|
|
|
|
✔3.3 |
|
|
|
|
|
|
|
|
|
✔3.1 |
|
|
|
|
|
✔3.3 |
|
|
|
|
|
|
|
|
|
✔3.1 |
|
|
|
|
|
✔3.3 |
|
|
|
|
|
|
|
|
|
|
|
|
✔ |
|
|
|
|
|
|
|
✔ |
|
|
|
|
|
|
|
|
✔ |
|
|
|
|
|
|
|
|
✔7.1 |
|
|
|
|
|
|
|
|
✔7.1 |
|
|
|
|
|
|
|
|
✔7.1 |
Annotations du mécanisme
-
[1] Opérations à une seule partie uniquement.
-
[2] Le mécanisme est fonctionnellement identique au mécanisme
CKM_RSA_PKCS_KEY_PAIR_GEN, mais offre de meilleures garanties pour la génération depetq. [3.1] AWS CloudHSM aborde le hachage différemment en fonction du SDK client. Pour le SDK client 3, l'endroit où nous effectuons le hachage dépend de la taille des données et du fait que vous utilisez des opérations en une ou plusieurs parties.
Opérations en une seule partie dans le SDK client 3
Le tableau 3.1 répertorie la taille maximale de l'ensemble de données pour chaque mécanisme du SDK client 3. Le hachage complet est calculé dans le HSM. Aucune prise en charge pour les tailles de données supérieures à 16 Ko.
Tableau 3.1, Taille maximale de l'ensemble de données pour les opérations en une seule partie Mécanisme Taille maximale des données CKM_SHA_116296 CKM_SHA22416264 CKM_SHA25616296 CKM_SHA38416232 CKM_SHA51216232 SDK client 3 pour les opérations en plusieurs parties
Prise en charge pour les tailles de données supérieures à 16 Ko, mais la taille des données détermine l'endroit où le hachage a lieu. Les tampons de données de moins de 16 Ko sont hachés dans le HSM. Les tampons compris entre 16 Ko et la taille de données maximale de votre système sont hachés localement dans le logiciel. N'oubliez pas : les fonctions de hachage ne nécessitent pas de secrets cryptographiques, vous pouvez donc les calculer en toute sécurité en dehors du HSM.
[3.2] AWS CloudHSM aborde le hachage différemment en fonction du SDK client. Pour le SDK client 3, l'endroit où nous effectuons le hachage dépend de la taille des données et du fait que vous utilisez des opérations en une ou plusieurs parties.
SDK client 3 pour les opérations en une seule partie
Le tableau 3.2 répertorie la taille maximale de l'ensemble de données pour chaque mécanisme du SDK client 3. Aucune prise en charge pour les tailles de données supérieures à 16 Ko.
Tableau 3.2, Taille maximale de l'ensemble de données pour les opérations en une seule partie Mécanisme Taille maximale des données CKM_SHA1_RSA_PKCS16296 CKM_SHA224_RSA_PKCS16264 CKM_SHA256_RSA_PKCS16296 CKM_SHA384_RSA_PKCS16232 CKM_SHA512_RSA_PKCS16232 CKM_SHA1_RSA_PKCS_PSS16296 CKM_SHA224_RSA_PKCS_PSS16264 CKM_SHA256_RSA_PKCS_PSS16296 CKM_SHA384_RSA_PKCS_PSS16232 CKM_SHA512_RSA_PKCS_PSS16232 CKM_ECDSA_SHA116296 CKM_ECDSA_SHA22416264 CKM_ECDSA_SHA25616296 CKM_ECDSA_SHA38416232 CKM_ECDSA_SHA51216232 SDK client 3 pour les opérations en plusieurs parties
Prise en charge pour les tailles de données supérieures à 16 Ko, mais la taille des données détermine l'endroit où le hachage a lieu. Les tampons de données de moins de 16 Ko sont hachés dans le HSM. Les tampons compris entre 16 Ko et la taille de données maximale de votre système sont hachés localement dans le logiciel. N'oubliez pas : les fonctions de hachage ne nécessitent pas de secrets cryptographiques, vous pouvez donc les calculer en toute sécurité en dehors du HSM.
[3.3] Lors de l’utilisation de données avec l’un des mécanismes suivants, si la mémoire tampon des données dépasse la taille maximale des données, l’opération génère une erreur. Pour ces mécanismes, tout le traitement des données doit avoir lieu à l'intérieur du HSM. Le tableau suivant répertorie la taille maximale des données définie pour chaque mécanisme :
Tableau 3.3, Taille maximale de l'ensemble de données Mécanisme Taille maximale des données CKM_SHA_1_HMAC16288 CKM_SHA224_HMAC16256 CKM_SHA256_HMAC16288 CKM_SHA384_HMAC16224 CKM_SHA512_HMAC16224 CKM_AES_CBC16272 CKM_AES_GCM16224 CKM_CLOUDHSM_AES_GCM16224 CKM_DES3_CBC16280 [4] Lorsque vous procédez au chiffrement AES GCM, le HSM n'accepte pas de données du vecteur d'initialisation (VI) de l'application. Vous devez utiliser un vecteur d’initialisation qu’il génère. Le vecteur d'initialisation 12 octets fourni par le HSM est écrit dans la référence en mémoire vers lequel pointe l'élément pIV des paramètres
CK_GCM_PARAMSde la structure que vous fournissez. Pour éviter toute confusion de l'utilisateur, le kit SDK PKCS#11 version 1.1.1 et ultérieure s’assure que cet élément pIV pointe vers une mémoire tampon mise à zéro lorsque le chiffrement AES-GCM est initialisé.-
[5] SDK client 3 uniquement. Ce mécanisme est mis en œuvre pour prendre en charge des cas de transfert de charge SSL/TLS et est exécuté uniquement partiellement dans le HSM. Avant d'utiliser ce mécanisme, consultez « Problème : La dérivation de clés ECDH est exécutée uniquement partiellement dans le HSM » dans Problèmes connus relatifs à la bibliothèque PKCS #11 pour AWS CloudHSM.
CKM_ECDH1_DERIVEne prend pas en charge la courbe secp521r1 (P-521). [6] Les
CK_MECHANISM_TYPEetCK_RSA_PKCS_MGF_TYPEsuivants sont pris en charge en tant queCK_RSA_PKCS_OAEP_PARAMSpourCKM_RSA_PKCS_OAEP:-
CKM_SHA_1utilisantCKG_MGF1_SHA1 -
CKM_SHA224utilisantCKG_MGF1_SHA224 -
CKM_SHA256utilisantCKG_MGF1_SHA256 -
CKM_SHA384utilisantCKM_MGF1_SHA384 -
CKM_SHA512utilisantCKM_MGF1_SHA512
-
[7.1] Mécanisme défini par le fournisseur. Afin d'utiliser les mécanismes définis par le fournisseur CloudHSM, les applications PKCS #11 doivent inclure
/opt/cloudhsm/include/pkcs11t.hlors de la compilation.CKM_CLOUDHSM_AES_GCM: Ce mécanisme propriétaire est une alternative plus sûre par programme à la normeCKM_AES_GCM. Il ajoute le IV généré par le HSM au chiffrement au lieu de l'écrire dans la structureCK_GCM_PARAMSfournie lors de l'initialisation du chiffrement. Vous pouvez utiliser ce mécanisme avec les fonctionsC_Encrypt,C_WrapKey,C_DecryptetC_UnwrapKey. Lors de l'utilisation de ce mécanisme, la variable PiV dans la structureCK_GCM_PARAMSdoit être définie surNULL. Lors de l'utilisation de ce mécanisme avecC_DecryptetC_UnwrapKey, le IV doit être ajouté au texte chiffré qui est en cours de désencapsulage.CKM_CLOUDHSM_AES_KEY_WRAP_PKCS5_PAD: Encapsulage des clés AES avec remplissage PKCS #5CKM_CLOUDHSM_AES_KEY_WRAP_ZERO_PAD: Encapsulage des clés AES avec remplissage à l'aide de zérosPour plus d'informations sur l'encapsulage de clé AES, voir Encapsulage de clé AES.
[8] Conformément aux directives du NIST, cela n'est pas autorisé pour les clusters en mode FIPS après 2023. Pour les clusters en mode non FIPS, cela est toujours autorisé après 2023. Consultez Conformité à la norme FIPS 140 : mécanisme 2024 rendu obsolète pour plus de détails.
