Configurar ByOK (Traga sua própria chave)

  • 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).

A seguir estão os requisitos:

  • A chave a ser transferida nunca existe fora de um HSM no 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
Chave de Troca de Criptografia (KEK) RSA Azure Key Vault HSM Um par de chaves RSA suportado por 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 Chave (KEK): Esta é uma chave gerada pelo cliente com suporte HSM, dentro do cofre de chaves, destinada à 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.
  • 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 KEK.
  2. Recupere a chave pública do KEK.
  3. Usando a ferramenta BYOK fornecida pelo fornecedor de HSM, importe o KEK para o HSM de destino e exporte a Chave de Destino protegida pela KEK.
  4. Importe a chave de destino protegida para o Azure Key Vault.

Os clientes usam a ferramenta BYOK e a documentação fornecidas 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 na chave que eles gerenciam, incluindo:

  • O HSM pode precisar ser configurado para permitir a exportação baseada em encapsulamento de chave
  • A chave de destino pode precisar ser marcada atributo Cryptoki (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 encapsular chaves no HSM.

A configuração do HSM de origem está, em geral, fora do escopo dessa especificação. A Microsoft espera que o fornecedor de HSM produza documentação acompanhando sua ferramenta BYOK para incluir essas 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 SDK do Key Vault.

Gerar KEK

Use o comando az keyvault key create para criar KEK com operações de chave definidas para importação. Anote o identificador principal 'kid' retornado pelo 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 kek; O SQL do Azure, por exemplo, só dá suporte a comprimentos de chave de 2048 ou 3072 bytes.

Recuperar a chave pública do KEK

Baixe a parte da 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 chave usando a ferramenta BYOK fornecida pelo fornecedor de HSM

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

Blob de Transferência de Chaves

A longo prazo, a Microsoft gostaria de usar o mecanismo de CKM_RSA_AES_KEY_WRAP PKCS nº 11 para transferir a chave de destino para o Azure Key Vault, pois esse mecanismo produz um único blob e, mais importante, a chave AES intermediária é manipulada pelos dois HSMs e é garantida como efêmera. Esse 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 puro da chave de destino depende do tipo de chave:

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

Os bytes da chave de texto sem formatação 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 de texto claro codificada é criptografada com a chave AES utilizando o Envoltório 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 criptografado final.

O formato do blob de transferência utiliza a serialização compacta de Criptografia Web JSON (RFC7516) principalmente como meio de entregar os metadados necessários ao serviço para a correta descriptografia.