Criptografia Always Encrypted

Artigo
05/23/2023

Aplica-se a:SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

Este documento descreve mecanismos e algoritmos de criptografia para derivar o material criptográfico usado no recurso Always Encrypted no SQL Server e no banco de dados SQL do Azure.

Chaves, repositórios de chaves e algoritmos de criptografia de chave

O Sempre Criptografado usa dois tipos de chave: chaves mestras de coluna e chaves de criptografia de coluna.

Uma CMK (chave mestra de coluna) é uma chave de criptografia de chave (por exemplo, uma chave usada para criptografar outras chaves) que está sempre sob controle do cliente e é armazenada em um repositório de chaves externas. Um driver de cliente habilitado para Always Encrypted interage com o repositório de chaves por meio de um provedor de repositório CMK, que pode fazer parte da biblioteca de drivers (um provedor da Microsoft/de sistema) ou parte do aplicativo cliente (um provedor personalizado). Atualmente, as bibliotecas de drivers de cliente incluem provedores de repositório de chaves da Microsoft para Repositório de Certificados do Windows e HSMs (módulos de segurança de hardware). Para obter a lista atual de provedores, veja CREATE COLUMN MASTER KEY (Transact-SQL). Um desenvolvedor de aplicativos pode fornecer um provedor personalizado para um repositório arbitrário.

Uma CEK (chave de criptografia de coluna) é uma criptografia de conteúdo (por exemplo, uma chave usada para proteger dados) protegida por uma CMK.

Todos os provedores de repositórios de CMK da Microsoft criptografam CEKs usando RSA-OAEP (RSA com preenchimento de criptografia assimétrica ideal). O provedor de repositório de chaves compatível com API de criptografia da Microsoft: a próxima geração (CNG) no .NET Framework (SqlColumnEncryptionCngProvider Class) usa os parâmetros padrão especificados por RFC 8017 na seção A.2.1. Esses parâmetros padrão estão usando uma função de hash de SHA-1 e uma função de geração de máscara de MGF1 com SHA-1. Todos os outros provedores de repositório de chaves usam SHA-256.

Always Encrypted usa internamente os módulos criptográficos validados pelo FIPS 140-2.

Algoritmo de criptografia de dados

O Always Encrypted usa o algoritmo AEAD_AES_256_CBC_HMAC_SHA_256 para criptografar dados no banco de dados.

AEAD_AES_256_CBC_HMAC_SHA_256 é derivado do projeto da especificação em https://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05. Ele usa um esquema de Criptografia Autenticada com Dados Associados, seguindo uma abordagem Criptografar depois MAC. Isto é, o texto não criptografado é criptografado primeiro e o MAC é gerado com base no texto cifrado resultante.

Para ocultar padrões, o AEAD_AES_256_CBC_HMAC_SHA_256 usa o modo de operação CBC (Encadeamento de Blocos de Criptografia), em que um valor inicial é alimentado no sistema chamado IV (vetor de inicialização). A descrição completa do modo CBC pode ser encontrada em https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.

OAEAD_AES_256_CBC_HMAC_SHA_256 computa um valor de texto cifrado para determinado valor de texto não criptografado usando as etapas a seguir.

Etapa 1: Gerando o IV (vetor de inicialização)

O Always Encrypted dá suporte a duas variações de AEAD_AES_256_CBC_HMAC_SHA_256:

Aleatória
Determinística

Para criptografia aleatória, o IV é gerado aleatoriamente. Como resultado, toda vez que o mesmo texto não criptografado é criptografado, um texto cifrado diferente é gerado, o que impede a divulgação de quaisquer informações.

When using randomized encryption: IV = Generate cryptographicaly random 128bits

Caso haja criptografia determinística, o IV não é gerado aleatoriamente, mas, em vez disso, ele é derivado do valor de texto não criptografado usando o seguinte algoritmo:

When using deterministic encryption: IV = HMAC-SHA-256( iv_key, cell_data ) truncated to 128 bits.

Onde iv_key é derivado da CEK da seguinte maneira:

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

O truncamento do valor HMAC é executado para adequação de um bloco de dados conforme a necessidade do IV. Como resultado, a criptografia determinística sempre produz o mesmo texto cifrado para um determinado valor de texto não criptografado, o que permite inferir se dois valores de texto não criptografado são iguais comparando seus valores de texto cifrado correspondentes. Essa divulgação limitada de informações permite que o sistema de banco de dados ofereça suporte à comparação de igualdade em valores de coluna criptografados.

A criptografia determinística é mais eficaz em ocultar padrões, em comparação com as alternativas, como usar um valor predefinido de IV.

Etapa 2: Computando o texto cifrado AES_256_CBC

Depois de computar o IV, o texto cifrado AES_256_CBC é gerado:

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

Onde a chave de criptografia (enc_key) é derivada da CEK como se segue.

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

Etapa 3: Computando o MAC

Subsequentemente, o MAC é computado usando o seguinte algoritmo:

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

Em que:

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

Etapa 4: Concatenação

Por fim, o valor criptografado é produzido com a concatenação do byte da versão do algoritmo, do MAC, do IV e do texto cifrado AES_256_CBC:

aead_aes_256_cbc_hmac_sha_256 = versionbyte + MAC + IV + aes_256_cbc_ciphertext

Comprimento do texto cifrado

Os tamanhos (em bytes) de componentes específicos do texto cifrado AEAD_AES_256_CBC_HMAC_SHA_256 são:

versionbyte: 1
MAC: 32
IV: 16
aes_256_cbc_ciphertext: (FLOOR (DATALENGTH(cell_data)/ block_size) + 1)* block_size, em que:
- block_size é 16 bytes
- cell_data é um valor de texto não criptografado
Portanto, o tamanho mínimo de aes_256_cbc_ciphertext é 1 bloco, que são 16 bytes.

Portanto, o comprimento do texto cifrado, resultante da criptografia de determinados valores de texto não criptografado (cell_data) pode ser calculado usando a fórmula a seguir:

1 + 32 + 16 + (FLOOR(DATALENGTH(cell_data)/16) + 1) * 16

Por exemplo:

Um valor de texto não criptografado int longo de 4 bytes torna-se um valor binário longo de 65 bytes após a criptografia.
Um valor de texto não criptografado nchar(1000) longo de 2.000 bytes torna-se um valor binário longo de 2.065 bytes após a criptografia.

A tabela a seguir contém uma lista completa de tipos de dados e o comprimento do texto cifrado para cada tipo.

Tipo de Dados	Comprimento do texto cifrado [bytes]
bigint	65
binary	Varia. Use a fórmula acima.
bit	65
char	Varia. Use a fórmula acima.
date	65
datetime	65
datetime2	65
datetimeoffset	65
decimal	81
float	65
geografia	N/D (sem suporte)
geometria	N/D (sem suporte)
hierarchyid	N/D (sem suporte)
imagem	N/D (sem suporte)
int	65
money	65
nchar	Varia. Use a fórmula acima.
ntext	N/D (sem suporte)
numeric	81
nvarchar	Varia. Use a fórmula acima.
real	65
smalldatetime	65
smallint	65
smallmoney	65
sql_variant	N/D (sem suporte)
sysname	N/D (sem suporte)
text	N/D (sem suporte)
time	65
timestamp (rowversion)	N/D (sem suporte)
tinyint	65
uniqueidentifier	81
varbinary	Varia. Use a fórmula acima.
varchar	Varia. Use a fórmula acima.
xml	N/D (sem suporte)

Referência do .NET

Para obter detalhes sobre os algoritmos abordados neste documento, confira os arquivos SqlAeadAes256CbcHmac256Algorithm.cs, SqlColumnEncryptionCertificateStoreProvider.cs e SqlColumnEncryptionCertificateStoreProvider.cs na Referência do .NET.