Configurer Bring your own key (BYOK)

  • 7 minutes

Scénario

Un client de Key Vault souhaite transférer en toute sécurité une clé à partir de son HSM local vers l'HSM soutenant Azure Key Vault. Le processus d’importation d’une clé générée en dehors du coffre de clés est appelé BYOK (Bring Your Own Key).

Voici les conditions requises :

  • La clé à transférer n’existe jamais en dehors d’un HSM sous forme de texte brut.
  • En dehors d’un HSM, la clé à transférer est toujours protégée par une clé conservée dans le HSM Azure Key Vault.

Terminologie

Nom de Clé type de clé Origine Description
Clé d’échange de clés (KEK) RSA Azure Key Vault HSM Paire de clés RSA sauvegardée par HSM générée dans Azure Key Vault
Clé d'encapsulation AES Fournisseur HSM Clé AES [éphémère] générée par un HSM local
Clé cible RSA, EC, AES (HSM managé uniquement) HSM fournisseur La clé à transférer vers le Key Vault HSM d'Azure

Clé d'échange (KEK): il s’agit d’une clé générée par le client et soutenue par un HSM dans le coffre à clés, destinée à l'importation de la clé BYOK (Bring Your Own Key). La clé KEK doit avoir les propriétés suivantes :

  • Il doit s’agir d’une clé RSA-HSM, avec une taille de 4096 bits, 3072 bits ou 2048 bits.
  • Ses opérations clés (key_ops) sont limitées à « importer », ce qui permet son utilisation exclusivement pendant le processus BYOK.
  • Il doit résider dans le même coffre où la clé cible doit être importée.

Étapes de l’utilisateur

Pour effectuer un transfert de clé :

  1. Générez KEK.
  2. Récupérez la clé publique du KEK.
  3. À l’aide de l'outil BYOK fourni par le fabricant HSM, importez le KEK dans le HSM cible et exportez la clé cible protégée par le KEK.
  4. Importez la clé cible protégée dans Azure Key Vault.

Les clients utilisent l’outil BYOK et la documentation fournies par le fournisseur HSM pour effectuer les étapes 3. Il produit un objet blob de transfert de clés (un fichier ".byok").

Contraintes HSM

Le HSM existant peut appliquer des contraintes sur la clé qu'il gère, notamment :

  • Le HSM peut avoir besoin d’être configuré pour autoriser l’exportation basée sur l'enveloppement de clé.
  • La clé cible peut avoir besoin d’être marquée l’attribut Cryptoki (CKA)_EXTRACTABLE pour que le module HSM autorise l’exportation contrôlée
  • Dans certains cas, la clé KEK et la clé d’habillage doivent être marquées comme CKA_TRUSTED, ce qui lui permet d’être utilisée pour encapsuler les clés dans le HSM.

La configuration du HSM source est généralement en dehors de l’étendue de cette spécification. Microsoft s’attend à ce que le fournisseur HSM produise de la documentation qui accompagne son outil BYOK pour inclure toutes ces étapes de configuration.

Note

Plusieurs de ces étapes peuvent être effectuées à l’aide d’autres interfaces telles qu’Azure PowerShell et le portail Azure. Elles peuvent également être effectuées par programmation à l’aide de fonctions équivalentes dans le Kit de développement logiciel (SDK) Key Vault.

Générer une clé KEK

Utilisez la commande az keyvault key create pour créer un KEK avec les opérations de clé définies sur l'importation. Notez l’identificateur de clé « kid » retourné par la commande ci-dessous.

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

Les services prennent en charge différentes longueurs KEK ; Azure SQL, par exemple, prend uniquement en charge les longueurs de clé de 2048 ou 3072 octets.

Récupérer la clé publique du KEK

Téléchargez la partie clé publique du KEK et stockez-la dans un fichier PEM.

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

Générer un blob de transfert de clé en utilisant l’outil BYOK fourni par le fournisseur HSM.

Utilisez l’outil BYOK fourni par le fournisseur HSM pour créer un objet blob de transfert de clés (stocké sous forme de fichier .byok). La clé publique KEK, sous forme de .Privacy-Enhanced courrier électronique (fichier .pem), sera l'une des entrées de cet outil.

Blob de transfert de clé

À long terme, Microsoft souhaite utiliser le mécanisme de CKM_RSA_AES_KEY_WRAP PKCS#11 pour transférer la clé cible vers Azure Key Vault, car ce mécanisme produit un objet blob unique et, plus important encore, la clé AES intermédiaire est gérée par les deux modules HSM et est garantie d’être éphémère. Ce mécanisme n’est actuellement pas disponible dans certains modules HSM, mais la combinaison de la protection de la clé cible avec CKM_AES_KEY_WRAP_PAD à l’aide d’une clé AES et de la protection de la clé AES avec CKM_RSA_PKCS_OAEP produit un objet blob équivalent.

Le texte en clair de la clé cible dépend du type de clé :

  • Pour une clé RSA, l’encodage DER ASN.1 de la clé privée [RFC3447] encapsulé dans PKCS#8 [RFC5208]
  • Pour une clé EC, l’encodage DER ASN.1 de clé privée [RFC5915] encapsulé dans PKCS#8 [RFC5208]
  • Pour une clé d’octet, octets bruts de la clé

Les octets de la clé en texte clair sont ensuite transformés à l’aide du mécanisme de CKM_RSA_AES_KEY_WRAP :

  • Une clé AES éphémère est générée et chiffrée avec la clé RSA encapsulée à l’aide de RSA-OAEP avec SHA1.
  • La clé en texte clair encodée est chiffrée avec la clé AES en utilisant AES Key Wrap avec remplissage.
  • La clé AES chiffrée et la clé en texte clair chiffrée sont concaténées pour produire l’objet blob de texte chiffré final.

Le format de l’objet blob de transfert utilise la sérialisation compacte JSON Web Encryption (RFC7516) principalement comme moyen de remettre les métadonnées requises au service pour le déchiffrement correct.