Konfigurera BYOK (Bring Your Own Key)

  • 7 minuter

Scenario

En Key Vault-kund vill på ett säkert sätt överföra en nyckel från sin lokala maskinvarusäkerhetsmodul (HSM) utanför Azure till HSM som stöder Azure Key Vault. Processen för att importera en nyckel som genereras utanför Key Vault kallas BYOK (Bring Your Own Key).

Följande är kraven:

  • Nyckeln som ska överföras finns aldrig utanför en HSM i oformaterad textform.
  • Utanför en HSM skyddas nyckeln som ska överföras alltid av en nyckel som finns i Azure Key Vault HSM.

Terminologi

Nyckelnamn Nyckeltyp Ursprung Beskrivning
Nyckelutbytesnyckel (KEK) RSA Azure Key Vault HSM Ett HSM-säkerhetskopierat RSA-nyckelpar som genererats i Azure Key Vault
Omslutningsnyckel AES Leverantörs-HSM En [tillfällig] AES-nyckel som genereras av HSM lokalt
Målnyckel RSA, EC, AES (endast hanterad HSM) Leverantörs-HSM Nyckeln som ska överföras till Azure Key Vault HSM

Nyckelutbytesnyckel (KEK): Det här är en kundgenererad HSM-backad nyckel i nyckelvalvet som är avsedd för import av BYOK-nyckeln (Bring Your Own Key). KEK:et bör ha följande egenskaper:

  • Det måste vara en RSA-HSM-nyckel med storleken 4 096 bitar, 3 072 bitar eller 2 048 bitar.
  • Dess nyckelåtgärder (key_ops) är begränsade till "import", vilket endast tillåter användning under BYOK-processen.
  • Den måste finnas i samma valv där målnyckeln ska importeras.

Användarsteg

Så här utför du en nyckelöverföring:

  1. Generera KEK.
  2. Hämta den offentliga nyckeln för KEK.
  3. Med hjälp av HSM-leverantören som tillhandahålls av BYOK-verktyget importerar du KEK till mål-HSM och exporterar målnyckeln som skyddas av KEK.
  4. Importera den skyddade målnyckeln till Azure Key Vault.

Kunder använder BYOK-verktyget och dokumentationen från HSM-leverantören för att slutföra steg 3. Den skapar en nyckelöverföringsblob (en ".byok"-fil).

HSM-begränsningar

Den befintliga HSM:en kan tillämpa begränsningar för nyckel som de hanterar, inklusive:

  • HSM kan behöva konfigureras för att tillåta nyckelomslutningsbaserad export
  • Målnyckeln kan behöva markeras med Cryptoki-attribut (CKA)_EXTRACTABLE för att HSM ska tillåta kontrollerad export
  • I vissa fall kan KEK och omslutningsnyckeln behöva markeras som CKA_TRUSTED, vilket gör att den kan användas för att omsluta nycklar i HSM.

Konfigurationen av HSM-källan ligger i allmänhet utanför omfånget för den här specifikationen. Microsoft förväntar sig att HSM-leverantören ska ta fram dokumentation som medföljer deras BYOK-verktyg för att inkludera sådana konfigurationssteg.

Kommentar

Flera av de här stegen kan utföras med hjälp av andra gränssnitt, till exempel Azure PowerShell och Azure Portal. De kan också utföras programmatiskt med motsvarande funktioner i Key Vault SDK.

Generera KEK

Använd kommandot az keyvault key create för att skapa KEK med nyckelåtgärder som ska importeras. Anteckna nyckelidentifieraren "kid" som returneras från kommandot nedan.

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

Tjänster stöder olika KEK-längder; Azure SQL har till exempel bara stöd för nyckellängder på 2 048 eller 3 072 byte.

Hämta den offentliga nyckeln för KEK

Ladda ned den offentliga nyckeldelen av KEK och lagra den i en PEM-fil.

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

Generera nyckelöverföringsblob med hjälp av HSM-leverantörens BYOK-verktyg

Använd det HSM-leverantör som tillhandahålls av BYOK-verktyget för att skapa en nyckelöverföringsblob (lagras som en ".byok"-fil). OFFENTLIG KEK-nyckel som en . Sekretessförstärkt e-postmeddelande (.pem-fil) är en av indata till det här verktyget.

Nyckelöverföringsblob

På lång sikt vill Microsoft använda PKCS#11 CKM_RSA_AES_KEY_WRAP mekanism för att överföra målnyckeln till Azure Key Vault eftersom den här mekanismen skapar en enda blob och, ännu viktigare, den mellanliggande AES-nyckeln hanteras av de två HSM:erna och garanteras vara tillfälliga. Den här mekanismen är för närvarande inte tillgänglig i vissa HSM:er, men kombinationen av att skydda målnyckeln med CKM_AES_KEY_WRAP_PAD med hjälp av en AES-nyckel och skydda AES-nyckeln med CKM_RSA_PKCS_OAEP skapar en motsvarande blob.

Målnyckelns klartext beror på nyckeltypen:

  • För en RSA-nyckel är den privata nyckeln ASN.1 DER-kodning [RFC3447] omsluten i PKCS#8 [RFC5208]
  • För en EC-nyckel är den privata nyckeln ASN.1 DER-kodning [RFC5915] omsluten i PKCS#8 [RFC5208]
  • För en oktettnyckel är nyckelns råa byte

Byte för klartextnyckeln omvandlas sedan med hjälp av mekanismen CKM_RSA_AES_KEY_WRAP:

  • En tillfällig AES-nyckel genereras och krypteras med omslutande RSA-nyckel med RSA-OAEP med SHA1.
  • Den kodade klartextnyckeln krypteras med hjälp av AES-nyckeln med hjälp av AES-nyckelomslutning med utfyllnad.
  • Den krypterade AES-nyckeln och den krypterade klartextnyckeln sammanfogas för att skapa den slutliga chifferbloben.

Formatet för överföringsbloben använder JSON Web Encryption kompakt serialisering (RFC7516) främst som ett verktyg för att leverera nödvändiga metadata till tjänsten för korrekt dekryptering.