Share via

Viktiga typer, algoritmer och åtgärder

  • Artikel

Key Vault stöder två resurstyper: valv och hanterade HSM:er. Båda resurstyperna stöder olika krypteringsnycklar. En sammanfattning av nyckeltyper som stöds finns i Om nycklar.

Följande tabell visar en sammanfattning av nyckeltyper och algoritmer som stöds.

Nyckeltyper/storlekar/kurvor Kryptera/dekryptera
(Omsluta/packa upp)		 Signera/verifiera
EC-P256, EC-P256K, EC-P384, EC-P521 NA ES256
ES256K
ES384
ES512
RSA 2K, 3K, 4K RSA1_5
RSA-OAEP
RSA-OAEP-256		 PS256
PS384
PS512
RS256
RS384
RS512
RSNULL
AES 128-bitars, 256-bitars
(Endast hanterad HSM)		 AES-KW
AES-GCM
AES-CBC		 NA

EC-algoritmer

Följande algoritmidentifierare stöds med EC-HSM-nycklar

Kurvtyper

SIGNERA/VERIFIERA

  • ES256 – ECDSA för SHA-256-sammandrag och nycklar som skapats med kurvan P-256. Den här algoritmen beskrivs i RFC7518.
  • ES256K – ECDSA för SHA-256-sammandrag och nycklar som skapats med kurvan P-256K. Den här algoritmen väntar på standardisering.
  • ES384 – ECDSA för SHA-384-sammandrag och nycklar som skapats med kurva P-384. Den här algoritmen beskrivs i RFC7518.
  • ES512 – ECDSA för SHA-512-sammandrag och nycklar som skapats med kurvan P-521. Den här algoritmen beskrivs i RFC7518.

RSA-algoritmer

Följande algoritmidentifierare stöds med RSA- och RSA-HSM-nycklar

WRAPKEY/UNWRAPKEY, ENCRYPT/DECRYPT

  • RSA1_5 – nyckelkryptering för RSAES-PKCS1-V1_5 [RFC3447]
  • RSA-OAEP – RSAES med optimal asymmetrisk krypteringsutfyllnad (OAEP) [RFC3447], med standardparametrarna som anges av RFC 3447 i avsnitt A.2.1. Dessa standardparametrar använder en hashfunktion av SHA-1 och en maskgenereringsfunktion för MGF1 med SHA-1.
  • RSA-OAEP-256 – RSAES med optimal asymmetrisk krypteringsutfyllnad med hashfunktionen SHA-256 och en maskgenereringsfunktion av MGF1 med SHA-256

SIGNERA/VERIFIERA

  • PS256 – RSASSA-PSS med SHA-256 och MGF1 med SHA-256, enligt beskrivningen i RFC7518.
  • PS384 – RSASSA-PSS med SHA-384 och MGF1 med SHA-384, enligt beskrivningen i RFC7518.
  • PS512 – RSASSA-PSS med SHA-512 och MGF1 med SHA-512, enligt beskrivningen i RFC7518.
  • RS256 – RSASSA-PKCS-v1_5 med SHA-256. Det angivna sammandragsvärdet måste beräknas med SHA-256 och måste vara 32 byte långt.
  • RS384 – RSASSA-PKCS-v1_5 med SHA-384. Det angivna sammandragsvärdet måste beräknas med SHA-384 och måste vara 48 byte långt.
  • RS512 – RSASSA-PKCS-v1_5 med SHA-512. Det angivna sammandragsvärdet måste beräknas med SHA-512 och måste vara 64 byte långt.
  • RSNULL – Se RFC2437, ett specialiserat användningsfall för att aktivera vissa TLS-scenarier.

Kommentar

DigestInfo skapas på serversidan för sign-åtgärder som algoritmerna RS256, RS384 och RS512 genererar.

Symmetriska nyckelalgoritmer (endast hanterad HSM)

  • AES-KW – AES-nyckelomslutning (RFC3394).
  • AES-GCM – AES-kryptering i Galois Counter Mode (NIST SP 800-38d)
  • AES-CBC – AES-kryptering i Kedjeläge för chifferblock (NIST SP 800-38a)

Kommentar

Signera och verifiera att algoritmer för åtgärder måste matcha nyckeltypen, annars returnerar tjänsten nyckelstorleken är felaktigt fel.

Nyckelåtgärder

Key Vault, inklusive Managed HSM, stöder följande åtgärder för nyckelobjekt:

  • Skapa: Gör att en klient kan skapa en nyckel i Key Vault. Värdet för nyckeln genereras av Key Vault och lagras och släpps inte till klienten. Asymmetriska nycklar kan skapas i Key Vault.
  • Import: Tillåter att en klient importerar en befintlig nyckel till Key Vault. Asymmetriska nycklar kan importeras till Key Vault med flera olika förpackningsmetoder i en JWK-konstruktion.
  • Uppdatering: Tillåter en klient med tillräcklig behörighet att ändra metadata (nyckelattribut) som är associerade med en nyckel som tidigare lagrats i Key Vault.
  • Ta bort: Tillåter att en klient med tillräcklig behörighet tar bort en nyckel från Key Vault.
  • Lista: Tillåter att en klient visar alla nycklar i ett visst Nyckelvalv.
  • Listversioner: Tillåter att en klient visar en lista över alla versioner av en viss nyckel i ett visst Nyckelvalv.
  • Hämta: Tillåter att en klient hämtar de offentliga delarna av en viss nyckel i ett Nyckelvalv.
  • Säkerhetskopiering: Exporterar en nyckel i ett skyddat formulär.
  • Återställ: Importerar en tidigare säkerhetskopierad nyckel.
  • Version: Den släpper säkert en nyckel till auktoriserad kod som körs i en konfidentiell beräkningsmiljö. Det kräver ett attestering att den betrodda körningsmiljön (TEE) uppfyller kraven för nyckelns release_policy.
  • Rotera: Rotera en befintlig nyckel genom att generera en ny version av nyckeln (endast Key Vault).

Mer information finns i Nyckelåtgärder i KEY Vault REST API-referensen.

När en nyckel har skapats i Key Vault kan följande kryptografiska åtgärder utföras med hjälp av nyckeln:

  • Signera och verifiera: Strikt är den här åtgärden "sign hash" eller "verify hash", eftersom Key Vault inte stöder hashning av innehåll när signaturen skapas. Program bör hash-data som ska signeras lokalt och sedan begära att Key Vault signerar hashen. Verifiering av signerade hashvärden stöds som en bekvämlighetsåtgärd för program som kanske inte har åtkomst till [offentligt] nyckelmaterial. För bästa programprestanda bör VERIFIERA åtgärder utföras lokalt.
  • Nyckelkryptering/omslutning: En nyckel som lagras i Key Vault kan användas för att skydda en annan nyckel, vanligtvis en symmetrisk innehållskrypteringsnyckel (CEK). När nyckeln i Key Vault är asymmetrisk används nyckelkryptering. Till exempel motsvarar RSA-OAEP- och WRAPKEY/UNWRAPKEY-åtgärderna ENCRYPT/DECRYPT. När nyckeln i Key Vault är symmetrisk används nyckelomslutning. Till exempel AES-KW. WRAPKEY-åtgärden stöds som en bekvämlighet för program som kanske inte har åtkomst till [offentligt] nyckelmaterial. För bästa programprestanda bör WRAPKEY-åtgärder utföras lokalt.
  • Kryptera och dekryptera: En nyckel som lagras i Key Vault kan användas för att kryptera eller dekryptera ett enda datablock. Storleken på blocket bestäms av nyckeltypen och den valda krypteringsalgoritmen. Krypteringsåtgärden tillhandahålls för enkelhetens skull för program som kanske inte har åtkomst till [offentligt] nyckelmaterial. För bästa programprestanda bör ENCRYPT-åtgärder utföras lokalt.

Även om WRAPKEY/UNWRAPKEY med asymmetriska nycklar kan verka överflödig (eftersom åtgärden motsvarar ENCRYPT/DECRYPT) är det viktigt att använda distinkta åtgärder. Skillnaden ger semantisk och auktoriseringsavgränsning av dessa åtgärder och konsekvens när andra nyckeltyper stöds av tjänsten.

Key Vault stöder inte EXPORT-åtgärder. När en nyckel har etablerats i systemet kan den inte extraheras eller dess nyckelmaterial ändras. Användare av Key Vault kan dock kräva sin nyckel för andra användningsfall, till exempel efter att den har tagits bort. I det här fallet kan de använda åtgärderna BACKUP och RESTORE för att exportera/importera nyckeln i ett skyddat formulär. Nycklar som skapats av säkerhetskopieringsåtgärden kan inte användas utanför Key Vault. Alternativt kan importåtgärden användas mot flera Key Vault-instanser.

Användare kan begränsa någon av de kryptografiska åtgärder som Key Vault stöder per nyckel med hjälp av egenskapen key_ops för JWK-objektet.

Mer information om JWK-objekt finns i JSON Web Key (JWK).

Principåtgärder för nyckelrotation

Automatisk rotation av nyckelvalv kan ställas in genom att konfigurera principen för automatisk rotation av nycklar. Den är endast tillgänglig på Key Vault-resursen.

  • Hämta rotationsprincip: Hämta rotationsprincipkonfiguration.
  • Ange rotationsprincip: Ange konfiguration av rotationsprincip.

Nyckelattribut

Utöver nyckelmaterialet kan följande attribut anges. I en JSON-begäran krävs attributen nyckelord och klammerparenteser, {' '}', även om det inte finns några angivna attribut.

  • aktiverat: booleskt, valfritt, standardvärdet är sant. Anger om nyckeln är aktiverad och användbar för kryptografiska åtgärder. Det aktiverade attributet används med nbf och exp. När en åtgärd inträffar mellan nbf och exp tillåts den endast om aktiverad är inställd på true. Åtgärder utanför nbf-exp-fönstret / tillåts automatiskt, förutom dekryptera, släppa, packa upp och verifiera.
  • nbf: IntDate, valfritt, standard är nu. Attributet nbf (inte före) identifierar den tid innan nyckeln INTE får användas för kryptografiska åtgärder, förutom dekryptera , släppa, packa upp och verifiera. Bearbetningen av attributet nbf kräver att aktuellt datum/tid MÅSTE vara efter eller lika med det datum/den tid som anges i attributet nbf . Key Vault KAN ge ett litet spelrum, vanligtvis inte mer än några minuter, för att ta hänsyn till klocksnedställning. Dess värde MÅSTE vara ett tal som innehåller ett IntDate-värde.
  • exp: IntDate, valfritt, standard är "forever". Attributet exp (förfallotid) identifierar förfallotiden på eller efter vilken nyckeln INTE får användas för kryptografisk åtgärd, förutom dekryptera, släppa, packa upp och verifiera. Bearbetningen av exp-attributet kräver att aktuellt datum/tid MÅSTE före förfallodatum/tid som anges i exp-attributet . Key Vault KAN ge ett litet spelrum, vanligtvis inte mer än några minuter, för att ta hänsyn till klocksnedvridning. Dess värde MÅSTE vara ett tal som innehåller ett IntDate-värde.

Det finns fler skrivskyddade attribut som ingår i alla svar som innehåller nyckelattribut:

  • skapad: IntDate, valfritt. Det skapade attributet anger när den här versionen av nyckeln skapades. Värdet är null för nycklar som skapats innan det här attributet läggs till. Dess värde MÅSTE vara ett tal som innehåller ett IntDate-värde.
  • uppdaterad: IntDate, valfritt. Det uppdaterade attributet anger när den här versionen av nyckeln uppdaterades. Värdet är null för nycklar som senast uppdaterades innan attributet lades till. Dess värde MÅSTE vara ett tal som innehåller ett IntDate-värde.
  • hsmPlatform: sträng, valfritt. Den underliggande HSM-plattformen som skyddar en nyckel.
    • Ett hsmPlatform-värde på 2 innebär att nyckeln skyddas av vår senaste FIPS 140 Level 3-verifierade HSM-plattform.
    • Ett hsmPlatform-värde på 1 innebär att nyckeln skyddas av vår tidigare FIPS 140 Level 2-verifierade HSM-plattform.
    • Ett hsmPlatform-värde på 0 innebär att nyckeln skyddas av en FIPS 140 HSM-programvarukrypteringsmodul på nivå 1.
    • Om detta inte anges av en hanterad HSM-pool skyddas den av vår senaste FIPS 140 Level 3-verifierade HSM-plattform.

Det är viktigt att observera att nycklarna är bundna till den HSM där de skapades. Nya nycklar skapas och lagras sömlöst i de nya HSM:erna. Det finns inget sätt att migrera eller överföra nycklar, men nya nyckelversioner finns automatiskt i de nya HSM:erna. Mer information om hur du migrerar till en ny nyckel finns i Så här migrerar du nyckelarbetsbelastningar.

Mer information om IntDate och andra datatyper finns i [Om nycklar, hemligheter och certifikat: Datatyper.

Datum-tidskontrollerade åtgärder

Nycklar som ännu inte är giltiga och har upphört att gälla, utanför nbf-exp-fönstret / , fungerar för dekryptera, släppa, packa upp och verifiera åtgärder (returnerar inte 403, Förbjudet). Anledningen till att använda det ännu inte giltiga tillståndet är att tillåta att en nyckel testas före produktionsanvändning. Anledningen till att använda det utgångna tillståndet är att tillåta återställningsåtgärder för data som skapades när nyckeln var giltig. Du kan också inaktivera åtkomst till en nyckel med hjälp av Key Vault-principer eller genom att uppdatera det aktiverade nyckelattributet till false.

Mer information om datatyper finns i Datatyper.

Mer information om andra möjliga attribut finns i JSON-webbnyckeln (JWK).

Nyckeltaggar

Du kan ange mer programspecifika metadata i form av taggar. Key Vault stöder upp till 15 taggar, som var och en kan ha ett namn på 256 tecken och ett värde på 256 tecken.

Kommentar

Taggar kan läsas av en uppringare om de har listan eller får behörighet till den nyckeln.

Nyckelåtkomstkontroll

Åtkomstkontroll för nycklar som hanteras av Key Vault tillhandahålls på nivån för ett Nyckelvalv som fungerar som container för nycklar. Du kan styra åtkomsten till nycklar med rollbaserad åtkomstkontroll i Key Vault (rekommenderas) eller en gammal behörighetsmodell för valvåtkomstprincip. Rollbaserad behörighetsmodell har tre fördefinierade roller för att hantera nycklar: "Key Vault Crypto Officer", "Key Vault Crypto User", "Key Vault Service Encryption User" och kan begränsas till prenumeration, resursgrupp eller valvnivå.

Behörigheter för behörighetsmodell för valvåtkomstprincip:

  • Behörigheter för nyckelhanteringsåtgärder

    • get: Läs den offentliga delen av en nyckel, plus dess attribut
    • list: Visa en lista över nycklar eller versioner av en nyckel som lagras i ett nyckelvalv
    • update: Uppdatera attributen för en nyckel
    • skapa: Skapa nya nycklar
    • import: Importera en nyckel till ett nyckelvalv
    • ta bort: Ta bort nyckelobjektet
    • återställ: Återställa en borttagen nyckel
    • säkerhetskopiering: Säkerhetskopiera en nyckel i ett nyckelvalv
    • återställning: Återställa en säkerhetskopierad nyckel till ett nyckelvalv

  • Behörigheter för kryptografiska åtgärder

    • dekryptera: Använd nyckeln för att ta bort skyddet för en sekvens med byte
    • kryptera: Använd nyckeln för att skydda en godtycklig sekvens med byte
    • unwrapKey: Använd nyckeln för att ta bort skyddet av omslutna symmetriska nycklar
    • wrapKey: Använd nyckeln för att skydda en symmetrisk nyckel
    • verifiera: Använd nyckeln för att verifiera sammandrag
    • sign: Använd nyckeln för att signera sammandrag

  • Behörigheter för privilegierade åtgärder

    • rensa: Rensa (ta bort permanent) en borttagen nyckel
    • release: Släpp en nyckel till en konfidentiell beräkningsmiljö som matchar nyckelns release_policy

  • Behörigheter för rotationsprincipåtgärder

    • rotera: Rotera en befintlig nyckel genom att generera en ny version av nyckeln (endast Key Vault)
    • hämta rotationsprincip: Hämta rotationsprincipkonfiguration
    • ange rotationsprincip: Ange rotationsprincipkonfiguration

Mer information om hur du arbetar med nycklar finns i Nyckelåtgärder i KEY Vault REST API-referensen.

Nästa steg