Teilen über

Schlüsseltypen, Algorithmen und Vorgänge

  • Artikel

Key Vault unterstützt zwei Ressourcentypen: Tresore und verwaltete HSMs. Beide Typen unterstützen verschiedene Verschlüsselungsschlüssel. Eine Übersicht über die unterstützten Schlüsseltypen sowie Schutztypen für den jeweiligen Ressourcentyp finden Sie unter Informationen zu Schlüsseln.

Die folgende Tabelle fasst die Schlüsseltypen und unterstützten Algorithmen zusammen.

Schlüsseltypen/Größen/Kurven Verschlüsseln/Entschlüsseln
(Umschließen/Aufheben der Umschließung)		 Signieren/Überprüfen
EC-P256, EC-P256K, EC-P384, EC-P521 Nicht verfügbar ES256
ES256K
ES384
ES512
RSA 2K, 3K, 4K RSA1_5
RSA-OAEP
RSA-OAEP-256		 PS256
PS384
PS512
RS256
RS384
RS512
RSNULL
AES (128 Bit, 256 Bit)
(Nur verwaltetes HSM)		 AES-KW
AES-GCM
AES-CBC		 Nicht verfügbar

EC-Algorithmen

Die folgenden Algorithmusbezeichner werden mit EC-HSM-Schlüsseln unterstützt:

Kurventypen

SIGN/VERIFY

  • ES256 – ECDSA für SHA-256-Hashs und -Schlüssel, erstellt mit P-256-Kurve. Dieser Algorithmus wird im RFC 7518 beschrieben.
  • ES256K – ECDSA für SHA-256-Hashs und -Schlüssel, erstellt mit P-256K-Kurve. Bei diesem Algorithmus steht die Standardisierung noch aus.
  • ES384 – ECDSA für SHA-384-Hashs und -Schlüssel, erstellt mit P-384-Kurve. Dieser Algorithmus wird im RFC 7518 beschrieben.
  • ES512 – ECDSA für SHA-512-Hashs und -Schlüssel, erstellt mit P-521-Kurve. Dieser Algorithmus wird im RFC 7518 beschrieben.

RSA-Algorithmen

Die folgenden Algorithmusbezeichner werden mit RSA- und RSA-HSM-Schlüsseln in unterstützt:

WRAPKEY/UNWRAPKEY, ENCRYPT/DECRYPT

  • RSA1_5: RSAES-PKCS1-V1_5 [RFC3447] Schlüsselverschlüsselung
  • RSA-OAEP: RSAES unter Verwendung von Optimal Asymmetric Encryption Padding (OAEP) [RFC3447], wobei die Standardparameter durch RFC 3447 in Abschnitt A.2.1 angegeben werden. Diese Standardparameter verwenden eine Hashfunktion von SHA-1 und eine Maskengenerierungsfunktion von MGF1 mit SHA-1.
  • RSA-OAEP-256: RSAES mit OAEP (Optimal Asymmetric Encryption Padding), einer Hashfunktion vom Typ SHA-256 und einer MGF1-Maskengenerierungsfunktion mit SHA-256

SIGN/VERIFY

  • PS256: RSASSA-PSS unter Verwendung von SHA-256 und MGF1 mit SHA-256, wie in RFC7518 beschrieben.
  • PS384: RSASSA-PSS unter Verwendung von SHA-384 und MGF1 mit SHA-384, wie in RFC7518 beschrieben.
  • PS512: RSASSA-PSS unter Verwendung von SHA-512 und MGF1 mit SHA-512, wie in RFC7518 beschrieben.
  • RS256: RSASSA-PKCS-v1_5 mithilfe von SHA-256. Der von der Anwendung bereitgestellte Zusammenfassungswert muss mithilfe von SHA-256 berechnet werden und 32 Byte lang sein.
  • RS384: RSASSA-PKCS-v1_5 mithilfe von SHA-384. Der von der Anwendung bereitgestellte Zusammenfassungswert muss mithilfe von SHA-384 berechnet werden und 48 Byte lang sein.
  • RS512: RSASSA-PKCS-v1_5 mithilfe von SHA-512. Der von der Anwendung bereitgestellte Zusammenfassungswert muss mithilfe von SHA-512 berechnet werden und 64 Byte lang sein.
  • RSNULL: Siehe RFC2437. Hierbei handelt es sich um einen speziellen Anwendungsfall für bestimmte TLS-Szenarien.

Hinweis

Die DigestInfo wird auf der Serverseite für Signiervorgänge erstellt, die von den Algorithmen RS256, RS384 und RS512 generiert werden.

Algorithmen für symmetrische Schlüssel (nur verwaltetes HSM)

  • AES-KW: AES-Schlüsselverpackung (RFC3394)
  • AES-GCM: AES-Verschlüsselung im Galois-Zählermodus (NIST SP 800-38d)
  • AES-CBC: AES-Verschlüsselung im Verschlüsselungsblockverkettungs-Modus (NIST SP 800-38a)

Hinweis

Signatur- und Überprüfungsvorgangsalgorithmen müssen dem Schlüsseltyp entsprechen, da der Dienst sonst den Fehler „Falsche Schlüsselgröße“ zurückgibt.

Schlüsselvorgänge

Key Vault, einschließlich verwalteter HSM, unterstützt die folgenden Vorgänge für Schlüsselobjekte:

  • Erstellen: Ermöglicht einem Client, einen Schlüssel in Key Vault zu erstellen. Der Wert des Schlüssels wird von Key Vault generiert und gespeichert und nicht für den Client freigegeben. In Key Vault können asymmetrische Schlüssel erstellt werden.
  • Import: Ermöglicht einem Client, einen vorhandenen Schlüssel in Key Vault zu importieren. Asymmetrische Schlüssel können mithilfe mehrerer unterschiedlicher Paketerstellungsmethoden in einem JWK-Konstrukt in Key Vault importiert werden.
  • Update (Aktualisieren): Ermöglicht einem Client mit ausreichenden Berechtigungen, die Metadaten (Schlüsselattribute) zu ändern, die einem zuvor in Key Vault gespeicherten Schlüssel zugeordnet sind.
  • Löschen: Ermöglicht einem Client mit ausreichenden Berechtigungen das Löschen eines Schlüssels aus Key Vault.
  • List (Auflisten): Ermöglicht einem Client das Auflisten aller Schlüssel in einem bestimmten Schlüsseltresor.
  • List versions (Versionen auflisten): Ermöglicht einem Client das Auflisten aller Versionen eines bestimmten Schlüssels in einem bestimmten Key Vault.
  • Get (Abrufen): Ermöglicht einem Client das Abrufen des öffentlichen Teils eines bestimmten Schlüssels in einem Schlüsseltresor.
  • Backup (Sichern): Exportiert einen Schlüssel in einer geschützten Form.
  • Restore (Wiederherstellen): Importiert einen zuvor gesicherten Schlüssel.
  • Release: Gibt sicher einen Schlüssel für autorisierten Code frei, der in einer vertraulichen Compute-Umgebung ausgeführt wird. Es erfordert einen Nachweis, dass die Trusted Execution Environment (TEE) die Anforderungen der „release_policy“ des Schlüssels erfüllt.
  • Rotieren: Rotieren eines vorhandenen Schlüssels durch Generieren einer neuen Version des Schlüssels (nur Key Vault).

Weitere Informationen finden Sie unter Schlüsselvorgänge in der Referenz zur REST-API für Azure Key Vault.

Nachdem ein Schlüssel in Key Vault erstellt wurde, können die folgenden kryptografischen Vorgänge mit dem Schlüssel ausgeführt werden:

  • Sign an Verify (Signieren und überprüfen): Streng genommen handelt es sich hierbei um den Vorgang „sign hash“ (Hash signieren) oder „verify hash“ (Hash überprüfen), da Key Vault das Hashing von Inhalten im Rahmen der Signaturerstellung nicht unterstützt. Anwendungen sollten ein Hashing der Daten durchführen, die lokal signiert werden sollen, und dann anfordern, dass Key Vault den Hash signiert. Die Überprüfung signierter Hashes wird aus Gründen der Vereinfachung für Anwendungen unterstützt, die möglicherweise keinen Zugriff auf (öffentliches) Schlüsselmaterial haben. Um eine optimale Anwendungsleistung zu erzielen, sollten VERIFY-Vorgänge lokal ausgeführt werden.
  • Key Encryption / Wrapping (Verschlüsselung mit Schlüssel / Umschließen): Ein in Key Vault gespeicherter Schlüssel kann zum Schutz eines anderen Schlüssels verwendet werden. In der Regel handelt es sich dabei um einen symmetrischen Inhaltsverschlüsselungsschlüssel (Content Encryption Key, CEK). Wenn der Schlüssel in Key Vault asymmetrisch ist, wird die Schlüsselverschlüsselung verwendet. RSA-OAEP und die WRAPKEY/UNWRAPKEY-Vorgänge sind beispielsweise äquivalent zu ENCRYPT/DECRYPT. Wenn der Schlüssel in Key Vault symmetrisch ist, wird die Schlüsselumschließung verwendet. Beispiel: AES-KW. Der WRAPKEY-Vorgang wird aus Gründen der Vereinfachung für Anwendungen unterstützt, die möglicherweise keinen Zugriff auf (öffentliches) Schlüsselmaterial haben. Um eine optimale Anwendungsleistung zu erzielen, sollten WRAPKEY-Vorgänge lokal ausgeführt werden.
  • Encrypt and Decrypt (Verschlüsseln und Entschlüsseln): Ein in Key Vault gespeicherter Schlüssel kann zum Verschlüsseln oder Entschlüsseln eines einzelnen Datenblocks verwendet werden. Die Größe des Blocks wird durch den Schlüsseltyp und den ausgewählten Verschlüsselungsalgorithmus bestimmt. Der ENCRYPT-Vorgang wird aus Gründen der Vereinfachung für Anwendungen unterstützt, die möglicherweise keinen Zugriff auf (öffentliches) Schlüsselmaterial haben. Um eine optimale Anwendungsleistung zu erzielen, sollten ENCRYPT-Vorgänge lokal ausgeführt werden.

Obwohl WRAPKEY/UNWRAPKEY mit asymmetrischen Schlüsseln überflüssig erscheinen mögen (da die Vorgänge äquivalent zu ENCRYPT/DECRYPT sind), ist die Verwendung unterschiedlicher Vorgänge wichtig. Die Unterscheidung sorgt für eine semantische und autorisierungsbezogene Trennung dieser Vorgänge sowie für Konsistenz, wenn andere Schlüsseltypen vom Dienst unterstützt werden.

Key Vault unterstützt keine EXPORT-Vorgänge. Sobald ein Schlüssel im System bereitgestellt ist, kann er weder extrahiert noch sein Schlüsselmaterial geändert werden. Möglicherweise benötigen Key Vault-Benutzer ihren Schlüssel jedoch für andere Anwendungsfälle, beispielsweise nachdem er gelöscht wurde. In diesem Fall können die Vorgänge BACKUP und RESTORE verwendet werden, um den Schlüssel in geschützter Form zu exportieren und zu importieren. Vom BACKUP-Vorgang erstellte Schlüssel können außerhalb von Key Vault nicht verwendet werden. Alternativ dazu kann der IMPORT-Vorgang für mehrere Key Vault-Instanzen verwendet werden.

Benutzer können die kryptografischen Vorgänge, die Key Vault pro Schlüssel unterstützt, mithilfe der key_ops-Eigenschaft des JWK-Objekts einschränken.

Weitere Informationen zu JWK-Objekten finden Sie unter JSON Web Key (JWK).

Schlüsselrotationsrichtlinien-Vorgänge

Das automatische Rotieren von Schlüsseln im Schlüsseltresor lässt sich durch Konfigurieren der Richtlinie für die automatische Schlüsselrotation konfigurieren. Dies ist nur für Key Vault-Ressourcen verfügbar.

  • Rotationsrichtlinie abrufen: Abrufen der Rotationsrichtlinienkonfiguration.
  • Rotationsrichtlinie festlegen: Festlegen der Rotationsrichtlinienkonfiguration.

Schlüsselattribute

Zusätzlich zum Schlüsselmaterial können die folgenden Attribute angegeben werden. In einer JSON-Anforderung sind das Schlüsselwort „attributes“ und die Klammern „{“ „}“ auch dann erforderlich, wenn keine Attribute angegeben werden.

  • enabled: Boolesch, optional, Standardwert ist true. Gibt an, ob der Schlüssel aktiviert und für kryptografische Vorgänge verwendbar ist. Das enabled-Attribut wird mit nbf und exp verwendet. Wenn ein Vorgang zwischen nbf und exp auftritt, wird er nur zugelassen, wenn enabled auf true festgelegt ist. Vorgänge außerhalb des nbf / exp-Fensters werden automatisch nicht zugelassen, außer zum Entschlüsseln, Freigeben, Entpacken und Überprüfen.
  • nbf: IntDate, optional, Standardwert ist „now“. Das Attribut nbf (not before, nicht vor) gibt die Uhrzeit an, vor der der Schlüssel NICHT für kryptografische Vorgänge mit Ausnahme von Entschlüsseln, Freigeben, Entpacken und Überprüfen verwendet werden DARF. Die Verarbeitung des nbf-Attributs erfordert, dass das aktuelle Datum / die aktuelle Uhrzeit mindestens dem Wert des nbf-Attributs entsprechen MUSS. Key Vault KANN einen kleinen Spielraum von in der Regel nicht mehr als einigen wenigen Minuten einräumen, um Abweichungen der Uhr zu berücksichtigen. Der Wert MUSS eine Zahl sein, die einen IntDate-Wert enthält.
  • exp: IntDate, optional, Standardwert ist „forever“. Das Attribut exp (Ablaufzeit) gibt die Ablaufzeit an, zu bzw. nach der der Schlüssel mit Ausnahme von Entschlüsseln, Freigeben, Entpacken und Überprüfen NICHT MEHR für kryptografische Vorgänge verwendet werden DARF. Die Verarbeitung des exp-Attributs erfordert, dass das aktuelle Datum / die aktuelle Uhrzeit vor dem Wert des exp-Attributs liegen MUSS. Key Vault KANN einen kleinen Spielraum von in der Regel nicht mehr als einigen wenigen Minuten einräumen, um Abweichungen der Uhr zu berücksichtigen. Der Wert MUSS eine Zahl sein, die einen IntDate-Wert enthält.

Es gibt mehr schreibgeschützte Attribute, die in alle Antworten einbezogen werden, die Schlüsselattribute enthalten:

  • created: IntDate, optional. Das created-Attribut gibt an, wann diese Version des Schlüssels erstellt wurde. Der Wert ist NULL für Schlüssel, die vor dem Hinzufügen dieses Attributs erstellt wurden. Der Wert MUSS eine Zahl sein, die einen IntDate-Wert enthält.
  • updated: IntDate, optional. Das updated-Attribut gibt an, wann diese Version des Schlüssels aktualisiert wurde. Der Wert ist NULL für Schlüssel, die vor dem Hinzufügen dieses Attributs zuletzt aktualisiert wurden. Der Wert MUSS eine Zahl sein, die einen IntDate-Wert enthält.
  • hsmPlatform: Zeichenfolge, optional. Die zugrunde liegende HSM-Plattform, die einen Schlüssel schützt.
    • Der Wert 2 für hsmPlatform bedeutet, dass der Schlüssel durch unsere neueste, für FIPS 140 Level 3 validierte HSM-Plattform geschützt ist.
    • Der Wert 1 für hsmPlatform bedeutet, dass der Schlüssel durch unsere vorherige, für FIPS 140 Level 2 validierte HSM-Plattform geschützt ist.
    • Der Wert 0 für hsmPlatform bedeutet, dass der Schlüssel durch ein kryptografisches HSM-Softwaremodul nach FIPS 140 Level 1 geschützt ist.
    • Wenn dies nicht von einem verwalteten HSM-Pool festgelegt wird, erfolgt der Schutz durch unsere neueste, für FIPS 140 Level 3 validierte HSM-Plattform.

Es muss beachtet werden, dass Schlüssel an das HSM gebunden sind, in dem sie erstellt wurden. Neue Schlüssel werden nahtlos in den neuen HSMs erstellt und gespeichert. Obwohl es keine Möglichkeit zum Migrieren oder Übertragen von Schlüsseln gibt, befinden sich neue Schlüsselversionen automatisch in den neuen HSMs. Weitere Informationen zum Migrieren zu einem neuen Schlüssel finden Sie unter Migrieren von Schlüsselworkloads.

Weitere Informationen zu IntDate und anderen Datentypen finden Sie unter „Informationen zu Schlüsseln, Geheimnissen und Zertifikaten“ im Abschnitt Datentypen.

Durch Datum und Uhrzeit gesteuerte Vorgänge

Noch nicht gültige und abgelaufene Schlüssel, die außerhalb des nbf / exp-Fensters liegen, funktionieren in Entschlüsselungs (decrypt)-, Freigabe (Release)-, Entpack (unwrap)- und Überprüfungs (verify)-Vorgängen (keine Rückgabe von „403 – Verboten“). Grund für die Verwendung des „Noch-nicht-gültig“-Status ist, den Test eines Schlüssels vor der Verwendung in der Produktion zu ermöglichen. Grund für die Verwendung des abgelaufenen Zustands ist, Wiederherstellungsvorgänge bei Daten zu ermöglichen, die erstellt wurden, als der Schlüssel gültig war. Sie können den Zugriff auf einen Schlüssel auch mittels Key Vault-Richtlinien oder durch Aktualisieren des enabled-Schlüsselattributs mit false deaktivieren.

Weitere Informationen zu Datentypen finden Sie unter Datentypen.

Weitere Informationen zu anderen möglichen Attributen finden Sie unter JSON Web Key (JWK).

Schlüsseltags

Sie können mehr anwendungsspezifische Metadaten in Form von Tags angeben. Key Vault unterstützt bis zu 15 Tags, von denen jedes einen 256 Zeichen langen Namen und einen Wert von 256 Zeichen aufweisen kann.

Hinweis

Tags sind für Aufrufer lesbar, die über die Berechtigung list oder get für den Schlüssel verfügen.

Schlüsselzugriffssteuerung

Die Zugriffssteuerung für Schlüssel, die von Key Vault verwaltet werden, ist auf der Ebene eines Schlüsseltresors möglich, der als Schlüsselcontainer fungiert. Sie können den Zugriff auf Schlüssel mithilfe der rollenbasierten Zugriffssteuerung von Key Vault (empfohlen) oder mit dem alten Berechtigungsmodell für Tresorzugriffsrichtlinien steuern. Das rollenbasierte Berechtigungsmodell verfügt über drei vordefinierte Rollen zum Verwalten von Schlüsseln: „Key Vault-Kryptografiebeauftragter“, „Key Vault-Kryptografiebenutzer“, „Key Vault Dienstverschlüsselungsbenutzer“ und kann auf die Bereiche Abonnement-, Ressourcengruppen- oder Tresorebene festgelegt werden.

Berechtigungen des Berechtigungsmodells für Tresorzugriffsrichtlinien:

  • Berechtigungen für Schlüsselverwaltungsvorgänge

    • get: Lesen des öffentlichen Teils eines Schlüssels sowie seiner Attribute
    • list: Auflisten der Schlüssel oder Versionen eines in einem Schlüsseltresor gespeicherten Schlüssels
    • update: Aktualisieren der Attribute für einen Schlüssel
    • create: Erstellen neuer Schlüssel
    • import: Importieren eines Schlüssels in einen Schlüsseltresor
    • delete: Löschen des Schlüsselobjekts
    • recover: Wiederherstellen eines gelöschten Schlüssels
    • backup: Sichern eines Schlüssels in einem Schlüsseltresor
    • restore: Wiederherstellen eines gesicherten Schlüssels in einem Schlüsseltresor

  • Berechtigungen für kryptografische Vorgänge

    • decrypt: Verwenden des Schlüssels zum Aufheben des Schutzes einer Folge von Bytes
    • encrypt: Verwenden des Schlüssels zum Schützen einer beliebigen Folge von Bytes
    • unwrapKey: Verwenden des Schlüssels zum Aufheben des Schutzes eines umschlossenen symmetrischen Schlüssels
    • wrapKey: Verwenden des Schlüssels zum Schützen eines symmetrischen Schlüssels
    • verify: Verwenden des Schlüssels zum Überprüfen von Digests
    • sign: Verwenden des Schlüssels zum Signieren von Digests

  • Berechtigungen für privilegierte Vorgänge

    • purge: Bereinigen (dauerhaftes Löschen) eines gelöschten Schlüssels
    • release: Freigeben eines Schlüssels in eine vertrauliche Compute-Umgebung, die der „release_policy“ des Schlüssels entspricht.

  • Berechtigungen für Rotationsrichtlinienvorgänge

    • rotate: Rotieren eines vorhandenen Schlüssels durch Generieren einer neuen Version des Schlüssels (nur Key Vault).
    • get rotation policy: Abrufen der Rotationsrichtlinienkonfiguration.
    • set rotation policy: Festlegen der Rotationsrichtlinienkonfiguration.

Weitere Informationen zum Arbeiten mit Schlüsseln finden Sie in der REST-API-Referenz für Key Vault.

Nächste Schritte