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, erstellt AWS KMS einen asymmetrischen KMS-Schlüssel mit einem RSA-Schlüsselpaar. Der private Schlüssel verlässt AWS KMS niemals unverschlüsselt. Sie können den öffentlichen Schlüssel innerhalb von AWS KMS verwenden oder für die Verwendung außerhalb von AWS KMS herunterladen.

Warnung

Wenn Sie Daten außerhalb von AWS KMS verschlüsseln, stellen Sie sicher, dass Sie Ihren Chiffretext entschlüsseln können. Wenn Sie den öffentlichen Schlüssel aus einem KMS-Schlüssel, der aus AWS KMS gelöscht wurde, den öffentlichen Schlüssel aus einem für Signatur und Überprüfung konfigurierten KMS-Schlüssel oder einen vom KMS-Schlüssel nicht unterstützten Verschlüsselungsalgorithmus verwenden, können die Daten nicht wiederhergestellt werden.

In AWS KMS können Sie asymmetrische KMS-Schlüssel mit RSA-Schlüsselpaaren für Verschlüsselung und Entschlüsselung oder für Signatur und Verifizierung verwenden, jedoch nicht für 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 Signatur und Überprüfung:

• RSA_2048

• RSA_3072

• RSA_4096

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. Weitere Informationen zur AWS KMS-Preisgestaltung finden Sie unter AWS Key Management Service – Preise. 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 die Encrypt-Produktion in AWS KMS für einen RSA-KMS-Schlüssel aufrufen, verwendet AWS KMS 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 die Decrypt-Produktion auf und geben Sie denselben KMS-Schlüssel und 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 ihn verwenden, um Daten außerhalb von AWS KMS zu verschlüsseln. Achten Sie darauf, einen Verschlüsselungsalgorithmus zu verwenden, den AWS KMS für RSA-KMS-Schlüssel 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.

Unterstützte Verschlüsselungsalgorithmen für RSA-Schlüsselspezifikationen
Verschlüsselungsalgorithmus	Beschreibung des Algorithmus
RSAES_OAEP_SHA_1	PKCS #1 v2.2, Abschnitt 7.1. RSA-Verschlüsselung mit OAEP-Auffüllung mit SHA-1 sowohl für den Hash als auch in der MGF1-Maskengenerierungsfunktion zusammen mit einer leeren Kennzeichnung.
RSAES_OAEP_SHA_256	PKCS #1, Abschnitt 7.1. RSA-Verschlüsselung mit OAEP-Auffüllung mit SHA-256 sowohl für den Hash als auch in der MGF1-Maskengenerierungsfunktion zusammen mit einer leeren Kennzeichnung.

Sie können einen KMS-Schlüssel nicht so konfigurieren, dass er einen bestimmten Verschlüsselungsalgorithmus verwendet. Sie können jedoch die kms:EncryptionAlgorithm-Richtlinienbedingung 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, zeigen Sie die kryptografische Konfiguration des KMS-Schlüssels in der -AWS KMSKonsole an oder verwenden Sie die -DescribeKeyOperation. stellt AWS KMS auch die Schlüsselspezifikation und die Verschlüsselungsalgorithmen bereit, wenn Sie Ihren öffentlichen Schlüssel entweder in der -AWS KMSKonsole oder mithilfe der -GetPublicKeyOperation 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.

Maximale Klartextgröße (in Bytes) in einer Verschlüsselungsoperation
	Verschlüsselungsalgorithmus
Schlüsselspezifikation	RSAES_OAEP_SHA_1	RSAES_OAEP_SHA_256
RSA_2048	214	190
RSA_3072	342	318
RSA_4096	470	446

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 die Sign-Produktion in AWS KMS für einen asymmetrischen KMS-Schlüssel aufrufen, verwendet AWS KMS 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 den gleichen KMS-Schlüssel, und Signaturalgorithmus und die gleiche Nachricht an. AWS KMS verwendet dann den öffentlichen Schlüssel im RSA-Schlüsselpaar, um die Signatur zu verifizieren. 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.

Unterstützte Signaturalgorithmen für RSA-Schlüsselspezifikationen
Signaturalgorithmus	Beschreibung des Algorithmus
RSASSA_PSS_SHA_256	PKCS #1 v2.2, Abschnitt 8.1, RSA-Signatur mit PSS-Auffüllung mit SHA-256 sowohl für den Message Digest als auch die MGF1-Maskengenerierungsfunktion zusammen mit 256-Bit-Salt
RSASSA_PSS_SHA_384	PKCS #1 v2.2, Abschnitt 8.1, RSA-Signatur mit PSS-Auffüllung mit SHA-384 sowohl für den Message Digest als auch die MGF1-Maskengenerierungsfunktion zusammen mit 384-Bit-Salt
RSASSA_PSS_SHA_512	PKCS #1 v2.2, Abschnitt 8.1, RSA-Signatur mit PSS-Auffüllung mit SHA-512 sowohl für den Message Digest als auch die MGF1-Maskengenerierungsfunktion zusammen mit 512-Bit-Salt
RSASSA_PKCS1_V1_5_SHA_256	PKCS #1 v2.2, Abschnitt 8.2, RSA-Signatur mit PKCS #1v1.5 Auffüllung und SHA-256
RSASSA_PKCS1_V1_5_SHA_384	PKCS #1 v2.2, Abschnitt 8.2, RSA-Signatur mit PKCS #1v1.5 Auffüllung und SHA-384
RSASSA_PKCS1_V1_5_SHA_512	PKCS #1 v2.2, Abschnitt 8.2, RSA-Signatur mit PKCS #1v1.5 Auffüllung und SHA-512

Sie können einen KMS-Schlüssel nicht so konfigurieren, dass bestimmte Signaturalgorithmen verwendet werden. Sie können jedoch die kms:SigningAlgorithm-Richtlinienbedingung 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, zeigen Sie die kryptografische Konfiguration des KMS-Schlüssels in der -AWS KMSKonsole oder mithilfe der -DescribeKeyOperation an. stellt AWS KMS auch die Schlüsselspezifikation und Signaturalgorithmen bereit, wenn Sie Ihren öffentlichen Schlüssel entweder in der -AWS KMSKonsole oder mithilfe der -GetPublicKeyOperation herunterladen.

Elliptic Curve(EC)-Schlüsselspezifikationen

Wenn Sie eine Elliptic-Curve-Schlüsselspezifikation (ECC) verwenden, erstellt AWS KMS einen asymmetrischen KMS-Schlüssel mit einem ECC-Schlüsselpaar für Signatur und Verifizierung. Der private Schlüssel, der eine Signatur generiert, verlässt AWS KMS niemals unverschlüsselt. Sie können den öffentlichen Schlüssel verwenden, um innerhalb von AWS KMS Signaturen zu verifizieren oder für die Verwendung außerhalb von AWS KMS den öffentlichen Schlüssel herunterladen.

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

• Asymmetrische NIST-empfohlene Elliptic Curve-Schlüsselpaare (Signatur und Verifizierung)

  • ECC_NIST_P256 (secp256r1)

  • ECC_NIST_P384 (secp384r1)

  • ECC_NIST_P521 (secp521r1)

• Andere asymmetrische Elliptic Curve-Schlüsselpaare (Signatur und Verifizierung)

  • ECC_SECG_P256K1 (secp256k1), häufig für Kryptowährung verwendet.

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 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 zu AWS KMS-Preisen erhalten Sie unter AWS Key Management Service Pricing (Preise für WAF). Weitere Informationen zu Anforderungskontingenten finden Sie unter Anforderungskontingente.

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

Unterstützte Signaturalgorithmen für ECC-Schlüsselspezifikationen
Schlüsselspezifikation	Signaturalgorithmus	Beschreibung des Algorithmus
ECC_NIST_P256	ECDSA_SHA_256	NIST FIPS 186-4, Abschnitt 6.4, ECDSA-Signatur unter Verwendung der durch den Schlüssel angegebenen Kurve und SHA-256 für den Message Digest.
ECC_NIST_P384	ECDSA_SHA_384	NIST FIPS 186-4, Abschnitt 6.4, ECDSA-Signatur unter Verwendung der durch den Schlüssel angegebenen Kurve und SHA-384 für den Message Digest.
ECC_NIST_P521	ECDSA_SHA_512	NIST FIPS 186-4, Abschnitt 6.4, ECDSA-Signatur unter Verwendung der durch den Schlüssel angegebenen Kurve und SHA-512 für den Message Digest.
ECC_SECG_P256K1	ECDSA_SHA_256	NIST FIPS 186-4, Abschnitt 6.4, ECDSA-Signatur unter Verwendung der durch den Schlüssel angegebenen Kurve und SHA-256 für den Message Digest.

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 eine SM2-Schlüsselspezifikation verwenden, erstellt AWS KMS einen asymmetrischen KMS-Schlüssel mit einem SM2-Schlüsselpaar. Sie können Ihr SM2-Schlüsselpaar innerhalb von AWS KMS verwenden oder für die Verwendung außerhalb von AWS KMS herunterladen.

Im Gegensatz zur ECC-Schlüsselspezifikation können Sie einen SM2-KMS-Schlüssel zum Signieren und Überprüfen oder für die Verschlüsselung und Entschlüsselung 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.

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

• SM2PKE-Verschlüsselungsalgorithmus

  SM2PKE ist ein auf elliptischen Kurven basierender Verschlüsselungsalgorithmus, der von OSCCA in GM/T 0003.4-2012 definiert wurde.

• SM2DSA-Signaturalgorithmus

  SM2DSA ist ein auf elliptischen Kurven basierender Verschlüsselungsalgorithmus, der von OSCCA in GM/T 0003.2-2012 definiert wurde. SM2DSA erfordert eine unterscheidende ID, die mit dem SM3-Hashing-Algorithmus gehasht und dann mit der Nachricht oder dem Message Digest kombiniert wird, die/den Sie AWS KMS übergeben haben. Dieser verkettete Wert wird dann gehasht und von AWS KMS signiert.

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üsselungsvorgänge erfordern möglicherweise die Konvertierung der unformatierten Geheimtext-Ausgabe in ein Format, das AWS KMS akzeptieren kann.

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.

Wichtig

Der SM2OfflineOperationHelper-Referenzcode ist so konzipiert, dass er kompatibel mit Bouncy CastleVersion 1.68 ist. Für Hilfe zu anderen Versionen wenden Sie sich an bouncycastle.org.

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

Um eine Signatur außerhalb von AWS KMS mit einem öffentlichen SM2-Schlüssel zu überprüfen, müssen Sie die unterscheidende ID angeben. Wenn Sie eine unformatierte Nachricht, MessageType:RAW, an die Sign-API weitergeben, verwendet AWS KMS die standardmäßige Unterscheidungs-ID, 1234567812345678, definiert von OSCCA in GM/T 0009-2012. Sie können nicht Ihre eigene unterscheidende ID in AWS KMS angeben.

Wenn Sie jedoch einen Message Digest außerhalb von AWS generieren, können Sie Ihre eigene unterscheidende ID angeben und dann den Message Digest, MessageType:DIGEST, zum Signieren an AWS KMS übergeben. 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 AWS KMS den Message Digest signiert hat, benötigen Sie entweder den Message Digest oder die Nachricht und die unterscheidende ID, die zur Berechnung des Digest verwendet wird, um ihn offline zu verifizieren.

SM2OfflineOperationHelper-Klasse

Innerhalb von AWS KMS werden die unformatierten Geheimtext-Konvertierungen und SM2DSA-Message-Digest-Berechnungen automatisch durchgeführt. Nicht alle kryptografischen Anbieter implementieren SM2 auf die gleiche Weise. Manche Bibliotheken, wie OpenSSL der Version 1.1.1 und höher, führen diese Aktionen automatisch aus. AWS KMS bestätigte dieses Verhalten in Tests mit OpenSSL der 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:

• Message-Digest-Berechnung

  Um offline einen Message Digest zu generieren, den Sie für die Offline-Überprüfung verwenden können oder den Sie zum Signieren an AWS KMS weitergeben können, verwenden Sie die calculateSM2Digest-Methode. Die calculateSM2Digest-Methode generiert einen Message Digest mit dem SM3-Hashing-Algorithmus. Die GetPublicKey API gibt Ihren öffentlichen Schlüssel im Binärformat zurück. Sie müssen den Binärschlüssel in eine Java- analysieren PublicKey. Stellen Sie den geparsten öffentlichen Schlüssel mit der Nachricht bereit. Die Methode kombiniert Ihre Nachricht automatisch mit der standardmäßigen Unterscheidungs-ID, 1234567812345678, aber Sie können Ihre eigene Unterscheidungs-ID festlegen, indem Sie den DEFAULT_DISTINGUISHING_ID-Wert ändern.

• Verify

  Um eine Signatur offline zu prüfen, verwenden Sie die offlineSM2DSAVerify-Methode. Die offlineSM2DSAVerify-Methode verwendet den Message Difest, der anhand der angegebenen unterscheidenden ID berechnet wurde, und die ursprüngliche Nachricht, die Sie zur Überprüfung der digitalen Signatur bereitstellen. Die GetPublicKey API gibt Ihren öffentlichen Schlüssel im Binärformat zurück. Sie müssen den Binärschlüssel in eine Java- analysieren PublicKey. Stellen Sie den geparsten öffentlichen Schlüssel mit der ursprünglichen Nachricht und der Signatur, die Sie überprüfen möchten, bereit. Weitere Informationen finden Sie unter .Offline-Überprüfung mit SM2-Schlüsselpaaren.

• Encrypt

  Um Klartext offline zu verschlüsseln, verwenden Sie die offlineSM2PKEEncrypt-Methode. Diese Methode stellt sicher, dass der Geheimtext in einem Format vorliegt, das AWS KMS entschlüsseln kann. Die offlineSM2PKEEncrypt-Methode verschlüsselt den Klartext und konvertiert dann den von SM2PKE erzeugten unformatierten Geheimtext in das ASN.1-Format. Die GetPublicKey API gibt Ihren öffentlichen Schlüssel im Binärformat zurück. Sie müssen den Binärschlüssel in eine Java- analysieren PublicKey. Versehen Sie den geparsten öffentlichen Schlüssel mit dem Klartext, den Sie verschlüsseln möchten.

  Wenn Sie sich nicht sicher sind, ob Sie die Konvertierung durchführen müssen, verwenden Sie den folgenden OpenSSL-Vorgang, um das Format Ihres Geheimtextes zu testen. Wenn der Vorgang fehlschlägt, müssen Sie den Geheimtext in das ASN.1-Format konvertieren.

  openssl asn1parse -inform DER -in ciphertext.der

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 den Schlüsseltyp Symmetric (Symmetrisch) und die Schlüsselverwendung Encrypt and decrypt (Verschlüsseln und Entschlüsseln) in der AWS KMS-Konsole auswählen, wird die SYMMETRIC_DEFAULT-Schlüsselspezifikation ausgewählt. Wenn Sie in 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. Aber diese Sicherheitsstufe reicht aus, um Brute-Force-Angriffe auf AWS KMS-Verschlüsselungstexte undurchführbar zu machen.

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 in AWS KMS verwenden, um Daten zu verschlüsseln, zu entschlüsseln und erneut zu verschlüsseln und um generierte Datenschlüssel und Datenschlüsselpaare zu schützen. AWS-Services, die in AWS KMS integriert sind, verwenden im Allgemeinen 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 Details über AWS KMS und symmetrische Verschlüsselungsschlüssel finden Sie unter Kryptografische Details zu AWS Key Management Service.