Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:
SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance
In diesem Artikel werden Verschlüsselungsalgorithmen und -mechanismen beschrieben, um kryptografisches Material abzuleiten, das im Feature "Immer verschlüsselt" in SQL Server und Azure SQL-Datenbank verwendet wird. Diese Algorithmen gelten für alle Editionen und Versionen von Always Encrypted; sowohl Always Encrypted mit als auch ohne sichere Enklaven verwenden denselben Verschlüsselungsalgorithmus.
Schlüssel, Schlüsselspeicher und Algorithmen für die Schlüsselverschlüsselung
Always Encrypted verwendet zwei Schlüsseltypen: Spaltenhauptschlüssel und Spaltenverschlüsselungsschlüssel.
Ein Spaltenhauptschlüssel (Column Master Key; CMK) ist ein Schlüsselverschlüsselungsschlüssel (d. h. ein Schlüssel zum Verschlüsseln anderer Schlüssel), der sich immer unter der Kontrolle eines Clients befindet und in einem externen Schlüsselspeicher gespeichert ist. Ein Clienttreiber, der für Always Encrypted aktiviert ist, interagiert mit dem Schlüsselspeicher über einen CMK-Speicheranbieter, der entweder Teil der Treiberbibliothek (ein Microsoft/Systemanbieter) oder Teil der Clientanwendung (ein benutzerdefinierter Anbieter) ist. Clienttreiber-Bibliotheken enthalten derzeit Microsoft-Schlüsselspeicheranbieter für den Windows-Zertifikatspeicher und Hardwaresicherheitsmodule (HSMs). Die aktuelle Liste der Anbieter finden Sie unter CREATE COLUMN MASTER KEY (Transact-SQL). Ein Anwendungsentwickler kann einen benutzerdefinierten Anbieter für einen beliebigen Speicher angeben.
Ein Spaltenverschlüsselungsschlüssel (column encryption key; CEK) ist ein Inhaltsverschlüsselungsschlüssel (d.h. ein Schlüssel zum Schützen von Daten), der durch einen CMK geschützt ist.
Alle Microsoft CMK-Speicheranbieter verschlüsseln CEKs, indem sie RSA-OAEP (RSA mit optimalem asymmetrischen Verschlüsselungspadding) verwenden. Der Schlüsselspeicheranbieter, der Microsoft Cryptography API: Next Generation (CNG) im .NET Framework unterstützt (SqlColumnEncryptionCngProvider-Klasse), verwendet die in RFC 8017, Abschnitt A.2.1, angegebenen Standardparameter. Diese Standardparameter verwenden eine Hashfunktion von SHA-1 und eine Maskengenerierungsfunktion von MGF1 mit SHA-1. Alle anderen Schlüsselspeicheranbieter verwenden SHA-256.
Always Encrypted verwendet intern überprüfte FPS 140-2-Kryptografiemodule.
Datenverschlüsselungsalgorithmus
Always Encrypted verwendet den Algorithmus AEAD_AES_256_CBC_HMAC_SHA_256 zum Verschlüsseln von Daten in der Datenbank. AEAD steht für authenticated Encryption with Associated Data; HMAC steht für Hash-basierten Nachrichtenauthentifizierungscode; MAC steht für Nachrichtenauthentifizierungscode.
AEAD_AES_256_CBC_HMAC_SHA_256 wird vom IETF-Spezifikationsentwurf abgeleitet. Er verwendet ein authentifiziertes Verschlüsselungsschema mit zugeordneten Daten nach einem Encrypt-then-MAC-Ansatz. D.h. zunächst wird der Klartext verschlüsselt, und anschließend wird der MAC basierend auf dem resultierenden Chiffretext erstellt.
Um Muster zu verbergen, verwendet AEAD_AES_256_CBC_HMAC_SHA_256 den Betriebsmodus der Blockchiffreverkettung (Cipher Block Chaining, CBC), in dem ein Anfangswert in das System eingegeben wird, der als Initialisierungsvektor (IV) bezeichnet wird. Die vollständige Beschreibung des CBC-Modus finden Sie im US National Institute of Standards and Technology (NIST).
AEAD_AES_256_CBC_HMAC_SHA_256 berechnet einen Chiffretextwert für einen angegebenen Klartextwert mithilfe der folgenden Schritte.
Schritt 1: Generieren des Initialisierungsvektors (IV)
Always Encrypted unterstützt zwei Variationen von AEAD_AES_256_CBC_HMAC_SHA_256:
Zufällig
Deterministisch
Für die zufällige Verschlüsselung wird der IV zufällig generiert. Daher wird jedes Mal, wenn der gleiche Klartext verschlüsselt wird, ein anderer Chiffretext generiert, was jegliche Offenlegung von Informationen verhindert.
When using randomized encryption: IV = Generate cryptographically random 128bits
Bei deterministischer Verschlüsselung wird der IV nicht zufällig generiert, sondern stattdessen anhand des folgenden Algorithmus aus dem Nur-Text-Wert abgeleitet:
When using deterministic encryption: IV = HMAC-SHA-256( iv_key, cell_data ) truncated to 128 bits.
Wobei iv_key vom CEK folgendermaßen abgeleitet wird:
iv_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell IV key" + algorithm + CEK_length)
Die Kürzung des HMAC-Werts erfolgt, damit die Daten wie für den IV erforderlich in einen Block passen. Daher erzeugt die deterministische Verschlüsselung immer den gleichen Chiffretext für einen angegebenen Klartextwert. Dadurch kann aus einem Vergleich der entsprechenden Chiffretextwerte abgeleitet werden, ob zwei Klartexte identisch sind. Diese begrenzte Offenlegung von Informationen ermöglicht es dem Datenbanksystem, Gleichheitsvergleiche für verschlüsselte Spaltenwerte zu unterstützen.
Die deterministische Verschlüsselung ist im Vergleich zu Alternativen, wie der Verwendung von vordefinierten IV-Werten, effektiver im Verdecken von Mustern.
Schritt 2: Berechnen von AES_256_CBC Chiffretext
Für always Encrypteds AEAD_AES_256_CBC_HMAC_SHA_256 Algorithmus wird nach dem Berechnen des IV in Schritt 1 der AES_256_CBC Chiffretext generiert:
aes_256_cbc_ciphertext = AES-CBC-256(enc_key, IV, cell_data) with PKCS7 padding.
Wo der Verschlüsselungsschlüssel (enc_key) wie folgt vom Spaltenverschlüsselungsschlüssel (CEK) abgeleitet wird:
enc_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell encryption key" + algorithm + CEK_length )
Schritt 3: Berechnen des MAC
Für always Encrypteds AEAD_AES_256_CBC_HMAC_SHA_256 Algorithmus wird der MAC (Nachrichtenauthentifizierungscode) aus dem Versionsbyte, dem IV (aus Schritt 1) und dem AES_256_CBC Verschlüsselungstext (aus Schritt 2) mithilfe eines mac_key abgeleiteten Spaltenverschlüsselungsschlüssels (CEK) berechnet:
MAC = HMAC-SHA-256(mac_key, versionbyte + IV + Ciphertext + versionbyte_length)
Wo:
versionbyte = 0x01 and versionbyte_length = 1
mac_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell MAC key" + algorithm + CEK_length)
Schritt 4: Verkettung
Für always Encrypteds AEAD_AES_256_CBC_HMAC_SHA_256 Algorithmus wird der endgültige verschlüsselte Wert erzeugt, indem das Algorithmusversionsbyte, der MAC (aus Schritt 3), der IV (aus Schritt 1) und der AES_256_CBC Chiffretext (aus Schritt 2) verkettet wird:
aead_aes_256_cbc_hmac_sha_256 = versionbyte + MAC + IV + aes_256_cbc_ciphertext
Länge des Chiffretexts
Die Längen (in Bytes) bestimmter Komponenten des Chiffretexts AEAD_AES_256_CBC_HMAC_SHA_256 lauten wie folgt:
| Bestandteil | Größe (Byte) |
|---|---|
versionbyte |
1 |
MAC |
32 |
IV |
16 |
aes_256_cbc_ciphertext |
(FLOOR(DATALENGTH(cell_data) / block_size) + 1) * block_size, wobei block_size 16 Bytes und cell_data der Nur-Text-Wert ist. Die Mindestgröße ist aes_256_cbc_ciphertext ein Block (16 Byte). |
Daher kann die Länge des Chiffretexts, die sich aus der Verschlüsselung bestimmter Klartextwerte (cell_data) ergibt, mithilfe der folgenden Formel berechnet werden:
1 + 32 + 16 + (FLOOR(DATALENGTH(cell_data)/16) + 1) * 16
Zum Beispiel:
Ein 4 Bytes langer int -Klartextwert wird nach der Verschlüsselung zu einem 65 Bytes langen Binärwert.
Ein 2.000-Byte long nchar(1000) -Nur-Text-Wert wird nach der Verschlüsselung zu einem 2.065-Byte-Long-Binärwert.
Die Länge des Chiffretexts hängt vom Quelldatentyp ab. Bei Typen mit fester Länge ist das Ergebnis eine Konstante; für Variablenlängentypen (char, nchar, varchar, nvarcharbinary, ), varbinaryverwenden Sie die obige Formel. Typen, die als N/A gekennzeichnet sind, können nicht mit Always Encrypted verschlüsselt werden. Die folgende Tabelle enthält eine vollständige Liste der Datentypen und Längen der Chiffretexte für jeden Typ.
| Datentyp | Länge des Chiffretexts [Bytes] |
|---|---|
| bigint | 65 |
| binary | Variiert. Verwenden Sie die oben stehende Formel. |
| bit | 65 |
| char | Variiert. Verwenden Sie die oben stehende Formel. |
| date | 65 |
| datetime | 65 |
| datetime2 | 65 |
| datetimeoffset | 65 |
| Dezimalzahl | 81 |
| float | 65 |
| geography | N/A (nicht unterstützt) |
| geometry | N/V (nicht unterstützt) |
| hierarchyid | N/A (nicht unterstützt) |
| Abbildung | N/A (nicht unterstützt) |
| int | 65 |
| money | 65 |
| nchar | Variiert. Verwenden Sie die oben stehende Formel. |
| ntext | N/A (nicht unterstützt) |
| numeric | 81 |
| nvarchar | Variiert. Verwenden Sie die oben stehende Formel. |
| real | 65 |
| smalldatetime | 65 |
| smallint | 65 |
| smallmoney | 65 |
| sql_variant | N/A (nicht unterstützt) |
| sysname | N/A (nicht unterstützt) |
| text | N/A (nicht unterstützt) |
| time | 65 |
|
timestamp (rowversion) |
N/A (nicht unterstützt) |
| tinyint | 65 |
| uniqueidentifier | 81 |
| varbinary | Variiert. Verwenden Sie die oben stehende Formel. |
| varchar | Variiert. Verwenden Sie die oben stehende Formel. |
| xml | N/A (nicht unterstützt) |
.NET Referenz
Ausführliche Informationen zu den in diesem Artikel erläuterten Algorithmen finden Sie in der SqlAeadAes256CbcHmac256Algorithm.cs-, SqlColumnEncryptionCertificateStoreProvider.cs- und SqlColumnEncryptionCngProvider.cs-Datei in der .NET Referenz.