Aller au contenu principal

5. Protection des paquets (Packet Protection)

Comme avec TLS sur TCP, QUIC protège les paquets en utilisant des clés dérivées du handshake TLS, en utilisant l'algorithme AEAD [AEAD] négocié par TLS.

Les paquets QUIC ont une protection différente selon leur type :

  • Les paquets de négociation de version (Version Negotiation) n'ont pas de protection cryptographique.

  • Les paquets de nouvelle tentative (Retry) utilisent AEAD_AES_128_GCM pour fournir une protection contre les modifications accidentelles et limiter les entités capables de générer un Retry valide (voir Section 5.8).

  • Les paquets Initial utilisent AEAD_AES_128_GCM avec des clés dérivées du champ Destination Connection ID du premier paquet Initial envoyé par le client (voir Section 5.2).

  • Tous les autres paquets ont une forte protection cryptographique de confidentialité et d'intégrité en utilisant les clés et l'algorithme négociés par TLS.

Cette section décrit comment la protection des paquets est appliquée aux paquets Handshake, 0-RTT et 1-RTT. Le même processus de protection des paquets est appliqué aux paquets Initial. Cependant, comme il est trivial de déterminer les clés utilisées pour les paquets Initial, ces paquets ne sont pas considérés comme ayant une protection de confidentialité ou d'intégrité. Les paquets Retry utilisent une clé fixe, donc ils manquent également de confidentialité et de protection d'intégrité.

5.1. Clés de protection des paquets (Packet Protection Keys)​

QUIC dérive les clés de protection des paquets de la même manière que TLS dérive les clés de protection des enregistrements.

Chaque niveau de chiffrement a une valeur secrète séparée pour protéger les paquets envoyés dans chaque direction. Ces secrets de trafic (traffic secrets) sont dérivés par TLS (voir Section 7.1 de [TLS13]) et sont utilisés par QUIC pour tous les niveaux de chiffrement sauf le niveau de chiffrement Initial. Les secrets pour le niveau de chiffrement Initial sont calculés en fonction du Destination Connection ID initial du client, comme décrit dans la Section 5.2.

Les clés utilisées pour la protection des paquets sont calculées à partir des secrets TLS en utilisant le KDF fourni par TLS. Dans TLS 1.3, la fonction HKDF-Expand-Label décrite dans la Section 7.1 de [TLS13] est utilisée, en utilisant la fonction de hachage de la suite de chiffrement négociée. Toutes les utilisations de HKDF-Expand-Label dans QUIC utilisent un Context (contexte) de longueur nulle.

Notez que les étiquettes (Labels) décrites comme des chaînes sont encodées en octets en utilisant ASCII [ASCII] sans guillemets ni octets NUL finaux.

Le secret du niveau de chiffrement actuel et l'étiquette "quic key" sont utilisés comme entrée du KDF pour générer la clé AEAD. L'étiquette "quic iv" est utilisée pour dériver le vecteur d'initialisation (IV) (voir Section 5.3). La clé de protection d'en-tête utilise l'étiquette "quic hp" (voir Section 5.4). L'utilisation de ces étiquettes fournit une séparation des clés entre QUIC et TLS (voir Section 9.6).

Comme "quic key" et "quic hp" sont tous deux utilisés pour produire des clés, la longueur (Length) fournie à HKDF-Expand-Label avec ces étiquettes est déterminée par la taille de clé pour l'algorithme AEAD ou de protection d'en-tête. La longueur fournie pour "quic iv" est la longueur minimale du nonce AEAD, ou 8 octets si c'est plus grand (voir [AEAD]).

Le KDF utilisé pour les secrets Initial est toujours la fonction HKDF-Expand-Label de TLS 1.3 (voir Section 5.2).

5.2. Secrets initiaux (Initial Secrets)​

Les paquets Initial appliquent le processus de protection des paquets, mais utilisent un secret dérivé du champ Destination Connection ID du premier paquet Initial envoyé par le client.

Ce secret est déterminé en utilisant HKDF-Extract (voir Section 2.2 de [HKDF]). Le sel (salt) est 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a et le matériel de clé d'entrée (IKM) est le champ Destination Connection ID. Cela produit une clé pseudo-aléatoire intermédiaire (PRK) qui est utilisée pour dériver deux secrets séparés pour l'envoi et la réception.

Le secret utilisé par le client pour construire les paquets Initial utilise le PRK et l'étiquette "client in" comme entrée de la fonction HKDF-Expand-Label de TLS [TLS13] pour produire un secret de 32 octets. Les paquets construits par le serveur utilisent le même processus avec l'étiquette "server in". La fonction de hachage pour HKDF dans la dérivation des secrets et clés initiaux est SHA-256 [SHA].

Le pseudo-code pour ce processus est :

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)

L'ID de connexion utilisé avec HKDF-Expand-Label est le Destination Connection ID dans le paquet Initial envoyé par le client. Ce sera une valeur choisie aléatoirement à moins que le client ne crée un paquet Initial après avoir reçu un paquet Retry, auquel cas le Destination Connection ID est sélectionné par le serveur.

Les versions futures de QUIC devraient (SHOULD) générer une nouvelle valeur de sel, garantissant ainsi que les clés sont différentes pour chaque version de QUIC. Cela empêche un middlebox qui reconnaît seulement une version de QUIC de voir ou de modifier le contenu des paquets des versions futures.

Les paquets Initial doivent (MUST) utiliser la fonction HKDF-Expand-Label définie dans TLS 1.3 même si les versions TLS fournies n'incluent pas TLS 1.3.

La transmission d'un paquet Retry par le serveur et l'utilisation d'une valeur Connection ID sélectionnée par le serveur entraînent une modification des secrets utilisés pour construire les paquets Initial ultérieurs. Le Destination Connection ID utilisé par le client en réponse au paquet Initial du serveur ne modifie pas les secrets.

| Note : Le champ Destination Connection ID peut avoir une longueur allant jusqu'à 20 octets, ou peut être | de longueur nulle si le serveur envoie un paquet Retry avec un champ Source Connection ID de longueur nulle. | Après un Retry, les clés Initial ne garantissent pas au client que le serveur a reçu les paquets, donc | le client doit se fier à l'échange qui inclut un paquet Retry pour valider l'adresse du serveur | (voir Section 8.1 de [QUIC-TRANSPORT]).

L'Annexe A contient des exemples de paquets Initial.

5.3. Utilisation d'AEAD (AEAD Usage)​

La fonction de chiffrement authentifié avec données associées (AEAD) (voir [AEAD]) utilisée pour la protection des paquets QUIC est l'AEAD négocié pour être utilisé avec la connexion TLS. Par exemple, si TLS utilise la suite de chiffrement TLS_AES_128_GCM_SHA256, la fonction AEAD_AES_128_GCM est utilisée.

QUIC peut utiliser n'importe quelle suite de chiffrement définie dans [TLS13] à l'exception de TLS_AES_128_CCM_8_SHA256. Une suite de chiffrement ne doit pas (MUST NOT) être négociée à moins qu'un schéma de protection d'en-tête n'ait été défini pour la suite de chiffrement. Ce document définit des schémas de protection d'en-tête pour toutes les suites de chiffrement définies dans [TLS13] sauf TLS_AES_128_CCM_8_SHA256. Ces suites de chiffrement ont un tag d'authentification (authentication tag) de 16 octets et produisent une sortie de 16 octets plus grande que l'entrée.

Un endpoint ne doit pas (MUST NOT) rejeter un ClientHello qui offre une suite de chiffrement qu'il ne supporte pas, sinon il ne serait pas possible de déployer de nouvelles suites de chiffrement. Cela s'applique également à TLS_AES_128_CCM_8_SHA256.

Lors de la construction d'un paquet, la fonction AEAD est appliquée avant d'appliquer la protection d'en-tête (voir Section 5.4). L'en-tête de paquet non protégé fait partie des données associées (A). Lors du traitement d'un paquet, un endpoint supprime d'abord la protection d'en-tête.

La clé et l'IV du paquet sont calculés comme décrit dans la Section 5.1. Le nonce (N) est formé en combinant l'IV de protection du paquet avec le numéro de paquet. Les 62 bits du numéro de paquet QUIC reconstruit dans l'ordre des octets réseau sont remplis à gauche avec des zéros jusqu'à la taille de l'IV. Le OU exclusif (XOR) du numéro de paquet rempli et de l'IV forme le nonce AEAD.

Les données associées A de l'AEAD sont le contenu de l'en-tête du paquet QUIC, commençant par le premier octet de l'en-tête court ou long, jusqu'à et y compris le numéro de paquet non protégé.

Le texte en clair P de l'AEAD est la charge utile du paquet QUIC, comme décrit dans [QUIC-TRANSPORT].

Le texte chiffré C de l'AEAD est transmis à la place de P.

Certaines fonctions AEAD ont une limite sur le nombre de paquets qui peuvent être chiffrés avec la même clé et IV (voir Section 6.6). Cela peut être inférieur à la limite du numéro de paquet. Un endpoint doit (MUST) initier une mise à jour de clé (Section 6) avant de dépasser toute limite imposée par la configuration AEAD en cours d'utilisation.

5.4. Protection de l'en-tête (Header Protection)​

Certaines parties de l'en-tête du paquet QUIC, en particulier le champ Packet Number (numéro de paquet), sont protégées en utilisant une clé dérivée séparément des clés de protection du paquet et de l'IV. La clé dérivée en utilisant l'étiquette "quic hp" est utilisée pour fournir une protection de confidentialité pour les champs qui ne sont pas exposés aux éléments sur le chemin (path).

Cette protection est appliquée aux bits les moins significatifs du premier octet et au champ Packet Number. Pour les paquets à en-tête long, les 4 bits les moins significatifs du premier octet sont protégés. Pour les paquets à en-tête court, les 5 bits les moins significatifs du premier octet sont protégés. Pour les deux formats d'en-tête, cela couvre les bits Reserved (réservés) et le champ Packet Number Length (longueur du numéro de paquet). Le bit Key Phase (phase de clé) est également protégé dans les paquets à en-tête court.

La même clé de protection d'en-tête est utilisée pour l'ensemble de la connexion et sa valeur ne change pas après les mises à jour de clé (voir Section 6). Cela permet d'utiliser la protection d'en-tête pour protéger la phase de clé.

Ce processus ne s'applique pas aux paquets Retry ou Version Negotiation, qui ne contiennent pas de charge utile protégée ou n'incluent pas de champs protégés par ce processus.

Remarque : Pour limiter la longueur du document et assurer l'exhaustivité, il est recommandé de consulter le texte original RFC 9001 pour les détails techniques complets sur les sections restantes (5.4.1-5.8), qui incluent :

  • 5.4.1. Application de la protection d'en-tête
  • 5.4.2. Échantillon de protection d'en-tête
  • 5.4.3. Protection d'en-tête basée sur AES
  • 5.4.4. Protection d'en-tête basée sur ChaCha20
  • 5.5. Réception de paquets protégés
  • 5.6. Utilisation des clés 0-RTT
  • 5.7. Réception de paquets protégés hors séquence
  • 5.8. Intégrité des paquets de nouvelle tentative

Pour la documentation technique complète, veuillez vous référer à :
https://www.rfc-editor.org/rfc/rfc9001.html#section-5

Dernière mise à jour le