6. Methoden zur Verteilung von Inhaltsschlüsseln

6. Methoden zur Verteilung von Inhaltsschlüsseln

Abschnitt 8.5 von [RFC9052] enthält eine allgemeine Beschreibung von Methoden zur Verteilung von Inhaltsschlüsseln. Dieses Dokument definiert die Bezeichner und die Verwendung für eine Reihe von Methoden zur Verteilung von Inhaltsschlüsseln.

6.1. Direkte Verschlüsselung

Ein direkter Verschlüsselungsalgorithmus ist in Abschnitt 8.5.1 von [RFC9052] definiert. Informationen zum Ausfüllen der COSE_Recipient-Struktur sind dort detailliert beschrieben.

6.1.1. Direkter Schlüssel (Direct Key)

Dieser Empfängeralgorithmus ist der einfachste; der identifizierte Schlüssel wird direkt als Schlüssel für die nächste Ebene in der Nachricht verwendet. Für diesen Algorithmus sind keine Algorithmusparameter definiert. Der Algorithmusbezeichnerwert wird in Tabelle 11 zugewiesen.

Wenn dieser Algorithmus verwendet wird, MUSS das Feld "protected" eine Länge von Null haben. Der Schlüsseltyp MUSS "Symmetric" sein.

  +========+=======+============================================+
  | Name   | Wert  | Beschreibung                               |
  +========+=======+============================================+
  | direct |   -6  | Direkte Verwendung des Inhalts-            |
  |        |       | verschlüsselungsschlüssels (CEK)           |
  +--------+-------+--------------------------------------------+

                        Tabelle 11: Direkter Schlüssel

6.1.2. Direkter Schlüssel mit KDF (Direct Key with KDF)

Diese Empfängeralgorithmen nehmen ein gemeinsames Geheimnis zwischen den beiden Parteien und wenden die HKDF-Funktion (Abschnitt 5.1) unter Verwendung der in Abschnitt 5.2 definierten Kontextstruktur an, um das gemeinsame Geheimnis in den CEK umzuwandeln. Das Feld "protected" kann eine Länge ungleich Null haben. Entweder der "salt"-Parameter für HKDF (Tabelle 9) oder der "PartyU nonce"-Parameter für die Kontextstruktur (Tabelle 10) MUSS vorhanden sein (beide können vorhanden sein, falls gewünscht). Der Wert im "salt"/"nonce"-Parameter kann entweder zufällig oder deterministisch generiert werden. Die Anforderung ist, dass es ein eindeutiger Wert für das fragliche gemeinsame Geheimnis ist.

Wenn der Salt/Nonce-Wert zufällig generiert wird, wird empfohlen, dass die Länge des Zufallswerts gleich der Ausgabe der Hash-Funktion ist, die HKDF zugrunde liegt. Obwohl nicht garantiert werden kann, dass er eindeutig ist, besteht eine hohe Wahrscheinlichkeit, dass er eindeutig ist. Wenn der Salt/Nonce-Wert deterministisch generiert wird, kann garantiert werden, dass er eindeutig ist, und daher gibt es keine Längenanforderung.

6.2. Schlüsselumhüllung (Key Wrap)

Schlüsselumhüllung ist in Abschnitt 8.5.2 von [RFC9052] definiert. Informationen zum Ausfüllen der COSE_Recipient-Struktur sind dort detailliert beschrieben.

6.2.1. AES-Schlüsselumhüllung (AES Key Wrap)

Der AES Key Wrap-Algorithmus ist in [RFC3394] definiert. Dieser Algorithmus verwendet einen AES-Schlüssel, um einen Wert zu umhüllen, der ein Vielfaches von 64 Bit ist. Daher kann er verwendet werden, um einen Schlüssel für einen der in diesem Dokument definierten Inhaltsverschlüsselungsalgorithmen zu umhüllen. Der Algorithmus erfordert einen einzigen festen Parameter, den Initialwert. Dieser ist auf den in Abschnitt 2.2.3.1 von [RFC3394] angegebenen Wert festgelegt. Es gibt keine Parameter für öffentliche Schlüssel, die bei jedem Aufruf variieren. Der geschützte Header-Bucket MUSS leer sein.

    +========+=======+==========+=============================+
    | Name   | Wert  | Größe    | Beschreibung                |
    +========+=======+==========+=============================+
    | A128KW |   -3  |   128    | AES Key Wrap (128-bit Key)  |
    +--------+-------+----------+-----------------------------+
    | A192KW |   -4  |   192    | AES Key Wrap (192-bit Key)  |
    +--------+-------+----------+-----------------------------+
    | A256KW |   -5  |   256    | AES Key Wrap (256-bit Key)  |
    +--------+-------+----------+-----------------------------+

              Tabelle 13: AES Key Wrap Algorithmuswerte

6.3. Direkte Schlüsselvereinbarung (Direct Key Agreement)

Direkte Schlüsselvereinbarung ist in Abschnitt 8.5.4 von [RFC9052] definiert. Informationen zum Ausfüllen der COSE_Recipient-Struktur sind dort detailliert beschrieben.

6.3.1. Direktes ECDH (Direct ECDH)

Die Mathematik für ECDH findet sich in [RFC6090]. In diesem Dokument wird der Algorithmus erweitert, um mit den zwei in [RFC7748] definierten Kurven verwendet zu werden.

ECDH wird durch Folgendes parametrisiert:

Curve Type/Curve: Die ausgewählte Kurve steuert nicht nur die Größe des gemeinsamen Geheimnisses, sondern auch die Mathematik zur Berechnung des gemeinsamen Geheimnisses.

Computed Secret to Shared Secret: Sobald das berechnete Geheimnis bekannt ist, muss der resultierende Wert in eine Bytefolge umgewandelt werden, um die KDF auszuführen.

Ephemeral-Static or Static-Static: Der Schlüsselvereinbarungsprozess kann entweder mit einem statischen oder einem ephemeren Schlüssel für die Senderseite durchgeführt werden.

Key Derivation Algorithm: Das Ergebnis eines ECDH-Schlüsselvereinbarungsprozesses liefert kein gleichmäßig zufälliges Geheimnis. Daher muss es durch eine KDF laufen, um einen verwendbaren Schlüssel zu erzeugen.

Key Wrap Algorithm: Es wird kein Schlüsselumhüllungsalgorithmus verwendet.

Der Satz der in diesem Dokument definierten direkten ECDH-Algorithmen findet sich in Tabelle 14.