Criptografia Always Encrypted
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 cryptographically 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.