Przynieś własną specyfikację klucza

W tym dokumencie opisano specyfikacje dotyczące importowania kluczy chronionych przez moduł HSM z lokalnych modułów HSM klientów do usługi Key Vault.

Scenariusz

Klient usługi Key Vault chce bezpiecznie przenieść klucz z lokalnego modułu HSM spoza platformy Azure do modułu HSM opartego na usłudze Azure Key Vault. Proces importowania klucza wygenerowanego poza usługą Key Vault jest określany jako Bring Your Own Key (BYOK).

Poniżej przedstawiono wymagania:

• Klucz, który ma zostać przeniesiony, nigdy nie istnieje poza modułem HSM w postaci zwykłego tekstu.
• Poza modułem HSM klucz, który ma zostać przeniesiony, jest zawsze chroniony przez klucz przechowywany w module HSM usługi Azure Key Vault

Terminologia

Klucz wymiany kluczy: klucz oparty na module HSM generowany przez klienta w magazynie kluczy, w którym jest importowany klucz BYOK. Ten klucz KEK musi mieć następujące właściwości:

• Jest to klucz RSA-HSM (4096-bitowy lub 3072-bitowy lub 2048-bitowy)
• Ma stałą key_ops (TYLKO import), która umożliwia jej używanie tylko podczas byOK
• Musi znajdować się w tym samym sejfie, w którym klucz docelowy jest importowany.

Kroki użytkownika

Aby wykonać transfer klucza, użytkownik wykonuje następujące czynności:

1. Generowanie klucza KEK.
2. Pobierz klucz publiczny klucza KEK.
3. Użycie dostawcy MODUŁU HSM dostarczonego przez narzędzie BYOK — zaimportuj klucz KEK do docelowego modułu HSM i eksportuje klucz docelowy chroniony przez klucz KEK.
4. Zaimportuj chroniony klucz docelowy do usługi Azure Key Vault.

Klienci używają narzędzia BYOK i dokumentacji dostarczonej przez dostawcę modułu HSM, aby wykonać kroki 3. Tworzy obiekt blob transferu kluczy (plik ".byok").

Ograniczenia modułu HSM

Istniejący moduł HSM może stosować ograniczenia dotyczące klucza, którymi zarządzają, w tym:

• Może być konieczne skonfigurowanie modułu HSM w celu zezwolenia na eksportowanie oparte na zawijanie kluczy
• Może być konieczne oznaczenie klucza docelowego jako CKA_EXTRACTABLE, aby moduł HSM umożliwił kontrolowany eksport.
• W niektórych przypadkach klucz KEK i klucz opakowujące mogą być oznaczone jako CKA_TRUSTED, co umożliwia jego użycie do opakowowania kluczy w module HSM.

Konfiguracja źródłowego modułu HSM jest ogólnie spoza zakresu tej specyfikacji. Firma Microsoft oczekuje, że dostawca modułu HSM utworzy dokumentację dołączącą do narzędzia BYOK, aby uwzględnił wszelkie takie kroki konfiguracji.

Generowanie klucza KEK

Użyj polecenia az keyvault key create, aby utworzyć klucz KEK z operacjami klucza ustawionymi na import. Zanotuj identyfikator klucza "kid" zwrócony z tego polecenia.

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

Pobieranie klucza publicznego klucza szyfrowania kluczy

Pobierz część klucza publicznego klucza kluczy publicznych i zapisz ją w pliku PEM.

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

Generowanie obiektu blob transferu kluczy przy użyciu dostawcy modułu HSM dostarczonego przez narzędzie BYOK

Klient używa dostawcy modułu HSM dostarczonego przez narzędzie BYOK, aby utworzyć obiekt blob transferu kluczy (przechowywany jako plik ".byok"). Klucz publiczny KEK (jako plik pem) jest jednym z danych wejściowych tego narzędzia.

Obiekt blob transferu kluczy

W dłuższej perspektywie firma Microsoft chce użyć mechanizmu PKCS#11 CKM_RSA_AES_KEY_WRAP w celu przeniesienia klucza docelowego do usługi Azure Key Vault, ponieważ ten mechanizm produkuje pojedynczy blob i, co ważniejsze, klucz AES pośredni jest obsługiwany przez dwa moduły HSM i jest gwarantowany jako efemeryczny. Ten mechanizm nie jest obecnie dostępny w niektórych modułach HSM, ale ochrona klucza docelowego za pomocą CKM_AES_KEY_WRAP_PAD z użyciem klucza AES oraz ochrona klucza AES używając CKM_RSA_PKCS_OAEP tworzy równoważny blob.

Klucz docelowy w postaci zwykłego tekstu zależy od typu klucza:

• Dla klucza RSA, kodowanie ASN.1 DER klucza prywatnego [RFC3447] zawinięte w PKCS#8 [RFC5208]
• W przypadku klucza EC kodowanie ASN.1 DER klucza prywatnego [RFC5915] opakowane w PKCS#8 [RFC5208]
• W przypadku klucza oktetu, to surowe bajty klucza.

Bajty klucza zwykłego tekstu są następnie przekształcane przy użyciu mechanizmu CKM_RSA_AES_KEY_WRAP:

• Jednorazowy klucz AES jest generowany i szyfrowany przy użyciu opakowującego klucza RSA z wykorzystaniem RSA-OAEP i algorytmu SHA1.
• Zakodowany klucz zwykłego tekstu jest szyfrowany przy użyciu klucza AES przy użyciu zawijania klucza AES z wypełnieniem.
• Zaszyfrowany klucz AES i zaszyfrowany klucz zwykłego tekstu są łączone w celu utworzenia końcowego obiektu blob szyfrowania.

Format transferu obiektu blob używa kompaktowej serializacji JSON Web Encryption (RFC7516) głównie jako środka do dostarczania wymaganych metadanych do usługi w celu poprawnego odszyfrowania.

Jeśli CKM_RSA_AES_KEY_WRAP_PAD jest używany, serializacja JSON bloba transferowego będzie:

{
  "schema_version": "1.0.0",
  "header":
  {
    "kid": "<key identifier of the KEK>",
    "alg": "dir",
    "enc": "CKM_RSA_AES_KEY_WRAP"
  },
  "ciphertext":"BASE64URL(<ciphertext contents>)",
  "generator": "BYOK tool name and version; source HSM name and firmware version"
}

• kid = kluczowy identyfikator KEK. W przypadku kluczy Key Vault wygląda to następująco: https://ContosoKeyVaultHSM.vault.azure.net/keys/mykek/eba63d27e4e34e028839b53fac905621
• alg = algorytm.
• dir = tryb bezpośredni, czyli, przywoływany identyfikator klucza jest używany do bezpośredniej ochrony tekstu zaszyfrowanego, stanowiący dokładną reprezentację CKM_RSA_AES_KEY_WRAP
• generator = pole informacyjne, które określa nazwę i wersję narzędzia BYOK oraz producenta i modelu źródłowego modułu HSM. Te informacje są przeznaczone do użycia w rozwiązywaniu problemów i obsłudze technicznej.

Obiekt blob danych JSON jest przechowywany w pliku z rozszerzeniem ".byok", dzięki czemu klient programu Azure PowerShell lub CLI traktuje go poprawnie, gdy są używane polecenia takie jak "Add-AzKeyVaultKey" (PSH) lub "az keyvault key import" (CLI).

Przekazywanie obiektu blob transferu kluczy w celu zaimportowania klucza HSM

Klienci przenoszą plik Blob Transfer Klucza (".byok") na pracującą stację roboczą, a następnie uruchamiają polecenie az keyvault key import, aby zaimportować ten obiekt blob jako nowy klucz wspierany przez HSM do Key Vault.

Aby zaimportować klucz RSA, użyj następującego polecenia:

az keyvault key import --vault-name ContosoKeyVaultHSM --name ContosoFirstHSMkey --byok-file KeyTransferPackage-ContosoFirstHSMkey.byok --ops encrypt decrypt

Aby zaimportować klucz EC, należy określić typ klucza i nazwę krzywej.

az keyvault key import --vault-name ContosoKeyVaultHSM --name ContosoFirstHSMkey --byok-file --kty EC-HSM --curve-name "P-256" KeyTransferPackage-ContosoFirstHSMkey.byok --ops sign verify

Po wykonaniu tego polecenia powoduje wysłanie żądania interfejsu API REST w następujący sposób:

PUT https://contosokeyvaulthsm.vault.azure.net/keys/ContosoFirstHSMKey?api-version=7.0

Treść żądania podczas importowania klucza RSA:

{
  "key": {
    "kty": "RSA-HSM",
    "key_ops": [
      "decrypt",
      "encrypt"
    ],
    "key_hsm": "<Base64 encoded BYOK_BLOB>"
  },
  "attributes": {
    "enabled": true
  }
}

Treść żądania podczas importowania klucza EC:

{
  "key": {
    "kty": "EC-HSM",
    "crv": "P-256",
    "key_ops": [
      "sign",
      "verify"
    ],
    "key_hsm": "<Base64 encoded BYOK_BLOB>"
  },
  "attributes": {
    "enabled": true
  }
}

Wartość "key_hsm" to cała zawartość klucza KeyTransferPackage-ContosoFirstHSMkey.byok zakodowana w formacie Base64.

Źródła

• Przewodnik dewelopera usługi Key Vault

Dalsze kroki

• Instrukcje krok po kroku BYOK: Importowanie kluczy chronionych przez moduł HSM do usługi Key Vault (BYOK)