Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Asymmetrische Schlüsselspezifikationen

Die folgenden Themen enthalten technische Informationen zu den Schlüsselspezifikationen, die AWS KMS für asymmetrische KMS-Schlüssel. Informationen zur Schlüsselspezifikation SYMMETRIC_DEFAULT für symmetrische Verschlüsselungsschlüssel sind zum Vergleich enthalten.

RSA-Schlüsselspezifikationen

Wenn Sie eine RSA-Schlüsselspezifikation verwenden, AWS KMS wird ein asymmetrischer KMS-Schlüssel mit einem RSA-Schlüsselpaar erstellt. Der private Schlüssel wird niemals unverschlüsselt verlassen. AWS KMS Sie können den öffentlichen Schlüssel innerhalb von verwenden oder den öffentlichen Schlüssel herunterladen AWS KMS, um ihn außerhalb von AWS KMS zu verwenden.

In AWS KMS können Sie asymmetrische KMS-Schlüssel mit RSA-Schlüsselpaaren für die Verschlüsselung und Entschlüsselung oder für das Signieren und Überprüfen verwenden, aber nicht beides. Diese Eigenschaft, die als Schlüsselnutzung bezeichnet wird, wird getrennt von der Schlüsselspezifikation bestimmt, aber Sie sollten diese Entscheidung treffen, bevor Sie eine Schlüsselspezifikation auswählen.

AWS KMS unterstützt die folgenden RSA-Schlüsselspezifikationen für Verschlüsselung und Entschlüsselung oder Signierung und Überprüfung:

Die RSA-Schlüsselspezifikationen unterscheiden sich in der Länge des RSA-Schlüssels in Bits. Die von Ihnen gewählte RSA-Schlüsselspezifikation hängt möglicherweise von Ihren Sicherheitsstandards oder den Anforderungen Ihrer Aufgabe ab. Verwenden Sie im Allgemeinen den größten Schlüssel, der für Ihre Aufgabe praktisch und erschwinglich ist. Kryptografische Operationen zu KMS-Schlüsseln mit unterschiedlichen RSA-Schlüsselspezifikationen haben unterschiedliche Preise. AWS KMS Preisinformationen finden Sie unter Preise für den AWS Key Management Service. Weitere Hinweise zu Anforderungskontingenten finden Sie unter Anforderungskontingente.

RSA-Schlüsselspezifikationen für Verschlüsselung und Entschlüsselung

Wenn ein asymmetrischer RSA-KMS-Schlüssel für die Verschlüsselung und Entschlüsselung verwendet wird, verschlüsseln Sie mit dem öffentlichen Schlüssel und entschlüsseln mit dem privaten Schlüssel. Wenn Sie den Encrypt Vorgang AWS KMS für einen RSA-KMS-Schlüssel aufrufen, AWS KMS verwendet den öffentlichen Schlüssel im RSA-Schlüsselpaar und den von Ihnen angegebenen Verschlüsselungsalgorithmus, um Ihre Daten zu verschlüsseln. Um den Chiffretext zu entschlüsseln, rufen Sie den Decrypt Vorgang auf und geben Sie denselben KMS-Schlüssel und denselben Verschlüsselungsalgorithmus an. AWS KMS verwendet dann den privaten Schlüssel im RSA-Schlüsselpaar, um Ihre Daten zu entschlüsseln.

Sie können den öffentlichen Schlüssel auch herunterladen und damit Daten außerhalb von verschlüsseln. AWS KMS Stellen Sie sicher, dass Sie einen Verschlüsselungsalgorithmus verwenden, der RSA-KMS-Schlüssel AWS KMS unterstützt. Um den Chiffretext zu entschlüsseln, rufen Sie die Decrypt-Funktion mit demselben KMS-Schlüssel und Verschlüsselungsalgorithmus auf.

AWS KMS unterstützt zwei Verschlüsselungsalgorithmen für KMS-Schlüssel mit RSA-Schlüsselspezifikationen. Diese Algorithmen, die in PKCS #1 v2.2, definiert sind, unterscheiden sich in der Hashfunktion, die sie intern verwenden. In AWS KMS verwenden die RSAES_OAEP-Algorithmen immer dieselbe Hashfunktion sowohl für Hashzwecke als auch für die Maskengenerierungsfunktion (MGF1). Sie müssen beim Aufruf der Operationen Encrypt und Decrypt einen Verschlüsselungsalgorithmus angeben. Sie können für jede Anforderung einen anderen Algorithmus auswählen.

Sie können einen KMS-Schlüssel nicht so konfigurieren, dass er einen bestimmten Verschlüsselungsalgorithmus verwendet. Sie können jedoch die EncryptionAlgorithm Richtlinienbedingung kms: verwenden, um die Verschlüsselungsalgorithmen anzugeben, die Prinzipale mit dem KMS-Schlüssel verwenden dürfen.

Um die Verschlüsselungsalgorithmen für einen KMS-Schlüssel abzurufen, sehen Sie sich die kryptografische Konfiguration des KMS-Schlüssels in der AWS KMS Konsole an oder verwenden Sie den DescribeKeyVorgang. AWS KMS stellt außerdem die Schlüsselspezifikation und die Verschlüsselungsalgorithmen bereit, wenn Sie Ihren öffentlichen Schlüssel entweder in der AWS KMS Konsole oder mithilfe des GetPublicKeyVorgangs herunterladen.

Sie können eine RSA-Schlüsselspezifikation basierend auf der Länge der Klartextdaten auswählen, die Sie in jeder Anforderung verschlüsseln können. Die folgende Tabelle zeigt die maximale Größe (in Byte) des Klartextes, den Sie bei einem einzelnen Aufruf der Produktion Encrypt verschlüsseln können. Die Werte unterscheiden sich je nach Schlüsselspezifikation und Verschlüsselungsalgorithmus. Zum Vergleich können Sie einen KMS-Schlüssel mit symmetrischer Verschlüsselung verwenden, um bis zu 4096 Bytes gleichzeitig zu verschlüsseln.

Um die maximale Klartextlänge in Bytes für diese Algorithmen zu berechnen, verwenden Sie die folgende Formel: (Schlüsselgröße_in_Bits /8) - (2 * Hashlänge_in_Bits/8) - 2. Für RSA_2048 mit SHA-256 beträgt beispielsweise die maximale Klartextgröße in Bytes (2048/8) - (2 * 256/8) -2 = 190.

RSA-Schlüsselspezifikationen für Signatur und Verifizierung

Wenn ein asymmetrischer RSA-KMS-Schlüssel für Signatur und Verifizierung verwendet wird, generieren Sie die Signatur für eine Nachricht mit dem privaten Schlüssel und überprüfen die Signatur mit dem öffentlichen Schlüssel.

Wenn Sie den Sign Vorgang AWS KMS für einen asymmetrischen KMS-Schlüssel aufrufen, AWS KMS verwendet den privaten Schlüssel im RSA-Schlüsselpaar, die Nachricht und den von Ihnen angegebenen Signaturalgorithmus, um eine Signatur zu generieren. Um die Signatur zu überprüfen, rufen Sie die Produktion Verify auf. Geben Sie die Signatur sowie denselben KMS-Schlüssel, dieselbe Nachricht und denselben Signaturalgorithmus an. AWS KMS verwendet dann den öffentlichen Schlüssel im RSA-Schlüsselpaar, um die Signatur zu überprüfen. Sie können den öffentlichen Schlüssel auch herunterladen und ihn verwenden, um die Signatur außerhalb von AWS KMS zu überprüfen.

AWS KMS unterstützt die folgenden Signaturalgorithmen für alle KMS-Schlüssel mit einer RSA-Schlüsselspezifikation. Sie müssen einen Signaturalgorithmus angeben, wenn Sie die Operationen Sign (Signieren) und Verify (Überprüfen) aufrufen. Sie können für jede Anforderung einen anderen Algorithmus auswählen. Beim Signieren mit RSA-Schlüsselpaaren werden RSASSA-PSS-Algorithmen bevorzugt. Wir schließen RSASSA-PKCS1-v1_5-Algorithmen ein, um die Kompatibilität mit bestehenden Anwendungen zu gewährleisten.

Sie können einen KMS-Schlüssel nicht so konfigurieren, dass bestimmte Signaturalgorithmen verwendet werden. Sie können jedoch die SigningAlgorithm Richtlinienbedingung kms: verwenden, um die Signaturalgorithmen anzugeben, die Prinzipale mit dem KMS-Schlüssel verwenden dürfen.

Um die Signaturalgorithmen für einen KMS-Schlüssel abzurufen, sehen Sie sich die kryptografische Konfiguration des KMS-Schlüssels in der AWS KMS Konsole an oder verwenden Sie den DescribeKeyVorgang. AWS KMS stellt außerdem die Schlüsselspezifikation und die Signaturalgorithmen bereit, wenn Sie Ihren öffentlichen Schlüssel entweder in der AWS KMS Konsole oder mithilfe des GetPublicKeyVorgangs herunterladen.

Elliptic Curve(EC)-Schlüsselspezifikationen

Wenn Sie eine ECC-Schlüsselspezifikation (Elliptic Curve) verwenden, AWS KMS wird ein asymmetrischer KMS-Schlüssel mit einem ECC-Schlüsselpaar zum Signieren und Verifizieren oder zum Ableiten von gemeinsamen Geheimnissen (aber nicht beides) erstellt. Der private Schlüssel, der Signaturen generiert oder gemeinsame Geheimnisse ableitet, bleibt niemals unverschlüsselt. AWS KMS Sie können den öffentlichen Schlüssel verwenden, um Signaturen innerhalb von zu überprüfen AWS KMS, oder den öffentlichen Schlüssel herunterladen, um ihn außerhalb von zu verwenden. AWS KMS

AWS KMS unterstützt die folgenden ECC-Schlüsselspezifikationen für asymmetrische KMS-Schlüssel.

Die von Ihnen gewählte ECC-Schlüsselspezifikation hängt möglicherweise von Ihren Sicherheitsstandards oder den Anforderungen Ihrer Aufgabe ab. Verwenden Sie im Allgemeinen die Kurve mit den meisten Punkten, die für Ihre Aufgabe praktisch und erschwinglich ist.

Wenn Sie einen asymmetrischen KMS-Schlüssel erstellen, um gemeinsame geheime Schlüssel abzuleiten, verwenden Sie eine der von NIST empfohlenen Spezifikationen für elliptische Kurvenschlüssel. Der einzige unterstützte Schlüsselvereinbarungsalgorithmus zur Ableitung gemeinsamer Geheimnisse ist der Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive (ECDH).

Wenn Sie einen asymmetrischen KMS-Schlüssel für die Verwendung mit Kryptowährungen erstellen, verwenden Sie die Schlüsselspezifikation ECC_SECG_P256K1. Sie können diese Schlüsselspezifikation auch für andere Zwecke verwenden, aber sie ist für Bitcoin und andere Kryptowährungen erforderlich.

KMS-Schlüssel mit unterschiedlichen ECC-Schlüsselspezifikationen haben unterschiedliche Preise und unterliegen unterschiedlichen Anforderungkontingenten. Informationen zur Preisgestaltung finden Sie unter Preisgestaltung. AWS KMSAWS Key Management Service Weitere Informationen zu Anforderungskontingenten finden Sie unter Anforderungskontingente.

In der folgenden Tabelle sind die Signaturalgorithmen aufgeführt, die für die einzelnen ECC-Schlüsselspezifikationen AWS KMS unterstützt werden. Sie können einen KMS-Schlüssel nicht so konfigurieren, dass bestimmte Signaturalgorithmen verwendet werden. Sie können jedoch die SigningAlgorithm Richtlinienbedingung kms: verwenden, um die Signaturalgorithmen anzugeben, die Prinzipale mit dem KMS-Schlüssel verwenden dürfen.

Offline-Ableitung gemeinsam genutzter Geheimnisse

Sie können den öffentlichen Schlüssel Ihres ECC-Schlüsselpaars herunterladen, um ihn im Offline-Betrieb zu verwenden, d. h. bei Vorgängen außerhalb von AWS KMS.

Die folgende OpenSSL-Komplettlösung zeigt eine Methode zum Ableiten eines gemeinsamen geheimen Schlüssels außerhalb der AWS KMS Verwendung des öffentlichen Schlüssels eines ECC-KMS-Schlüsselpaars und eines mit OpenSSL erstellten privaten Schlüssels.

SM2-Schlüsselspezifikation (nur China-Regionen)

Die SM2-Schlüsselspezifikation ist eine Elliptic-Curve-Schlüsselspezifikation, die in der GM/T-Spezifikationsreihe definiert ist, die von Chinas Büro für staatliche kommerzielle Kryptographie (OSCCA) veröffentlicht wurde. Die SM2-Schlüsselspezifikation ist nur in den China-Regionen verfügbar. Wenn Sie die SM2-Schlüsselspezifikation verwenden, AWS KMS wird ein asymmetrischer KMS-Schlüssel mit einem SM2-Schlüsselpaar erstellt. Sie können Ihr SM2-Schlüsselpaar innerhalb von AWS KMS verwenden oder den öffentlichen Schlüssel für die Verwendung außerhalb von AWS KMS herunterladen.

Jeder KMS-Schlüssel kann nur eine Schlüsselnutzung haben. Sie können einen SM2-KMS-Schlüssel zum Signieren und Verifizieren, Verschlüsseln und Entschlüsseln oder zum Ableiten von gemeinsamen Geheimnissen verwenden. Sie müssen die Schlüsselverwendung bestimmen, wenn Sie den KMS-Schlüssel erstellen. Sie kann nach der Schlüsselerstellung nicht mehr geändert werden.

Wenn Sie einen asymmetrischen KMS-Schlüssel erstellen, um gemeinsame geheime Schlüssel abzuleiten, verwenden Sie die SM2-Schlüsselspezifikation. Der einzige unterstützte Schlüsselvereinbarungsalgorithmus zur Ableitung gemeinsamer Geheimnisse ist der Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive (ECDH).

AWS KMS unterstützt die folgenden SM2-Verschlüsselungs- und Signaturalgorithmen:

Offline-Operationen mit SM2 (nur China-Regionen)

Sie können den öffentlichen Schlüssel Ihres SM2-Schlüsselpaars zur Verwendung im Offline-Betrieb herunterladen, d. h. für Operationen außerhalb von AWS KMS. Wenn Sie Ihren öffentlichen SM2-Schlüssel jedoch offline verwenden, müssen Sie möglicherweise manuell zusätzliche Konvertierungen und Berechnungen durchführen. Bei SM2DSA-Operationen müssen Sie möglicherweise eine unterscheidende ID angeben oder einen Message Digest berechnen. SM2PKE-Verschlüsselungsoperationen erfordern möglicherweise, dass Sie die Rohchiffretext-Ausgabe in ein Format konvertieren, das akzeptiert werden kann. AWS KMS

Um Ihnen bei diesen Vorgängen zu helfen, bietet die SM2OfflineOperationHelper-Klasse für Java Methoden, die die Aufgaben für Sie ausführen. Sie können diese Hilfsklasse als Modell für andere kryptografische Anbieter verwenden.

Offline-Überprüfung mit SM2-Schlüsselpaaren (nur China-Regionen)

Um eine Signatur außerhalb eines öffentlichen SM2-Schlüssels zu verifizieren, müssen Sie die identifizierende ID angeben. AWS KMS Wenn Sie eine Rohnachricht an die Sign-API übergeben MessageType:RAW, AWS KMS verwendet sie die standardmäßige Unterscheidungs-ID1234567812345678, die von OSCCA in GM/T 0009-2012 definiert wurde. Sie können nicht Ihre eigene unterscheidende ID in AWS KMS angeben.

Wenn Sie jedoch einen Nachrichtenüberblick außerhalb von generieren AWS, können Sie Ihre eigene Unterscheidungs-ID angeben und dann den Nachrichtenüberblick,, zum Signieren an übergeben. MessageType:DIGEST AWS KMS Dafür ändern Sie den DEFAULT_DISTINGUISHING_ID-Wert in der SM2OfflineOperationHelper-Klasse. Die von Ihnen angegebene Unterscheidungs-ID kann eine beliebige Zeichenfolge mit einer Länge von bis zu 8.192 Zeichen sein. Nachdem Sie den Message Digest AWS KMS signiert haben, benötigen Sie entweder den Message Digest oder die Nachricht und die identifizierende ID, mit der der Digest berechnet wurde, um ihn offline zu verifizieren.

SM2OfflineOperationHelper-Klasse

Darin werden die AWS KMS unformatierten Chiffretext-Konvertierungen und die SM2DSA-Nachrichtendigest-Berechnungen automatisch durchgeführt. Nicht alle kryptografischen Anbieter implementieren SM2 auf die gleiche Weise. Einige Bibliotheken, wie OpenSSL-Versionen 1.1.1 und höher, führen diese Aktionen automatisch aus. AWS KMS bestätigte dieses Verhalten beim Testen mit OpenSSL Version 3.0. Verwenden Sie die folgende SM2OfflineOperationHelper-Klasse mit Bibliotheken, wie Bouncy Castle, bei denen Sie diese Konvertierungen und Berechnungen manuell durchführen müssen.

Die SM2OfflineOperationHelper-Klasse bietet Methoden für die folgenden Offline-Vorgänge:

Standardmäßig verwendet die SM2OfflineOperationHelper-Klasse die standardmäßige Unterscheidungs-ID, 1234567812345678, wenn Message Digests für SM2DSA-Vorgänge generiert werden.

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");
    }
}

Schlüsselspezifikation SYMMMETRIC_DEFAULT

Die Standard-Schlüsselspezifikation SYMMMETRIC_DEFAULT ist die Schlüsselspezifikation für KMS-Schlüssel mit symmetrischer Verschlüsselung. Wenn Sie in der AWS KMS Konsole den Schlüsseltyp Symmetrisch und die Verwendung des Schlüssels Verschlüsseln und Entschlüsseln auswählen, wird die Schlüsselspezifikation ausgewählt. SYMMETRIC_DEFAULT Wenn Sie bei der CreateKeyOperation keinen KeySpec Wert angeben, wird SYMMETRIC_DEFAULT ausgewählt. Wenn Sie keinen Grund haben, eine andere Schlüsselspezifikation zu verwenden, ist SYMMETRIC_DEFAULT eine gute Wahl.

SYMMETRIC_DEFAULT stellt gegenwärtig AES-256-GCM, einen symmetrischen Algorithmus, dar, der auf dem Advanced Encryption Standard (AES) im Galois Counter Mode (GCM) mit 256-Bit-Schlüsseln basiert, einem Industriestandard für sichere Verschlüsselung. Der Chiffretext, den dieser Algorithmus generiert, unterstützt zusätzliche authentifizierte Daten (AAD), z. B. einen Verschlüsselungskontext, und GCM bietet eine zusätzliche Integritätsprüfung für den Chiffretext. Details dazu finden Sie unter AWS Key Management Service kryptografische Details.

Die unter AES-256-GCM verschlüsselten Daten sind gegenwärtig und zukünftig geschützt. Kryptographen betrachten diesen Algorithmus als quantenresistent. Theoretische zukünftige, groß angelegte Quantenrechnungsangriffe auf Verschlüsselungstexte, die unter 256-Bit-AES-GCM-Schlüsseln erstellt wurden, reduzieren die effektive Sicherheit des Schlüssels auf 128-Bits. Diese Sicherheitsstufe reicht jedoch aus, um Brute-Force-Angriffe auf Chiffretexte unmöglich zu machen. AWS KMS

Die einzige Ausnahme bilden die China-Regionen, in denen SYMMETRIC_DEFAULT einen symmetrischen 128-Bit-Schlüssel darstellt, der SM4-Verschlüsselung verwendet. Sie können einen 128-Bit-SM4-Schlüssel nur innerhalb der China-Regionen erstellen. Sie können keinen 256-Bit-AES-GCM-KMS-Schlüssel in China erstellen.

Sie können einen KMS-Schlüssel mit symmetrischer Verschlüsselung verwenden, um Daten AWS KMS zu verschlüsseln, zu entschlüsseln und erneut zu verschlüsseln und um generierte Datenschlüssel und Datenschlüsselpaare zu schützen. AWS Dienste, die in integriert sind, AWS KMS verwenden KMS-Schlüssel mit symmetrischer Verschlüsselung, um Ihre Daten im Ruhezustand zu verschlüsseln. Sie können in einen KMS-Schlüssel mit symmetrischer Verschlüsselung Ihr eigenes Schlüsselmaterial importieren und KMS-Schlüssel mit symmetrischer Verschlüsselung in benutzerdefinierten Schlüsselspeichern erstellen. Eine Tabelle mit den Operationen, die Sie für symmetrische und asymmetrische KMS-Schlüssel ausführen können, finden Sie unter Vergleich symmetrischer und asymmetrischer KMS-Schlüssel.

Technische Informationen zu AWS KMS symmetrischen Verschlüsselungsschlüsseln finden AWS Key Management Service Sie unter Kryptografische Details.