Freigeben über


Always Encrypted-Kryptografie

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

Dieses Dokument beschreibt Verschlüsselungsalgorithmen und -mechanismen zum Ableiten von kryptografischem Material, das im Feature Always Encrypted 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 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. Clienttreiberbibliotheken umfassen derzeit Microsoft Schlüsselspeicheranbieter für Windows-Zertifikatspeicher und Hardwaresicherheitsmodule (HSMs). Eine 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 die Microsoft Cryptography API unterstützt: Next Generation (CNG) in .NET Framework (SqlColumnEncryptionCngProvider-Klasse) verwendet dich von RFC 8017 in Abschnitt A.2.1 angegeben 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

  • 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 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  

Zum 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.

Weitere Informationen