Configurar BYOK (bring your own key)

  • 7 minutos

Cenário

Um cliente do Key Vault gostaria de transferir com segurança uma chave de seu HSM (Módulo de Segurança de Hardware) local fora do Azure, para o HSM que dá suporte ao Azure Key Vault. O processo de importação de uma chave gerada fora do Key Vault é conhecido como BYOK (Bring Your Own Key).

Estes são os requisitos:

  • A chave a ser transferida nunca existiu fora de um HSM em formato de texto sem formatação.
  • Fora de um HSM, a chave a ser transferida é sempre protegida por uma chave mantida no HSM do Azure Key Vault.

Terminologia

Nome da chave Tipo de Chave Origem Descrição
KEK (Chave de Troca de Chaves) RSA HSM do Azure Key Vault Um par de chaves RSA compatível com o HSM gerado no Azure Key Vault
Chave de Encapsulamento AES HSM do fornecedor Uma chave AES [efêmera ] gerada pelo HSM local
Chave de Destino RSA, EC, AES (somente HSM gerenciado) HSM do fornecedor A chave a ser transferida para o HSM do Azure Key Vault

Chave de Troca de Chaves (KEK): Esta é uma chave com suporte de HSM gerada pelo cliente no cofre de chaves destinada à importação da chave Bring Your Own Key (BYOK). O KEK deve ter as seguintes propriedades:

  • Deve ser uma chave RSA-HSM, com um tamanho de 4096 bits, 3072 bits ou 2048 bits.
  • Suas operações principais (key_ops) são limitadas à "importação", permitindo seu uso exclusivamente durante o processo BYOK.
  • Ele deve residir no mesmo cofre onde a Chave de Destino deve ser importada.

Etapas do usuário

Para executar uma transferência de chave:

  1. Gerar a KEK.
  2. Recuperar a chave pública da KEK.
  3. Usando a ferramenta BYOK fornecida pelo fornecedor de HSM, importe a KEK para o HSM de destino e exporte a Chave de Destino protegida pela KEK.
  4. Importar a Chave de Destino protegida para o Azure Key Vault.

Os clientes usam a ferramenta BYOK e a documentação fornecida pelo fornecedor do HSM para concluir a etapa 3. Ela produz um Blob de Transferência de Chave (um arquivo " byok").

Restrições de HSM

O HSM existente pode aplicar restrições na chave gerenciada por ele, incluindo:

  • O HSM pode precisar ser configurado para permitir exportação baseada em encapsulamento de chave.
  • A chave de destino pode precisar ser marcada como Atributo Cryptoki (CKA)_EXTRACTABLE para que o HSM permita a exportação controlada
  • Em alguns casos, a KEK e a tecla de encapsulamento podem precisar ser marcadas como CKA_TRUSTED, o que permite que ela seja usada para encapsular chaves no HSM.

Em geral, a configuração do HSM de origem está fora do escopo dessa especificação. A Microsoft espera que o fornecedor do HSM produza documentação associada à ferramenta BYOK para incluir essas etapas de configuração.

Observação

Várias dessas etapas podem ser executadas usando outras interfaces, como o Azure PowerShell e o portal do Azure. Elas também podem ser executadas de forma programática usando funções equivalentes no SDK do Key Vault.

Gerar a KEK

Use o comando az keyvault key create para criar a KEK com operações de chave definidas para importação. Anote o identificador de chave 'kid' retornado do comando abaixo.

az keyvault key create --kty RSA-HSM --size 4096 --name KEKforBYOK --ops import --vault-name ContosoKeyVaultHSM

Os serviços dão suporte a diferentes comprimentos de KEK; o SQL do Azure, por exemplo, dá suporte apenas a comprimentos de chave de 2048 ou 3072 bytes.

Recuperar a chave pública da KEK

Baixe a parte de chave pública da KEK e armazene-a em um arquivo PEM.

az keyvault key download --name KEKforBYOK --vault-name ContosoKeyVaultHSM --file KEKforBYOK.publickey.pem

Gerar o blob de transferência de chave usando a ferramenta BYOK fornecida pelo fornecedor do HSM

Use a ferramenta BYOK fornecida pelo fornecedor de HSM para criar um blob de transferência de chave (armazenado como um arquivo ".byok"). A chave pública KEK como um .Privacy-Enhanced Mail (arquivo .pem) será uma das entradas para esta ferramenta.

Blob de Transferência de Chave

A longo prazo, a Microsoft deseja usar o mecanismo PKCS#11 CKM_RSA_AES_KEY_WRAP para transferir a chave de destino para o Azure Key Vault, já que esse mecanismo produz um único blob e, o mais importante, a chave AES intermediária é processada por dois HSMs e tem a garantia de ser efêmera. Este mecanismo não está disponível atualmente em alguns HSMs, mas a combinação de proteger a chave de destino com CKM_AES_KEY_WRAP_PAD usando uma chave AES e proteger a chave AES com CKM_RSA_PKCS_OAEP produz um blob equivalente.

O texto não criptografado da chave de destino depende do tipo de chave:

  • Para uma chave RSA, a chave privada ASN.1 com codificação DER [RFC3447] encapsulada em PKCS nº 8 [RFC5208]
  • Para uma chave EC, a chave privada ASN.1 com codificação DER [RFC5915] encapsulada no PKCS nº 8 [RFC5208]
  • Para uma chave de octeto, os bytes brutos da chave

Os bytes da chave de texto não criptografado são transformados usando o mecanismo CKM_RSA_AES_KEY_WRAP:

  • Uma chave AES efêmera é gerada e criptografada com a chave RSA de encapsulamento usando RSA-OAEP com SHA1.
  • A chave codificada de texto não criptografado é criptografada por meio da chave AES que usa o Encapsulamento de Chave AES com Preenchimento.
  • A chave AES criptografada e a chave de texto não criptografado criptografada são concatenadas para produzir o blob de texto cifrado final.

O formato do blob de transferência usa a serialização compacta de Criptografia da Web JSON (RFC7516) basicamente como um veículo para entregar ao serviço os metadados necessários para a descriptografia correta.