Configurar Bring your own key (BYOK)

  • 7 minutos

Cenário

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

Os requisitos são os seguintes:

  • A chave a ser transferida nunca existe fora de um HSM em formato de texto simples.
  • Fora de um HSM, a chave a ser transferida é sempre protegida por uma chave mantida no HSM do Cofre de Chaves do Azure.

Terminologia

Nome da chave Tipo de chave Origem Descrição
Chave de troca de chaves (KEK) RSA Azure Key Vault HSM Um par de chaves RSA com suporte de HSM gerado no Azure Key Vault
Chave de embrulho 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 gerada pelo cliente, apoiada por HSM, dentro do cofre de chaves destinado à importação da chave BYOK (Bring Your Own Key). O KEK deve ter as seguintes propriedades:

  • Deve ser uma chave RSA-HSM, com um tamanho de 4096 bits, 3072 bits ou 2048 bits.
  • As suas principais operações (key_ops) limitam-se à «importação», permitindo a sua utilização exclusivamente durante o processo BYOK.
  • Ele deve residir no mesmo cofre onde a chave de destino deve ser importada.

Etapas do usuário

Para realizar uma transferência de chaves:

  1. Gere o KEK.
  2. Recupere a chave pública do KEK.
  3. Usando a ferramenta BYOK fornecida pelo fornecedor HSM, importe o KEK para o HSM de destino e exporte a chave de destino protegida pelo KEK.
  4. Importe a Chave de Destino protegida para o Cofre de Chaves do Azure.

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

Restrições de HSM

O HSM existente pode aplicar restrições à chave que gerencia, incluindo:

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

A configuração do HSM de origem está, geralmente, fora do escopo desta especificação. A Microsoft espera que o fornecedor do HSM produza documentação que acompanhe sua ferramenta BYOK para incluir tais etapas de configuração.

Nota

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

Gerar KEK

Use o comando az keyvault key create para criar 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 suportam diferentes comprimentos KEK; O Azure SQL, por exemplo, suporta apenas comprimentos de chave de 2048 ou 3072 bytes.

Recuperar a chave pública do KEK

Faça o download da parte de chave pública do KEK e armazene-a em um arquivo PEM.

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

Gerar blob de transferência de chaves usando a ferramenta BYOK fornecida pelo fornecedor HSM

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

Blob de transferência de chave

A longo prazo, a Microsoft gostaria de usar o mecanismo PKCS#11 CKM_RSA_AES_KEY_WRAP para transferir a chave de destino para o Azure Key Vault, uma vez que esse mecanismo produz um único blob e, mais importante, a chave AES intermediária é manipulada pelos dois HSMs e é garantidamente efêmera. Esse mecanismo não está atualmente disponível 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 sem formatação da chave de destino depende do tipo de chave:

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

Os bytes para a chave de texto simples são entã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 de texto simples codificada é criptografada usando a chave AES usando o Wrap de Chave AES com Preenchimento.
  • A chave AES criptografada e a chave de texto sem formatação criptografada são concatenadas para produzir o blob de texto cifrado final.

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