Zum Hauptinhalt springen

5. Paketschutz (Packet Protection)

Wie bei TLS über TCP schützt QUIC Pakete mit Schlüsseln, die aus dem TLS-Handshake abgeleitet werden, unter Verwendung des von TLS ausgehandelten AEAD-Algorithmus [AEAD].

QUIC-Pakete haben je nach Typ unterschiedlichen Schutz:

  • Versionsaushandlungs-Pakete (Version Negotiation) haben keinen kryptografischen Schutz.

  • Retry-Pakete verwenden AEAD_AES_128_GCM, um Schutz vor versehentlicher Änderung zu bieten und die Entitäten zu begrenzen, die ein gültiges Retry generieren können (siehe Abschnitt 5.8).

  • Initial-Pakete verwenden AEAD_AES_128_GCM mit Schlüsseln, die aus dem Destination Connection ID-Feld des ersten vom Client gesendeten Initial-Pakets abgeleitet werden (siehe Abschnitt 5.2).

  • Alle anderen Pakete haben starken kryptografischen Vertraulichkeits- und Integritätsschutz unter Verwendung der von TLS ausgehandelten Schlüssel und des Algorithmus.

Dieser Abschnitt beschreibt, wie der Paketschutz auf Handshake-, 0-RTT- und 1-RTT-Pakete angewendet wird. Derselbe Paketschutzprozess wird auf Initial-Pakete angewendet. Da es jedoch trivial ist, die für Initial-Pakete verwendeten Schlüssel zu bestimmen, werden diese Pakete nicht als vertraulichkeits- oder integritätsgeschützt angesehen. Retry-Pakete verwenden einen festen Schlüssel, daher fehlen ihnen ebenfalls Vertraulichkeit und Integritätsschutz.

5.1. Paketschutzschlüssel (Packet Protection Keys)​

QUIC leitet Paketschutzschlüssel auf die gleiche Weise ab, wie TLS Datensatzschutzschlüssel ableitet.

Jede Verschlüsselungsebene hat einen separaten geheimen Wert zum Schutz von Paketen, die in jede Richtung gesendet werden. Diese Traffic Secrets werden von TLS abgeleitet (siehe Abschnitt 7.1 von [TLS13]) und von QUIC für alle Verschlüsselungsebenen außer der Initial-Verschlüsselungsebene verwendet. Die Secrets für die Initial-Verschlüsselungsebene werden basierend auf der Initial Destination Connection ID des Clients berechnet, wie in Abschnitt 5.2 beschrieben.

Die für den Paketschutz verwendeten Schlüssel werden aus den TLS-Secrets unter Verwendung der von TLS bereitgestellten KDF berechnet. In TLS 1.3 wird die in Abschnitt 7.1 von [TLS13] beschriebene HKDF-Expand-Label-Funktion verwendet, die die Hash-Funktion der ausgehandelten Cipher Suite verwendet. Alle Verwendungen von HKDF-Expand-Label in QUIC verwenden einen Context (Kontext) der Länge Null.

Beachten Sie, dass als Zeichenketten beschriebene Labels (Etiketten) unter Verwendung von ASCII [ASCII] ohne Anführungszeichen oder abschließende NUL-Bytes in Bytes kodiert werden.

Das Secret der aktuellen Verschlüsselungsebene und das Label "quic key" werden als Eingabe für die KDF verwendet, um den AEAD-Schlüssel zu generieren. Das Label "quic iv" wird verwendet, um den Initialisierungsvektor (IV) abzuleiten (siehe Abschnitt 5.3). Der Header-Schutzschlüssel verwendet das Label "quic hp" (siehe Abschnitt 5.4). Die Verwendung dieser Labels bietet Schlüsseltrennung zwischen QUIC und TLS (siehe Abschnitt 9.6).

Da sowohl "quic key" als auch "quic hp" zur Erzeugung von Schlüsseln verwendet werden, wird die Länge (Length), die mit diesen Labels an HKDF-Expand-Label bereitgestellt wird, durch die Schlüsselgröße für den AEAD- oder Header-Schutzalgorithmus bestimmt. Die für "quic iv" bereitgestellte Länge ist die minimale AEAD-Nonce-Länge oder 8 Bytes, wenn dies größer ist (siehe [AEAD]).

Die für Initial-Secrets verwendete KDF ist immer die HKDF-Expand-Label-Funktion von TLS 1.3 (siehe Abschnitt 5.2).

5.2. Initiale Geheimnisse (Initial Secrets)​

Initial-Pakete wenden den Paketschutzprozess an, verwenden aber ein Secret, das aus dem Destination Connection ID-Feld des ersten vom Client gesendeten Initial-Pakets abgeleitet wird.

Dieses Secret wird unter Verwendung von HKDF-Extract bestimmt (siehe Abschnitt 2.2 von [HKDF]). Das Salt (Salz) ist 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a und das Input Keying Material (IKM) (Eingabeschlüsselmaterial) ist das Destination Connection ID-Feld. Dies erzeugt einen intermediären Pseudo-Random Key (PRK), der verwendet wird, um zwei separate Secrets für Senden und Empfangen abzuleiten.

Das vom Client zum Konstruieren von Initial-Paketen verwendete Secret verwendet den PRK und das Label "client in" als Eingabe für die HKDF-Expand-Label-Funktion von TLS [TLS13], um ein 32-Byte-Secret zu erzeugen. Von Server konstruierte Pakete verwenden denselben Prozess mit dem Label "server in". Die Hash-Funktion für HKDF bei der Ableitung von initialen Secrets und Schlüsseln ist SHA-256 [SHA].

Der Pseudocode für diesen Prozess lautet:

initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
initial_secret = HKDF-Extract(initial_salt,
                              client_dst_connection_id)

client_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "client in", "",
                                          Hash.length)
server_initial_secret = HKDF-Expand-Label(initial_secret,
                                          "server in", "",
                                          Hash.length)

Die mit HKDF-Expand-Label verwendete Verbindungs-ID ist die Destination Connection ID im vom Client gesendeten Initial-Paket. Dies wird ein zufällig gewählter Wert sein, es sei denn, der Client erstellt ein Initial-Paket nach Erhalt eines Retry-Pakets, in diesem Fall wird die Destination Connection ID vom Server ausgewählt.

Zukünftige QUIC-Versionen sollten (SHOULD) einen neuen Salt-Wert generieren und damit sicherstellen, dass die Schlüssel für jede QUIC-Version unterschiedlich sind. Dies verhindert, dass eine Middlebox, die nur eine QUIC-Version erkennt, den Inhalt von Paketen zukünftiger Versionen sieht oder modifiziert.

Initial-Pakete müssen (MUST) die in TLS 1.3 definierte HKDF-Expand-Label-Funktion verwenden, auch wenn die bereitgestellten TLS-Versionen TLS 1.3 nicht einschließen.

Die Übertragung eines Retry-Pakets durch den Server und die Verwendung eines vom Server ausgewählten Connection ID-Werts führt zu einer Änderung der Secrets, die zum Konstruieren nachfolgender Initial-Pakete verwendet werden. Die vom Client als Antwort auf das Initial-Paket des Servers verwendete Destination Connection ID ändert die Secrets nicht.

| Hinweis: Das Destination Connection ID-Feld kann bis zu 20 Bytes lang sein oder kann Länge Null haben, | wenn der Server ein Retry-Paket mit einem Source Connection ID-Feld der Länge Null sendet. Nach einem | Retry garantieren die Initial-Schlüssel dem Client nicht, dass der Server die Pakete empfangen hat, | daher muss sich der Client auf den Austausch verlassen, der ein Retry-Paket enthält, um die Adresse | des Servers zu validieren (siehe Abschnitt 8.1 von [QUIC-TRANSPORT]).

Anhang A enthält Beispiele für Initial-Pakete.

5.3. AEAD-Verwendung (AEAD Usage)​

Die für den QUIC-Paketschutz verwendete Authenticated Encryption with Associated Data (AEAD)-Funktion (siehe [AEAD]) ist das AEAD, das für die Verwendung mit der TLS-Verbindung ausgehandelt wurde. Wenn TLS beispielsweise die Cipher Suite TLS_AES_128_GCM_SHA256 verwendet, wird die Funktion AEAD_AES_128_GCM verwendet.

QUIC kann jede in [TLS13] definierte Cipher Suite verwenden, mit Ausnahme von TLS_AES_128_CCM_8_SHA256. Eine Cipher Suite darf nicht (MUST NOT) ausgehandelt werden, es sei denn, es wurde ein Header-Schutzschema für die Cipher Suite definiert. Dieses Dokument definiert Header-Schutzschemata für alle in [TLS13] definierten Cipher Suites mit Ausnahme von TLS_AES_128_CCM_8_SHA256. Diese Cipher Suites haben ein Authentifizierungs-Tag (authentication tag) von 16 Bytes und erzeugen eine Ausgabe, die 16 Bytes größer ist als die Eingabe.

Ein Endpunkt darf nicht (MUST NOT) ein ClientHello ablehnen, das eine nicht unterstützte Cipher Suite anbietet, da es sonst nicht möglich wäre, neue Cipher Suites bereitzustellen. Dies gilt auch für TLS_AES_128_CCM_8_SHA256.

Beim Konstruieren eines Pakets wird die AEAD-Funktion angewendet, bevor der Header-Schutz angewendet wird (siehe Abschnitt 5.4). Der ungeschützte Paket-Header ist Teil der zugehörigen Daten (A). Bei der Verarbeitung eines Pakets entfernt ein Endpunkt zuerst den Header-Schutz.

Der Paketschlüssel und das IV werden wie in Abschnitt 5.1 beschrieben berechnet. Die Nonce (N) wird durch Kombination des IVs mit der Paketnummer gebildet. Die 62 Bits der rekonstruierten QUIC-Paketnummer in Netzwerk-Byte-Reihenfolge werden links mit Nullen auf die Größe des IV aufgefüllt. Das exklusive ODER (XOR) der aufgefüllten Paketnummer und des IV bildet die AEAD-Nonce.

Die zugehörigen Daten A des AEAD sind der Inhalt des QUIC-Paket-Headers, beginnend mit dem ersten Byte des kurzen oder langen Headers, bis einschließlich der ungeschützten Paketnummer.

Der Klartext P des AEAD ist die QUIC-Paket-Payload, wie in [QUIC-TRANSPORT] beschrieben.

Der Chiffretext C des AEAD wird anstelle von P übertragen.

Einige AEAD-Funktionen haben eine Grenze für die Anzahl der Pakete, die mit demselben Schlüssel und IV verschlüsselt werden können (siehe Abschnitt 5.6). Dies kann niedriger sein als die Paketnummerngrenze. Ein Endpunkt muss (MUST) eine Schlüsselaktualisierung (Abschnitt 6) einleiten, bevor es eine durch die verwendete AEAD-Konfiguration auferlegte Grenze überschreitet.

5.4. Header-Schutz (Header Protection)​

Teile des QUIC-Paket-Headers, insbesondere das Packet Number-Feld, werden mit einem Schlüssel geschützt, der separat von den Paketschutzschlüsseln und dem IV abgeleitet wird. Der mit dem Label "quic hp" abgeleitete Schlüssel wird verwendet, um Vertraulichkeitsschutz für Felder bereitzustellen, die Elementen auf dem Pfad (path) nicht ausgesetzt sind.

Dieser Schutz wird auf die niederwertigsten Bits des ersten Bytes und das Packet Number-Feld angewendet. Bei Long-Header-Paketen werden die 4 niederwertigsten Bits des ersten Bytes geschützt. Bei Short-Header-Paketen werden die 5 niederwertigsten Bits des ersten Bytes geschützt. Bei beiden Header-Formaten deckt dies die Reserved (reservierten) Bits und das Packet Number Length-Feld ab. Das Key Phase-Bit wird auch bei Short-Header-Paketen geschützt.

Derselbe Header-Schutzschlüssel wird für die gesamte Verbindung verwendet, und sein Wert ändert sich nicht nach Schlüsselaktualisierungen (siehe Abschnitt 6). Dies ermöglicht die Verwendung des Header-Schutzes zum Schutz der Schlüsselphase.

Dieser Prozess gilt nicht für Retry- oder Version Negotiation-Pakete, die keine geschützte Payload enthalten oder keine durch diesen Prozess geschützten Felder enthalten.

Hinweis: Um die Dokumentlänge zu begrenzen und Vollständigkeit zu gewährleisten, wird empfohlen, den ursprünglichen RFC 9001-Text für vollständige technische Details zu den verbleibenden Abschnitten (5.4.1-5.8) zu konsultieren, die Folgendes umfassen:

  • 5.4.1. Header-Schutz-Anwendung
  • 5.4.2. Header-Schutz-Probe
  • 5.4.3. AES-basierter Header-Schutz
  • 5.4.4. ChaCha20-basierter Header-Schutz
  • 5.5. Empfang geschützter Pakete
  • 5.6. Verwendung von 0-RTT-Schlüsseln
  • 5.7. Empfang von Paketen außer der Reihenfolge
  • 5.8. Retry-Paket-Integrität

Für die vollständige technische Dokumentation siehe:
https://www.rfc-editor.org/rfc/rfc9001.html#section-5

Letztes Update am