Spécifications de clés asymétriques - AWS Key Management Service

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.

Spécifications de clés asymétriques

Les rubriques suivantes fournissent des informations techniques sur les spécifications de clés prises en charge par AWS KMS pour les clés KMS asymétriques. Des informations sur les spécifications de clé SYMMETRIC_DEFAULT pour les clés de chiffrement symétriques sont incluses à des fins de comparaison.

Spécifications de clés RSA

Lorsque vous utilisez une spécification de clé RSA, AWS KMS crée une clé KMS asymétrique avec une paire de clés RSA. La clé privée ne quitte jamais AWS KMS non chiffrée. Vous pouvez utiliser la clé publique dans AWS KMS, ou la télécharger pour l'utiliser en dehors de AWS KMS.

Avertissement

Lorsque vous chiffrez des données en dehors de AWS KMS, assurez-vous de pouvoir déchiffrer votre texte chiffré. Si vous utilisez la clé publique d'une clé KMS qui a été supprimée de AWS KMS, la clé publique d'une clé KMS configurée pour la signature et la vérification, ou un algorithme de chiffrement qui n'est pas pris en charge par la clé KMS, les données seront irrécupérables.

Dans AWS KMS, vous pouvez utiliser des clés KMS asymétriques avec des paires de clés RSA pour le chiffrement et le déchiffrement, ou la signature et la vérification, mais pas les deux. Cette propriété, appelée Key usage (utilisation de la clé), est déterminée en marge des spécifications de la clé, mais vous devez prendre cette décision avant de sélectionner une spécification de clé.

AWS KMS prend en charge les spécifications de clé RSA suivantes pour le chiffrement et le déchiffrement ou la signature et la vérification :

  • RSA_2048

  • RSA_3072

  • RSA_4096

Les spécifications des clés RSA diffèrent par la longueur de la clé RSA en bits. La spécification de la clé RSA que vous choisissez peut être déterminée par vos normes de sécurité ou les exigences de votre tâche. En général, utilisez la plus grande clé qui est pratique et abordable pour votre tâche. Les opérations de chiffrement sur des clés KMS dont les spécifications de clés RSA sont différentes sont soumises à des tarifs différents. Pour de plus amples informations sur la tarification AWS KMS, veuillez consulter Tarification du service de gestion des clés AWS. Pour de plus amples informations sur les quotas de demande, veuillez consulter Quotas de demande.

Spécifications des clés RSA pour le chiffrement et le déchiffrement

Lorsqu'une clé KMS asymétrique RSA est utilisée pour le chiffrement et le déchiffrement, vous chiffrez avec la clé publique et déchiffrez avec la clé privée. Lorsque vous appelez l'opération Encrypt dans AWS KMS pour une clé KMS RSA, AWS KMS utilisez la clé publique dans la paire de clés RSA et l'algorithme de chiffrement que vous spécifiez pour chiffrer vos données. Pour déchiffrer le texte chiffré, appelez l'opération Decrypt et spécifiez les mêmes clés KMS et algorithme de chiffrement. AWS KMS utilise ensuite la clé privée dans la paire de clés RSA pour déchiffrer vos données.

Vous pouvez également télécharger la clé publique et l'utiliser pour chiffrer les données en dehors de AWS KMS. Assurez-vous d'utiliser un algorithme de chiffrement prenant AWS KMS en charge les clés KMS RSA. Pour déchiffrer le texte chiffré, appelez la fonction Decrypt avec les mêmes clé KMS et algorithme de chiffrement.

AWS KMS prend en charge deux algorithmes de chiffrement pour les clés KMS avec des spécifications de clé RSA. Ces algorithmes, définis dans PKCS #1 v2.2, diffèrent par la fonction de hachage qu'ils utilisent en interne. Dans AWS KMS, les algorithmes RSAES_OAEP utilisent toujours la même fonction de hachage à des fins de hachage et pour la fonction de génération de masque (MGF1). Vous devez spécifier un algorithme de chiffrement lorsque vous appelez les opérations Encrypt (Chiffrer) et Decrypt (Déchiffrer). Vous pouvez choisir un algorithme différent pour chaque requête.

Algorithmes de chiffrement pris en charge pour les spécifications de clé RSA
Algorithme de chiffrement Description de l'algorithme
RSAES_OAEP_SHA_1 PKCS #1 v2.2, section 7.1. Chiffrement RSA avec remplissage OAEP utilisant SHA-1 pour le hachage et dans la fonction de génération de masque MGF1 avec une étiquette vide.
RSAES_OAEP_SHA_256 PKCS #1, section 7.1. Chiffrement RSA avec remplissage OAEP utilisant SHA-256 pour le hachage et dans la fonction de génération de masque MGF1 avec une étiquette vide.

Vous ne pouvez pas configurer une clé KMS pour utiliser un algorithme de chiffrement particulier. Cependant, vous pouvez utiliser la condition kms : EncryptionAlgorithm policy pour spécifier les algorithmes de chiffrement que les principaux sont autorisés à utiliser avec la clé KMS.

Pour obtenir les algorithmes de chiffrement d'une clé KMS, consultez la configuration cryptographique de la clé KMS dans la AWS KMS console ou utilisez l'DescribeKeyopération. AWS KMSfournit également les spécifications de clé et les algorithmes de chiffrement lorsque vous téléchargez votre clé publique, que ce soit dans la AWS KMS console ou à l'aide de l'GetPublicKeyopération.

Vous pouvez choisir une spécification de clé RSA en fonction de la longueur des données en texte brut que vous pouvez chiffrer dans chaque requête. Le tableau suivant indique la taille maximale, en octets, du texte brut que vous pouvez chiffrer en un seul appel à l'opération Encrypt (chiffrer). Les valeurs diffèrent selon la spécification de la clé et l'algorithme de chiffrement. Pour comparer, vous pouvez utiliser une clé KMS de chiffrement symétrique pour chiffrer jusqu'à 4 096 octets en même temps.

Pour calculer la longueur maximale du texte brut en octets pour ces algorithmes, utilisez la formule suivante : (taille de la clé en bits /8) - (2 * longueur de hachage en bits/8) - 2. Par exemple, pour RSA_2048 avec SHA-256, la taille maximale du texte brut en octets est (2048/8) - (2 * 256/8) -2 = 190.

Taille maximale du texte brut (en octets) dans une opération de chiffrement
Algorithme de chiffrement
Spécifications de la clé RSAES_OAEP_SHA_1 RSAES_OAEP_SHA_256
RSA_2048 214 190
RSA_3072 342 318
RSA_4096 470 446

Spécifications des clés RSA pour la signature et la vérification

Lorsqu'une clé KMS asymétrique RSA est utilisée pour la signature et la vérification, vous générez la signature d'un message avec la clé privée et vérifiez une signature avec la clé publique.

Lorsque vous appelez l'opération Sign dans AWS KMS pour une clé KMS asymétrique, AWS KMS utilise la clé privée de la paire de clés RSA, le message et l'algorithme de signature que vous spécifiez pour générer une signature. Pour vérifier la signature, appelez l'opération Vérifier. Spécifiez la signature, plus la même clé KMS, message et algorithme de signature. AWS KMS utilise ensuite la clé publique dans la paire de clés RSA pour vérifier la signature. Vous pouvez également télécharger la clé publique et l'utiliser pour vérifier la signature en dehors de AWS KMS.

AWS KMS prend en charge les algorithmes de signature suivants pour toutes les clés KMS associées à une spécification RSA. Vous devez spécifier un algorithme de signature lorsque vous appelez les opérations Sign (Signer) et Verify (Vérifier). Vous pouvez choisir un algorithme différent pour chaque requête. Lors de la signature avec des paires de clés RSA, les algorithmes RSASSA-PSS sont privilégiés. Nous incluons les algorithmes RSASSA-PKCS1-v1_5 pour des raisons de compatibilité avec les applications existantes.

Algorithmes de signature pris en charge pour les spécifications de clés RSA
Algorithme de signature Description de l'algorithme
RSASSA_PSS_SHA_256 PKCS #1 v2.2, section 8.1, signature RSA avec remplissage PSS utilisant SHA-256 pour le résumé de message et la fonction de génération de masque MGF1 avec un salt de 256 bits
RSASSA_PSS_SHA_384 PKCS #1 v2.2, section 8.1, signature RSA avec remplissage PSS utilisant SHA-384 pour le résumé des messages et la fonction de génération de masque MGF1 avec un salt de 384 bits
RSASSA_PSS_SHA_512 PKCS #1 v2.2, section 8.1, signature RSA avec remplissage PSS utilisant SHA-512 pour le résumé des messages et la fonction de génération de masque MGF1 avec un salt de 512 bits
RSASSA_PKCS1_V1_5_SHA_256 PKCS #1 v2.2, section 8.2, signature RSA avec remplissage PKCS #1v1.5 et SHA-256
RSASSA_PKCS1_V1_5_SHA_384 PKCS #1 v2.2, section 8.2, signature RSA avec remplissage PKCS #1v1.5 et SHA-384
RSASSA_PKCS1_V1_5_SHA_512 PKCS #1 v2.2, section 8.2, signature RSA avec remplissage PKCS #1v1.5 et SHA-512

Vous ne pouvez pas configurer une clé KMS pour utiliser des algorithmes de signature particuliers. Cependant, vous pouvez utiliser la condition kms : SigningAlgorithm policy pour spécifier les algorithmes de signature que les principaux sont autorisés à utiliser avec la clé KMS.

Pour obtenir les algorithmes de signature d'une clé KMS, consultez la configuration cryptographique de la clé KMS dans la AWS KMS console ou en utilisant l'DescribeKeyopération. AWS KMSfournit également les spécifications clés et les algorithmes de signature lorsque vous téléchargez votre clé publique, soit dans la AWS KMS console, soit à l'aide de l'GetPublicKeyopération.

Spécifications de la clé de courbe elliptique

Lorsque vous utilisez une spécification de clé de courbe elliptique (ECC), AWS KMS crée une clé KMS asymétrique avec une paire de clés ECC pour la signature et la vérification. La clé privée qui génère la signature ne quitte jamais AWS KMS non chiffrée. Vous pouvez utiliser la clé publique pour vérifier les signatures dans AWS KMS, ou télécharger la clé publique pour l'utiliser en dehors de AWS KMS.

AWS KMS prend en charge les spécifications de clés ECC suivantes pour les clés KMS asymétriques.

  • Paires de clés asymétriques de courbe elliptique recommandées par NIST (signature et vérification)

    • ECC_NIST_P256 (secp256r1)

    • ECC_NIST_P384 (secp384r1)

    • ECC_NIST_P521 (secp521r1)

  • Autres paires de clés asymétriques de courbe elliptique (signature et vérification)

    • ECC_SECG_P256K1 (secp256k1), couramment utilisé pour les crypto-monnaies.

La spécification de clé ECC que vous choisissez peut être déterminée par vos normes de sécurité ou les exigences de votre tâche. En général, utilisez la courbe qui est la plus pratique et abordable pour votre tâche.

Si vous créez une clé KMS asymétrique à utiliser avec les crypto-monnaies, utilisez la spécification de clé ECC_SECG_P256K1. Vous pouvez également utiliser cette spécification de clé à d'autres fins, mais elle est nécessaire pour Bitcoin et d'autres crypto-monnaies.

Les clés KMS avec des spécifications de clés ECC différentes sont tarifées différemment et sont soumises à des quotas de demande différents. Pour plus d'informations sur la tarification AWS KMS, consultez Tarification AWS Key Management Service. Pour de plus amples informations sur les quotas de demande, veuillez consulter Quotas de demande.

Le tableau suivant présente les algorithmes de signature que AWS KMS prend en charge pour chacune des spécifications de clés ECC. Vous ne pouvez pas configurer une clé KMS pour utiliser des algorithmes de signature particuliers. Cependant, vous pouvez utiliser la condition kms : SigningAlgorithm policy pour spécifier les algorithmes de signature que les principaux sont autorisés à utiliser avec la clé KMS.

Algorithmes de signature pris en charge pour les spécifications de clés ECC
Spécifications de la clé Algorithme de signature Description de l'algorithme
ECC_NIST_P256 ECDSA_SHA_256 NIST FIPS 186-4, section 6.4, signature ECDSA utilisant la courbe spécifiée par la clé et SHA-256 pour le résumé du message.
ECC_NIST_P384 ECDSA_SHA_384 NIST FIPS 186-4, section 6.4, signature ECDSA utilisant la courbe spécifiée par la clé et SHA-384 pour le résumé du message.
ECC_NIST_P521 ECDSA_SHA_512 NIST FIPS 186-4, section 6.4, signature ECDSA utilisant la courbe spécifiée par la clé et SHA-512 pour le résumé du message.
ECC_SECG_P256K1 ECDSA_SHA_256 NIST FIPS 186-4, section 6.4, signature ECDSA utilisant la courbe spécifiée par la clé et SHA-256 pour le résumé du message.

Spécifications de la clé SM2 (régions de Chine uniquement)

La spécification clé SM2 est une spécification clé de courbe elliptique définie dans la série de spécifications GM/T publiée par le Bureau de l'administration chinoise de la cryptographie commerciale (OSCCA). La spécification de clé SM2 est disponible uniquement dans les régions de Chine. Lorsque vous utilisez une spécification de clé SM2, AWS KMS crée une clé KMS asymétrique avec une paire de clés SM2. Vous pouvez utiliser votre clé SM2 dans AWS KMS, ou télécharger la clé publique pour l'utiliser en dehors de AWS KMS.

Contrairement à la spécification de clé ECC, vous pouvez utiliser une clé SM2 KMS pour la signature et la vérification,ou le chiffrement et le déchiffrement. Vous devez spécifier l’utilisation de la clé lorsque vous créez la clé KMS, et vous ne pouvez pas la modifier une fois la clé créée.

AWS KMSprend en charge les algorithmes de cryptage et de signature SM2 suivants :

  • Algorithme de chiffrement SM2PKE

    SM2PKE est un algorithme de chiffrement basé sur une courbe elliptique définie par OSCCA dans GM/T 0003.4-2012.

  • Algorithme de signature SM2DSA

    SM2DSA est un algorithme de signature basé sur une courbe elliptique définie par OSCCA dans GM/T 0003.2-2012. SM2DSA nécessite un ID distinctif qui est haché avec l'algorithme de hachage SM3, puis combiné avec le message, ou résumé de message, que vous avez transmis àAWS KMS. Cette valeur concaténée est ensuite hachée et signée parAWS KMS.

Opérations hors ligne avec SM2 (régions de Chine uniquement)

Vous pouvez télécharger la clé publique de votre paire de clés SM2 pour une utilisation dans des opérations hors ligne, c'est-à-dire des opérations en dehors de AWS KMS. Toutefois, lorsque vous utiliserez votre clé publique SM2 hors ligne, vous devrez peut-être effectuer manuellement des conversions et des calculs supplémentaires. Les opérations SM2DSA peuvent vous obliger à fournir un ID distinctif ou à calculer un résumé de message. Les opérations de chiffrement SM2PKE peuvent vous obliger à convertir le texte chiffré brut en un format que AWS KMS peut accepter.

Pour vous aider dans ces opérations, la classe de SM2OfflineOperationHelper pour Java possède des méthodes qui exécutent les tâches à votre place. Vous pouvez utiliser cette classe d'assistance comme modèle pour d'autres fournisseurs de cryptographie.

Important

Le SM2OfflineOperationHelper code de référence est conçu pour être compatible avec Bouncy Castle version 1.68. Pour obtenir de l'aide sur les autres versions, contactezbouncycastle.org.

Vérification hors ligne avec des paires de clés SM2 (régions de Chine uniquement)

Pour vérifier une signature en dehors de AWS KMS avec une clé publique SM2, vous devez spécifier l'ID distinctif. Lorsque vous transmettez un message brut,MessageType:RAW, au signataire API,AWS KMSutilise l'identifiant distinctif par défaut,1234567812345678, défini par l'OSCCA dans GM/T 0009-2012. Vous ne pouvez pas spécifier votre propre ID distinctif dans AWS KMS.

Toutefois, si vous générez un résumé de message en dehors de AWS, vous pouvez spécifier votre propre ID distinctif, puis transmettre le résumé du message,MessageType:DIGEST, à AWS KMS pour signer. Pour ce faire, modifiez le paramètre DEFAULT_DISTINGUISHING_ID valeur dans la clé SM2OfflineOperationHelper classe. L'ID distinctif que vous spécifiez peut être n'importe quelle chaîne de 8 192 caractères maximum. Après que AWS KMS ait signé le résumé du message, vous aurez besoin soit du résumé du message ou du message et de l'ID distinctif utilisé pour calculer le résumé afin de le vérifier hors ligne.

classe SM2OfflineOperationHelper

Au sein de AWS KMS, les conversions de texte chiffré brut et les calculs de résumé de message SM2DSA se produisent automatiquement. Tous les fournisseurs de chiffrement ne mettent pas en œuvre SM2 de la même manière. Certaines bibliothèques, comme OpenSSL versions 1.1.1 et ultérieures, effectuent ces actions automatiquement. AWS KMS a confirmé ce comportement lors de tests avec OpenSSL version 3.0. Utilisez les classes SM2OfflineOperationHelper avec des bibliothèques, comme Bouncy Castle, qui vous obligent à effectuer ces conversions et ces calculs manuellement.

La classe SM2OfflineOperationHelper fournit des méthodes pour les opérations hors ligne suivantes :

  • Calcul de l'algorithme Message Digest

    Pour générer un résumé de message hors ligne que vous pouvez utiliser pour la vérification hors ligne ou que vous pouvez transmettre à AWS KMS pour signer, utilisez la méthode calculateSM2Digest. La méthode calculateSM2Digest génère un condensé de message avec l'algorithme de hachage SM3. L'GetPublicKeyAPI renvoie votre clé publique au format binaire. Vous devez analyser la clé binaire dans un Java PublicKey. Fournissez la clé publique analysée avec le message. La méthode combine automatiquement votre message avec l'identifiant distinctif par défaut, 1234567812345678, mais vous pouvez définir votre propre ID distinctif en modifiant la valeur DEFAULT_DISTINGUISHING_ID.

  • Vérification

    Pour vérifier une signature hors ligne, utilisez la méthode offlineSM2DSAVerify. La méthode offlineSM2DSAVerify utilise le résumé du message calculé à partir de l'ID distinctif spécifié et du message d'origine que vous avez fourni pour vérifier la signature numérique. L'GetPublicKeyAPI renvoie votre clé publique au format binaire. Vous devez analyser la clé binaire dans un Java PublicKey. Fournissez la clé publique analysée avec le message d'origine et la signature que vous souhaitez vérifier. Pour plus d'informations, consultez .Vérification hors ligne avec des paires de clés SM2.

  • Chiffrement

    Pour chiffrer du texte en clair hors ligne, utilisez la méthode offlineSM2PKEEncrypt. Cette méthode garantit que le texte chiffré est au format que AWS KMS peut déchiffrer. La méthode offlineSM2PKEEncrypt crypte le texte brut, puis convertit le texte chiffré brut produit par SM2PKE au format ASN.1. L'GetPublicKeyAPI renvoie votre clé publique au format binaire. Vous devez analyser la clé binaire dans un Java PublicKey. Fournissez la clé publique analysée avec le texte brut que vous souhaitez chiffrer.

    Si vous n'êtes pas sûr(e) de devoir effectuer la conversion, utilisez l'opération OpenSSL suivante pour tester le format de votre texte chiffré. Si l'opération échoue, vous devez convertir le texte chiffré au format ASN.1.

    openssl asn1parse -inform DER -in ciphertext.der

Par défaut, la classe SM2OfflineOperationHelper utilise l'ID distinctif par défaut, 1234567812345678, lors de la génération de résumés de messages pour les opérations SM2DSA.

package com.amazon.kms.utils; import javax.crypto.BadPaddingException; import javax.crypto.Cipher; import javax.crypto.IllegalBlockSizeException; import javax.crypto.NoSuchPaddingException; import java.io.IOException; import java.math.BigInteger; import java.nio.ByteBuffer; import java.nio.charset.StandardCharsets; import java.security.InvalidKeyException; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import java.security.NoSuchProviderException; import java.security.PrivateKey; import java.security.PublicKey; import org.bouncycastle.crypto.CryptoException; import org.bouncycastle.jce.interfaces.ECPublicKey; import java.util.Arrays; import org.bouncycastle.asn1.ASN1EncodableVector; import org.bouncycastle.asn1.ASN1Integer; import org.bouncycastle.asn1.DEROctetString; import org.bouncycastle.asn1.DERSequence; import org.bouncycastle.asn1.gm.GMNamedCurves; import org.bouncycastle.asn1.x9.X9ECParameters; import org.bouncycastle.crypto.CipherParameters; import org.bouncycastle.crypto.params.ParametersWithID; import org.bouncycastle.crypto.params.ParametersWithRandom; import org.bouncycastle.crypto.signers.SM2Signer; import org.bouncycastle.jcajce.provider.asymmetric.util.ECUtil; public class SM2OfflineOperationHelper { // You can change the DEFAULT_DISTINGUISHING_ID value to set your own distinguishing ID, // the DEFAULT_DISTINGUISHING_ID can be any string up to 8,192 characters long. private static final byte[] DEFAULT_DISTINGUISHING_ID = "1234567812345678".getBytes(StandardCharsets.UTF_8); private static final X9ECParameters SM2_X9EC_PARAMETERS = GMNamedCurves.getByName("sm2p256v1"); // ***calculateSM2Digest*** // Calculate message digest public static byte[] calculateSM2Digest(final PublicKey publicKey, final byte[] message) throws NoSuchProviderException, NoSuchAlgorithmException { final ECPublicKey ecPublicKey = (ECPublicKey) publicKey; // Generate SM3 hash of default distinguishing ID, 1234567812345678 final int entlenA = DEFAULT_DISTINGUISHING_ID.length * 8; final byte [] entla = new byte[] { (byte) (entlenA & 0xFF00), (byte) (entlenA & 0x00FF) }; final byte [] a = SM2_X9EC_PARAMETERS.getCurve().getA().getEncoded(); final byte [] b = SM2_X9EC_PARAMETERS.getCurve().getB().getEncoded(); final byte [] xg = SM2_X9EC_PARAMETERS.getG().getXCoord().getEncoded(); final byte [] yg = SM2_X9EC_PARAMETERS.getG().getYCoord().getEncoded(); final byte[] xa = ecPublicKey.getQ().getXCoord().getEncoded(); final byte[] ya = ecPublicKey.getQ().getYCoord().getEncoded(); final byte[] za = MessageDigest.getInstance("SM3", "BC") .digest(ByteBuffer.allocate(entla.length + DEFAULT_DISTINGUISHING_ID.length + a.length + b.length + xg.length + yg.length + xa.length + ya.length).put(entla).put(DEFAULT_DISTINGUISHING_ID).put(a).put(b).put(xg).put(yg).put(xa).put(ya) .array()); // Combine hashed distinguishing ID with original message to generate final digest return MessageDigest.getInstance("SM3", "BC") .digest(ByteBuffer.allocate(za.length + message.length).put(za).put(message) .array()); } // ***offlineSM2DSAVerify*** // Verify digital signature with SM2 public key public static boolean offlineSM2DSAVerify(final PublicKey publicKey, final byte [] message, final byte [] signature) throws InvalidKeyException { final SM2Signer signer = new SM2Signer(); CipherParameters cipherParameters = ECUtil.generatePublicKeyParameter(publicKey); cipherParameters = new ParametersWithID(cipherParameters, DEFAULT_DISTINGUISHING_ID); signer.init(false, cipherParameters); signer.update(message, 0, message.length); return signer.verifySignature(signature); } // ***offlineSM2PKEEncrypt*** // Encrypt data with SM2 public key public static byte[] offlineSM2PKEEncrypt(final PublicKey publicKey, final byte [] plaintext) throws NoSuchPaddingException, NoSuchAlgorithmException, NoSuchProviderException, InvalidKeyException, BadPaddingException, IllegalBlockSizeException, IOException { final Cipher sm2Cipher = Cipher.getInstance("SM2", "BC"); sm2Cipher.init(Cipher.ENCRYPT_MODE, publicKey); // By default, Bouncy Castle returns raw ciphertext in the c1c2c3 format final byte [] cipherText = sm2Cipher.doFinal(plaintext); // Convert the raw ciphertext to the ASN.1 format before passing it to AWS KMS final ASN1EncodableVector asn1EncodableVector = new ASN1EncodableVector(); final int coordinateLength = (SM2_X9EC_PARAMETERS.getCurve().getFieldSize() + 7) / 8 * 2 + 1; final int sm3HashLength = 32; final int xCoordinateInCipherText = 33; final int yCoordinateInCipherText = 65; byte[] coords = new byte[coordinateLength]; byte[] sm3Hash = new byte[sm3HashLength]; byte[] remainingCipherText = new byte[cipherText.length - coordinateLength - sm3HashLength]; // Split components out of the ciphertext System.arraycopy(cipherText, 0, coords, 0, coordinateLength); System.arraycopy(cipherText, cipherText.length - sm3HashLength, sm3Hash, 0, sm3HashLength); System.arraycopy(cipherText, coordinateLength, remainingCipherText, 0,cipherText.length - coordinateLength - sm3HashLength); // Build standard SM2PKE ASN.1 ciphertext vector asn1EncodableVector.add(new ASN1Integer(new BigInteger(1, Arrays.copyOfRange(coords, 1, xCoordinateInCipherText)))); asn1EncodableVector.add(new ASN1Integer(new BigInteger(1, Arrays.copyOfRange(coords, xCoordinateInCipherText, yCoordinateInCipherText)))); asn1EncodableVector.add(new DEROctetString(sm3Hash)); asn1EncodableVector.add(new DEROctetString(remainingCipherText)); return new DERSequence(asn1EncodableVector).getEncoded("DER"); } }

Spécification de clé SYMMETRIC_DEFAULT

La spécification de clé par défaut, SYMMETRIC_DEFAULT, est la spécification de clé pour les clés KMS de chiffrement symétriques. Lorsque vous sélectionnez le type de clé Symmetric (Symétrique) et l'utilisation de clé Encrypt and decrypt (Chiffrer et déchiffrer) dans la console AWS KMS, cela sélectionne la spécification de clé SYMMETRIC_DEFAULT. Dans l'CreateKeyopération, si vous ne spécifiez aucune KeySpec valeur, SYMMETRIC_DEFAULT est sélectionné. Si vous n'avez pas de raison d'utiliser une spécification de clé différente, SYMMETRIC_DEFAULT est un bon choix.

SYMMETRIC_DEFAULT représente actuellement AES-256-GCM, un algorithme symétrique basé sur Advanced Encryption Standard (AES) en mode compteur Galois (GCM) avec des clés de 256 bits, une norme du secteur pour le chiffrement sécurisé. Le texte chiffré généré par cet algorithme prend en charge les données authentifiées supplémentaires (AAD), telles qu'un contexte de chiffrement et GCM fournit une vérification d'intégrité supplémentaire sur le texte chiffré. Pour plus d'informations techniques, veuillez consulter Détails cryptographiques AWS Key Management Service.

Les données chiffrées sous AES-256-GCM sont protégées maintenant et à l'avenir. Les cryptographes considèrent cet algorithme comme résistant quantique. Dans un avenir théorique, les attaques de calcul quantique à grande échelle sur les textes chiffrés créés sous les clés AES-GCM 256 bits réduiront la sécurité effective de la clé à 128 bits. Mais ce niveau de sécurité sera suffisant pour rendre les attaques de force brute sur les textes chiffrés AWS KMS irréalisables.

Les régions de Chine sont la seule exception, où SYMMETRIC_DEFAULT représente une clé symétrique de 128 bits qui utilise le chiffrement SM4. Vous ne pouvez créer une clé SM4 128 bits que dans les régions de Chine. Vous ne pouvez pas créer une clé AES-GCM KMS AES-GCM 256 bits dans les régions de Chine.

Vous pouvez utiliser une clé KMS de chiffrement symétrique dans AWS KMS pour chiffrer, déchiffrer et chiffrer à nouveau des données, et protéger les clés de données et paires de clés de données générées. Les services AWS qui sont intégrés à AWS KMS utilisent des clés KMS de chiffrement symétriques pour chiffrer vos données au repos. Vous pouvez importer vos propres éléments de clé dans une clé KMS de chiffrement symétrique et créer des clés KMS de chiffrement symétriques dans des magasins de clés personnalisés. Pour obtenir un tableau comparant les opérations que vous pouvez effectuer sur les clés KMS symétriques et asymétriques, veuillez consulter la Comparaison des clés KMS symétriques et asymétriques.

Pour plus de détails techniques sur AWS KMS et les clés de chiffrement symétriques, consultez AWS Key Management ServiceDétails cryptographiques.