Always Encrypted-Kryptografie

Artikel
08/23/2023

Gilt für:SQL Server Azure SQL-Datenbank Azure SQL Managed Instance

In diesem Dokument 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.

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 immer verschlüsselter Clienttreiber interagiert mit dem Schlüsselspeicher über einen CMK-Speicheranbieter, der entweder Teil der Treiberbibliothek (microsoft/system provider) oder Teil der Clientanwendung (ein benutzerdefinierter Anbieter) sein kann. Clienttreiberbibliotheken umfassen derzeit Microsoft Key Store-Anbieter für Den Windows-Zertifikatspeicher und Hardwaresicherheitsmodule (Hardware Security Modules, 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 mithilfe von RSA mit optimaler asymmetrischer Verschlüsselungsabstand (RSA-OAEP). Der Schlüsselspeicheranbieter, der die Microsoft Cryptography-API: Next Generation (CNG) in .NET Framework (SqlColumnEncryptionCngProvider Class) unterstützt, verwendet die von RFC 8017 in Section 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_AES_256_CBC_HMAC_SHA_256 wird vom Spezifikationsentwurf unter https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 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. Eine vollständige Beschreibung des CBC-Modus finden Sie unter https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.

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
Deterministic

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 cryptographicaly random 128bits

Bei der deterministischen Verschlüsselung wird der IV nicht zufällig generiert, sondern mithilfe des folgenden Algorithmus aus dem Klartextwert 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)

Das Abschneiden des HMAC-Werts wird ausgeführt, um einen Block von Daten wie für den IV benötigt anzupassen. 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 eingeschränkte Offenlegung von Informationen ermöglicht dem Datenbanksystem das Unterstützen der Gleichheitsüberprüfung von verschlüsselten Datenwerten.

Die deterministische Verschlüsselung ist im Vergleich zu Alternativen, wie der Verwendung von vordefinierten IV-Werten, effektiver im Verdecken von Mustern.

Schritt 2: Berechnen des Chiffretexts „AES_256_CBC“

Nach dem Berechnen des IV-Werts wird der Chiffretext AES_256_CBC generiert:

aes_256_cbc_ciphertext = AES-CBC-256(enc_key, IV, cell_data) with PKCS7 padding.

Wobei der Verschlüsselungsschlüssel (enc_key) vom CEK folgendermaßen abgeleitet wird.

enc_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell encryption key" + algorithm + CEK_length )

Schritt 3: Berechnen des MAC

Anschließend wird der MAC mithilfe des folgenden Algorithmus berechnet:

MAC = HMAC-SHA-256(mac_key, versionbyte + IV + Ciphertext + versionbyte_length)

Hierbei gilt:

versionbyte = 0x01 and versionbyte_length = 1
mac_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell MAC key" + algorithm + CEK_length)

Schritt 4: Verkettung

Schließlich wird der verschlüsselte Wert erzeugt, indem das Algorithmusversionsbyte, der MAC, der IV und der Chiffretext „AES_256_CBC“ verkettet werden:

aead_aes_256_cbc_hmac_sha_256 = versionbyte + MAC + IV + aes_256_cbc_ciphertext

Chiffretextlänge

Die Längen (in Bytes) bestimmter Komponenten des Chiffretexts AEAD_AES_256_CBC_HMAC_SHA_256 lauten wie folgt:

Versionsbyte: 1
MAC: 32
IV: 16
aes_256_cbc_ciphertext: (FLOOR (DATALENGTH(cell_data)/ block_size) + 1)* block_size, wobei:
- block_size 16 Byte beträgt
- cell_data ein Klartextwert ist
Daher ist die minimale Größe des aes_256_cbc_ciphertext 1 Block, der 16 Byte groß ist.

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

Beispiel:

Ein 4 Bytes langer int -Klartextwert wird nach der Verschlüsselung zu einem 65 Bytes langen Binärwert.
Ein 2000 Bytes langer nchar(1000) -Klartextwert wird nach der Verschlüsselung zu einem 2065 Bytes langen Binärwert.

Die folgende Tabelle enthält eine vollständige Liste der Datentypen und Längen der Chiffretexte für jeden Typ.

Datentyp	Chiffretextlänge [Bytes]
bigint	65
binary	Verschiedene Ursachen. Verwenden Sie die oben stehende Formel.
bit	65
char	Verschiedene Ursachen. Verwenden Sie die oben stehende Formel.
date	65
datetime	65
datetime2	65
datetimeoffset	65
decimal	81
float	65
geography	N/V (nicht unterstützt)
geometry	N/V (nicht unterstützt)
hierarchyid	N/V (nicht unterstützt)
Abbildung	N/V (nicht unterstützt)
int	65
money	65
nchar	Verschiedene Ursachen. Verwenden Sie die oben stehende Formel.
ntext	N/V (nicht unterstützt)
numeric	81
nvarchar	Verschiedene Ursachen. Verwenden Sie die oben stehende Formel.
real	65
smalldatetime	65
smallint	65
smallmoney	65
sql_variant	N/V (nicht unterstützt)
sysname	N/V (nicht unterstützt)
text	N/V (nicht unterstützt)
time	65
timestamp (rowversion)	N/V (nicht unterstützt)
tinyint	65
uniqueidentifier	81
varbinary	Verschiedene Ursachen. Verwenden Sie die oben stehende Formel.
varchar	Verschiedene Ursachen. Verwenden Sie die oben stehende Formel.
xml	N/V (nicht unterstützt)

.NET-Referenz

Weitere Informationen zu den in diesem Dokument beschriebenen Algorithmen finden Sie in der .NET-Referenz in den Dateien SqlAeadAes256CbcHmac256Algorithm.cs, SqlColumnEncryptionCertificateStoreProvider.cs und SqlColumnEncryptionCertificateStoreProvider.cs.