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 sort jamais AWS KMS non chiffrée. Vous pouvez utiliser la clé publique contenue dans le AWS KMS fichier ou télécharger la clé publique pour une utilisation en dehors de celui-ci 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 pour 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 clés RSA suivantes pour le chiffrement et le déchiffrement ou pour 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 plus d'informations sur la AWS KMS tarification, consultez la section Tarification des services de gestion des AWS clés. 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'Encryptopération AWS KMS pour obtenir une clé RSA KMS, AWS KMS utilise la clé publique de 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'Decryptopération et spécifiez la même clé KMS et le même algorithme de chiffrement. AWS KMS utilise ensuite la clé privée de 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 des données en dehors de AWS KMS. Veillez à utiliser un algorithme de chiffrement AWS KMS compatible avec les clés RSA KMS. 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 KMS fournit également les spécifications de clé et les algorithmes de chiffrement lorsque vous téléchargez votre clé publique, soit dans la AWS KMS console, soit à 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'Signopération 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, ainsi que la même clé KMS, le même message et le même algorithme de signature. AWS KMS utilise ensuite la clé publique de 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 avec une spécification de clé 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 KMS fournit é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é à courbe elliptique (ECC), vous AWS KMS créez une clé KMS asymétrique avec une paire de clés ECC pour la signature et la vérification ou pour obtenir des secrets partagés (mais pas les deux). La clé privée qui génère des signatures ou déduit des secrets partagés n'est jamais AWS KMS déchiffrée. Vous pouvez utiliser la clé publique pour vérifier les signatures internes AWS KMS ou télécharger la clé publique pour une utilisation en dehors de AWS KMS.

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

• Paires de clés asymétriques à courbe elliptique recommandées par le NIST (signature et vérification, ou obtention de secrets partagés)

  • 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 pour obtenir des secrets partagés, utilisez l'une des spécifications de clé à courbe elliptique recommandées par le NIST. Le seul algorithme d'accord de clés pris en charge pour dériver des secrets partagés est le cofacteur Diffie-Hellman (Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive).

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 AWS KMS tarification, consultez la section AWS Key Management Service Tarification. Pour de plus amples informations sur les quotas de demande, veuillez consulter Quotas de demande.

Le tableau suivant présente les algorithmes de signature compatibles AWS KMS avec chacune des spécifications clés de l'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.

Découverte de secrets partagés hors ligne

Vous pouvez télécharger la clé publique de votre paire de clés ECC pour l'utiliser dans des opérations hors ligne, c'est-à-dire des opérations en dehors de AWS KMS.

La procédure pas à pas suivante montre une méthode permettant de dériver un secret partagé en dehors de l'utilisation de la clé publique d'une paire AWS KMS de clés ECC KMS et d'une clé privée créée avec OpenSSL.

1. Créez une paire de clés ECC dans OpenSSL et préparez-la pour une utilisation avec. AWS KMS

   // Create an ECC key pair in OpenSSL and save the private key in openssl_ecc_key_priv.pem
   export OPENSSL_CURVE_NAME="P-256"
   export KMS_CURVE_NAME="ECC_NIST_P256"
   
   export OPENSSL_KEY1_PRIV_PEM="openssl_ecc_key1_priv.pem"
   openssl ecparam -name ${OPENSSL_CURVE_NAME} -genkey -out ${OPENSSL_KEY1_PRIV_PEM}                    
                       
   // Derive the public key from the private key                    
   export OPENSSL_KEY1_PUB_PEM="openssl_ecc_key1_pub.pem"
   openssl ec -in ${OPENSSL_KEY1_PRIV_PEM} -pubout -outform pem \
       -out ${OPENSSL_KEY1_PUB_PEM}                    
                       
   // View the PEM file containing the public key and extract the public key as a 
   // Base64 encoded string into OPENSSL_KEY1_PUB_BASE64 for use with AWS KMS
   export OPENSSL_KEY1_PUB_BASE64=`cat ${OPENSSL_KEY1_PUB_PEM} | \
       tee /dev/stderr | grep -v "PUBLIC KEY" | tr -d "\n"`

2. Créez une paire de clés d'accord de clés ECC AWS KMS et préparez-la pour une utilisation avec OpenSSL.

   // Create a KMS key on the same curve as the key pair from step 1 
   // with a key usage of KEY_AGREEMENT
   // Save its ARN in KMS_KEY1_ARN.
   export KMS_KEY1_ARN=`aws kms create-key --key-spec ${KMS_CURVE_NAME} \
       --key-usage KEY_AGREEMENT | tee /dev/stderr | jq -r .KeyMetadata.Arn`
   
   // Download the public key and save the Base64-encoded version in KMS_KEY1_PUB_BASE64        
   export KMS_KEY1_PUB_BASE64=`aws kms get-public-key --key-id ${KMS_KEY1_ARN} | \
       tee /dev/stderr | jq -r .PublicKey`                    
                       
   // Create a PEM file for the public KMS key for use with OpenSSL   
   export KMS_KEY1_PUB_PEM="aws_kms_ecdh_key1_pub.pem"
   echo "-----BEGIN PUBLIC KEY-----" > ${KMS_KEY1_PUB_PEM}
   echo ${KMS_KEY1_PUB_BASE64} | fold -w 64 >> ${KMS_KEY1_PUB_PEM}
   echo "-----END PUBLIC KEY-----" >> ${KMS_KEY1_PUB_PEM}

3. Déterminez le secret partagé dans OpenSSL à l'aide de la clé privée d'OpenSSL et de la clé KMS publique.

   export OPENSSL_SHARED_SECRET1_BIN="openssl_shared_secret1.bin"
   openssl pkeyutl -derive -inkey ${OPENSSL_KEY1_PRIV_PEM} \
       -peerkey ${KMS_KEY1_PUB_PEM} -out ${OPENSSL_SHARED_SECRET1_BIN}

Afficher plusAfficher moins

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 la 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 paire de clés SM2 à l'intérieur AWS KMS ou télécharger la clé publique pour une utilisation en dehors de AWS KMS.

Chaque clé KMS ne peut avoir qu'un seul type d'utilisation de clé. Vous pouvez utiliser une clé KMS SM2 pour la signature et la vérification, le chiffrement et le déchiffrement, ou pour obtenir des secrets partagés. 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.

Si vous créez une clé KMS asymétrique pour obtenir des secrets partagés, utilisez la spécification de clé SM2. Le seul algorithme d'accord de clés pris en charge pour dériver des secrets partagés est le cofacteur Diffie-Hellman (Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive).

AWS KMS prend en charge les algorithmes de chiffrement 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 identifiant distinctif haché à l'aide de l'algorithme de hachage SM3, puis combiné avec le message, ou le résumé du message, auquel vous avez transmis le message. AWS KMS Cette valeur concaténée est ensuite hachée et signée par. AWS 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 sortie dans un format acceptable. AWS KMS

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 extérieure à l' AWS KMS aide d'une clé publique SM2, vous devez spécifier l'identifiant distinctif. Lorsque vous transmettez un message brut à l'API Sign MessageType:RAW, il AWS KMS utilise l'identifiant distinctif par défaut1234567812345678, défini par l'OSCA 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 identifiant distinctif, puis transmettre le résumé du message, AWS KMS à MessageType:DIGEST, pour le 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 avoir AWS KMS signé le résumé du message, vous avez besoin soit du résumé du message, soit du message et de l'ID distinctif utilisés pour calculer le résumé afin de le vérifier hors ligne.

classe SM2OfflineOperationHelper

Dans AWS KMS ce cadre, les conversions de texte chiffré brut et les calculs du résumé des messages SM2DSA sont effectués automatiquement. Tous les fournisseurs de chiffrement ne mettent pas en œuvre SM2 de la même manière. Certaines bibliothèques, comme les versions 1.1.1 et ultérieures d'OpenSSL, exécutent ces actions automatiquement. AWS KMS a confirmé ce comportement lors de tests avec la version 3.0 d'OpenSSL. 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 le signer, utilisez calculateSM2Digest cette méthode. 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 dans un format AWS KMS déchiffrable. 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é symétrique et l'utilisation de la clé de chiffrement et de déchiffrement dans la AWS KMS console, la spécification de la SYMMETRIC_DEFAULT clé est sélectionnée. 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é est suffisant pour empêcher les attaques par force brute sur des AWS KMS textes chiffrés.

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 AWS KMS pour chiffrer, déchiffrer et rechiffrer les données, ainsi que pour protéger les clés de données et les paires de clés de données générées. AWS les services 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 obtenir des informations techniques sur AWS KMS les clés de chiffrement symétriques, consultez la section Détails AWS Key Management Service cryptographiques.