Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
Den här artikeln beskriver krypteringsalgoritmer och mekanismer för att härleda kryptografiskt material som används i funktionen Always Encrypted i SQL Server och Azure SQL Database. Dessa algoritmer gäller för alla utgåvor och versioner av Always Encrypted; både Always Encrypted med och utan säkra enklaver använder samma krypteringsalgoritm.
Algoritmer för nycklar, nyckellager och nyckelkryptering
Always Encrypted använder två typer av nycklar: Kolumnhuvudnycklar och kolumnkrypteringsnycklar.
En kolumnhuvudnyckel (CMK) är en nyckelkrypteringsnyckel (till exempel en nyckel som används för att kryptera andra nycklar) som alltid finns i en klients kontroll och lagras i ett externt nyckelarkiv. En klientdrivrutin som är Always Encrypted-aktiverad interagerar med nyckellagringen via en CMK-tjänsteleverantör, som antingen kan vara en del av drivrutinsbiblioteket (en Microsoft/systemleverantör) eller en del av klientprogrammet (en anpassad leverantör). Klientdrivrutinsbibliotek innehåller för närvarande Microsofts nyckellagringsleverantörer för Windows Certificate Store och maskinvarusäkerhetsmoduler (HSM). Den aktuella listan över leverantörer finns i CREATE COLUMN MASTER KEY (Transact-SQL). En applikationsutvecklare kan tillhandahålla en anpassad leverantör för en godtycklig butik.
En kolumnkrypteringsnyckel (CEK) är en innehållskrypteringsnyckel (till exempel en nyckel som används för att skydda data) som skyddas av en CMK.
Alla Microsoft CMK-butiksleverantörer krypterar CEK:er med hjälp av RSA med optimal asymmetrisk krypteringsutfyllnad (RSA-OAEP). Nyckellagringsprovidern som stöder Microsoft Cryptography API: Next Generation (CNG) i .NET Framework (SqlColumnEncryptionCngProvider Class) använder standardparametrarna som anges av RFC 8017 i avsnitt A.2.1. Dessa standardparametrar använder en hashfunktion av SHA-1 och en maskgenereringsfunktion för MGF1 med SHA-1. Alla andra nyckellagringsleverantörer använder SHA-256.
Always Encrypted använder FIPS 140-2-verifierade kryptografiska moduler internt.
Algoritm för datakryptering
Always Encrypted använder AEAD_AES_256_CBC_HMAC_SHA_256-algoritmen för att kryptera data i databasen. AEAD står för autentiserad kryptering med associerade data. HMAC står för hash-baserad kod för meddelandeautentisering; MAC står för kod för meddelandeautentisering.
AEAD_AES_256_CBC_HMAC_SHA_256 härleds från IETF-specifikationsutkastet. Den använder ett autentiserat krypteringsschema med associerade data, enligt metoden Encrypt-then-MAC. Det innebär att klartexten först krypteras och MAC skapas baserat på den resulterande chiffertexten.
För att dölja mönster använder AEAD_AES_256_CBC_HMAC_SHA_256 CBC-läget (Cipher Block Chaining), där ett initialt värde matas in i systemet med namnet initieringsvektorn (IV). Den fullständiga beskrivningen av CBC-läget finns vid US National Institute of Standards and Technology (NIST).
AEAD_AES_256_CBC_HMAC_SHA_256 beräknar ett chiffertextvärde för ett angivet klartextvärde med hjälp av följande steg.
Steg 1: Generera initieringsvektorn (IV)
Always Encrypted stöder två varianter av AEAD_AES_256_CBC_HMAC_SHA_256:
Randomiserad
Deterministisk
För randomiserad kryptering genereras IV slumpmässigt. Varje gång samma klartext krypteras genereras därför en annan chiffertext, vilket förhindrar att information avslöjas.
When using randomized encryption: IV = Generate cryptographically random 128bits
För deterministisk kryptering genereras inte IV slumpmässigt, utan härleds i stället från klartextvärdet med hjälp av följande algoritm:
When using deterministic encryption: IV = HMAC-SHA-256( iv_key, cell_data ) truncated to 128 bits.
Där iv_key härleds från CEK på följande sätt:
iv_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell IV key" + algorithm + CEK_length)
HMAC-värdetrunkeringen utförs för att passa ett datablock efter behov för IV. Därför genererar deterministisk kryptering alltid samma chiffertext för ett givet klartextvärde, vilket gör det möjligt att avgöra om två klartextvärden är lika genom att jämföra motsvarande chiffertextvärden. Detta begränsade informationslämnande gör det möjligt för databassystemet att stödja likhetsjämförelse på krypterade kolumnvärden.
Deterministisk kryptering är effektivare när det gäller att dölja mönster, jämfört med alternativ, till exempel att använda ett fördefinierat IV-värde.
Steg 2: Databehandling AES_256_CBC chiffertext
För Always Encrypteds AEAD_AES_256_CBC_HMAC_SHA_256-algoritm genereras AES_256_CBC chiffertext efter databehandling av IV i steg 1:
aes_256_cbc_ciphertext = AES-CBC-256(enc_key, IV, cell_data) with PKCS7 padding.
Där krypteringsnyckeln (enc_key) härleds från kolumnkrypteringsnyckeln (CEK) enligt följande:
enc_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell encryption key" + algorithm + CEK_length )
Steg 3: Beräkna MAC
För Always Encrypteds AEAD_AES_256_CBC_HMAC_SHA_256-algoritm beräknas MAC (kod för meddelandeautentisering) från versionsbytet, IV (från steg 1) och AES_256_CBC chiffertext (från steg 2) med hjälp av en mac_key härledd från kolumnkrypteringsnyckeln (CEK):
MAC = HMAC-SHA-256(mac_key, versionbyte + IV + Ciphertext + versionbyte_length)
Where:
versionbyte = 0x01 and versionbyte_length = 1
mac_key = HMAC-SHA-256(CEK, "Microsoft SQL Server cell MAC key" + algorithm + CEK_length)
Steg 4: Sammanlänkning
För Always Encrypteds AEAD_AES_256_CBC_HMAC_SHA_256-algoritm skapas det slutliga krypterade värdet genom att algoritmversionsbyte sammanfogas, MAC (från steg 3), IV (från steg 1) och AES_256_CBC chiffertext (från steg 2):
aead_aes_256_cbc_hmac_sha_256 = versionbyte + MAC + IV + aes_256_cbc_ciphertext
Chiffertextlängd
Längden (i byte) på vissa komponenter i AEAD_AES_256_CBC_HMAC_SHA_256 chiffertext är:
| Component | Storlek (byte) |
|---|---|
versionbyte |
1 |
MAC |
32 |
IV |
16 |
aes_256_cbc_ciphertext |
(FLOOR(DATALENGTH(cell_data) / block_size) + 1) * block_size, där block_size är 16 byte och cell_data är klartextvärdet. Den minsta storleken på aes_256_cbc_ciphertext är ett block (16 byte). |
Därför kan längden på chiffertexten, som beror på kryptering av ett angivet klartextvärde (cell_data), beräknas med hjälp av följande formel:
1 + 32 + 16 + (FLOOR(DATALENGTH(cell_data)/16) + 1) * 16
Till exempel:
Ett 4 byte långt int-klartextvärde blir ett 65 byte långt binärt värde efter kryptering.
Ett 2 000 byte långt nchar(1 000) klartextvärde blir ett 2 065 byte långt binärt värde efter kryptering.
Chiffertextlängden beror på källdatatypen. För typer med fast längd är resultatet en konstant; för variabellängdstyper (char, , ncharvarchar, nvarchar, binary, ), varbinaryanvänder du formeln ovan. Typer som är markerade med N/A kan inte krypteras med Always Encrypted. Följande tabell innehåller en fullständig lista över datatyper och längden på chiffertexten för varje typ.
| Datatyp | Chiffertextlängd [byte] |
|---|---|
| bigint | 65 |
| binary | Varierar. Använd formeln ovan. |
| bit | 65 |
| tecken | Varierar. Använd formeln ovan. |
| date | 65 |
| datetime | 65 |
| datetime2 | 65 |
| datetimeoffset | 65 |
| decimal | 81 |
| float | 65 |
| geography | N/A (stöds inte) |
| geometry | N/A (stöds inte) |
| hierarchyid | N/A (stöds inte) |
| image | N/A (stöds inte) |
| int | 65 |
| pengar | 65 |
| nchar | Varierar. Använd formeln ovan. |
| ntext | N/A (stöds inte) |
| numerisk | 81 |
| nvarchar | Varierar. Använd formeln ovan. |
| riktiga | 65 |
| smalldatetime | 65 |
| smallint | 65 |
| småpengar | 65 |
| sql_variant | N/A (stöds inte) |
| sysname | N/A (stöds inte) |
| text | N/A (stöds inte) |
| time | 65 |
|
Tidsstämpel (rowversion) |
N/A (stöds inte) |
| tinyint | 65 |
| uniqueidentifier | 81 |
| varbinary | Varierar. Använd formeln ovan. |
| varchar | Varierar. Använd formeln ovan. |
| xml | N/A (stöds inte) |
.NET referens
Mer information om de algoritmer som beskrivs i den här artikeln finns i SqlAeadAes256CbcHmac256Algorithm.cs, SqlColumnEncryptionCertificateStoreProvider.cs och SqlColumnEncryptionCngProvider.cs filer i .NET-referensen.