Zum Hauptinhalt springen

3.14. Encrypted Payload (Verschlüsselte Nutzdaten)

3.14. Encrypted Payload (Verschlüsselte Nutzdaten)​

Das Encrypted-Payload, in diesem Dokument als SK {...} bezeichnet, enthält andere Nutzdaten in verschlüsselter Form. Ist ein Encrypted-Payload in einer Nachricht vorhanden, MUSS es die letzte Nutzlast der Nachricht sein. Oft ist es die einzige Nutzlast. Diese Nutzlast wird auch als „Encrypted and Authenticated“-Payload bezeichnet.

Die Algorithmen für Verschlüsselung und Integritätsschutz werden beim Aufbau der IKE-SA ausgehandelt, und die Schlüssel werden gemäß den Abschnitten 2.14 und 2.18 berechnet.

Dieses Dokument legt die kryptographische Verarbeitung von Encrypted-Payloads mit einem Blockchiffre im CBC-Modus und einem Integritätsprüfalgorithmus fest, der eine Prüfsumme fester Länge über eine Nachricht variabler Größe berechnet. Das Design orientiert sich an den in RFC 2104 [HMAC], 4303 [ESP] und 2451 [ESPCBC] beschriebenen ESP-Algorithmen. Die kryptographische Verarbeitung von IKE-Daten ist in diesem Dokument vollständig spezifiziert; für die Designbegründung sind jene Dokumente heranzuziehen. Zukünftige Dokumente KÖNNEN die Verarbeitung von Encrypted-Payloads für andere Transformtypen, z. B. Counter-Mode-Verschlüsselung und authentifizierte Verschlüsselungsalgorithmen, festlegen. Peers DÜRFEN keine Transformationen aushandeln, für die keine solche Spezifikation existiert.

Wird ein authentifiziertes Verschlüsselungsverfahren zum Schutz der IKE-SA verwendet, unterscheidet sich der Aufbau des Encrypted-Payloads von der hier beschriebenen Darstellung. Siehe [AEAD] zu authentifizierten Verschlüsselungsalgorithmen und ihrer Verwendung in IKEv2.

Der Nutzdatentyp für ein Encrypted-Payload ist sechsundvierzig (46). Das Encrypted-Payload besteht aus dem generischen IKE-Nutzdatenkopf und den folgenden Feldern:

                    1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Initialization Vector                     |
|         (length is block size for encryption algorithm)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Encrypted IKE Payloads                     ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |             Padding (0-255 octets)            |
+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
|                                               |  Pad Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Integrity Checksum Data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Abbildung 21: Format des Encrypted-Payloads

  • Next Payload - Der Nutzdatentyp der ersten eingebetteten Nutzlast. Dies ist eine Ausnahme vom Standardkopfformat, da das Encrypted-Payload die letzte Nutzlast der Nachricht ist und das Feld Next Payload daher normalerweise null wäre. Da der Inhalt eingebettete Nutzdaten sind und es keinen natürlichen Platz für den Typ der ersten gab, wird dieser hier untergebracht.

  • Payload Length - Umfasst die Längen von Kopf, Initialisierungsvektor (IV), verschlüsselten IKE-Nutzdaten, Padding, Pad Length und Integrity Checksum Data.

  • Initialization Vector - Bei CBC-Modus-Chiffren ist die Länge des IV gleich der Blocklänge des zugrunde liegenden Verschlüsselungsalgorithmus. Sender MÜSSEN für jede Nachricht einen neuen, nicht vorhersagbaren IV wählen; Empfänger MÜSSEN jeden Wert akzeptieren. Zur IV-Erzeugung siehe [MODES]. Insbesondere gilt die Verwendung des letzten Geheimtextblocks der vorherigen Nachricht nicht als nicht vorhersagbar. Für andere Modi als CBC werden IV-Format und -Verarbeitung im Dokument zum Verschlüsselungsalgorithmus und -modus festgelegt.

  • IKE-Nutzdaten wie weiter oben in diesem Abschnitt spezifiziert. Dieses Feld wird mit dem ausgehandelten Chiffre verschlüsselt.

  • Padding KANN einen vom Sender gewählten beliebigen Wert enthalten und MUSS eine Länge haben, sodass die Kombination aus Nutzdaten, Padding und Pad Length ein Vielfaches der Verschlüsselungsblockgröße ist. Dieses Feld wird mit dem ausgehandelten Chiffre verschlüsselt.

  • Pad Length ist die Länge des Padding-Feldes. Der Sender SOLLTE Pad Length auf den kleinsten Wert setzen, der die genannte Kombination zu einem Vielfachen der Blockgröße macht, der Empfänger MUSS jedoch jede Länge akzeptieren, die eine korrekte Ausrichtung ergibt. Dieses Feld wird mit dem ausgehandelten Chiffre verschlüsselt.

  • Integrity Checksum Data ist die kryptographische Prüfsumme der gesamten Nachricht vom festen IKE-Kopf bis einschließlich Pad Length. Die Prüfsumme MUSS über die verschlüsselte Nachricht berechnet werden. Ihre Länge ergibt sich aus dem ausgehandelten Integritätsalgorithmus.

Letztes Update am