Le cadre de protocole Noise

Le cadre de protocole Noise (Trevor Perrin, 2016 ; version actuelle de 2018) est un cadre permettant de construire des protocoles de canaux sécurisés à l'aide d'un petit ensemble de primitives et d'un langage de modèles. Au lieu de définir un protocole unique, Noise définit un vocabulaire de modèles de poignée de main décrivant la séquence des opérations DH et leur ordre. Tout modèle Noise valide peut être instancié avec des fonctions concrètes de DH (Curve25519 ou Curve448), de chiffrement (AESGCM ou ChaChaPoly) et de hachage (SHA-256, SHA-512, BLAKE2). Noise est utilisé dans WireGuard, WhatsApp, Signal (comme base de X3DH), le réseau Lightning et I2P.

Chaque poignée de main Noise possède un initiateur (I) et un répondant (R). Chaque partie peut avoir deux types de clés : statique (clé d'identité à long terme, notée s/S) et éphémère (générée spécialement pour chaque session, notée e/E). Les lettres minuscules désignent la clé de la partie locale ; les majuscules désignent la clé publique de la partie distante. Un modèle Noise précise quelles clés sont envoyées (en clair ou chiffrées) et quelles opérations DH sont effectuées. Par exemple, « e » signifie «‫envoyer ma clé publique éphémère » ; « es » signifie «‫effectuer DH(my_ephemeral, remote_static) ». Chaque résultat DH est intégré à l'état de hachage cumulatif de la poignée de main.

Le cœur de Noise est SymmetricState, qui conserve trois valeurs : ck (clé de chaînage, initialisée avec le hachage du nom du protocole), h (hachage de la poignée de main, c'est-à-dire le hachage cumulatif de la transcription) et k (clé de chiffrement actuelle). MixKey(input) exécute HKDF(ck, input) afin de mettre à jour ck et k. MixHash(data) hache data dans h. EncryptAndHash(plaintext) chiffre avec k et intègre le texte chiffré à h. DecryptAndHash(ciphertext) déchiffre et intègre le texte chiffré à h. Le hachage de la poignée de main h assure la liaison à la transcription : toute modification malveillante d'un message quelconque modifie h et fait donc échouer le déchiffrement. À la fin de la poignée de main, Split() produit deux CipherStates distincts pour l'envoi et la réception.

Noise_XX est le modèle d'authentification mutuelle le plus couramment utilisé. Il fournit une authentification mutuelle par clés statiques, les clés statiques des deux parties étant transmises pendant la poignée de main. Modèle : (1) -> e (l'initiateur envoie sa clé publique éphémère). (2) <- e, ee, s, es (le répondant envoie sa clé éphémère, effectue DH(e,e) et DH(e,s_resp), puis envoie sa clé statique chiffrée). (3) -> s, se (l'initiateur envoie sa clé statique chiffrée et effectue DH(s_init, e_resp)). Après l'étape 3, les deux parties ont intégré trois résultats DH à la clé de session : ee (confidentialité persistante), es (authentification du serveur) et se (authentification du client). La clé de session est indépendante de toute compromission d'une clé à long terme après la fin de la session.

WireGuard utilise un modèle dérivé de Noise_IK dans lequel l'initiateur connaît à l'avance la clé statique du répondant. (1) -> e, es, s, ss (l'initiateur envoie sa clé éphémère, effectue DH(e, S_resp), envoie sa clé statique chiffrée et effectue DH(s_init, S_resp)). (2) <- e, ee, se (le répondant envoie sa clé éphémère, effectue DH(e_resp, e_init) et DH(e_resp, S_init)). Le modèle IK assure la dissimulation de l'identité de l'initiateur (sa clé statique est chiffrée avec la clé statique du répondant à l'étape 1) et s'achève en un RTT. WireGuard ajoute un horodatage dans la charge utile chiffrée de l'initiateur afin d'empêcher les rejeux. Cela donne à WireGuard sa simplicité caractéristique : une poignée de main VPN complète en deux paquets UDP.

Le hachage de poignée de main h à la fin d'une poignée de main Noise est un hachage de transcription couvrant chaque message envoyé. Il sert de valeur de liaison de canal : les deux parties calculent le même h, et tout protocole tiers qui souhaite se lier à la session Noise peut inclure h comme nonce ou identifiant de canal. Cela permet une authentification composée : une étape d'authentification par certificat de type TLS peut s'exécuter après la poignée de main Noise, en liant le certificat à cette session précise au moyen de h. La liaison de canal empêche les attaques de transmission d'identifiants, dans lesquelles des identifiants d'authentification provenant d'une session sont rejoués contre une autre. Split() fournit h à l'application avec les clés de session.

Noise prend en charge les modèles différés lorsque l'initiateur ne connaît pas à l'avance la clé statique du répondant. Noise_NX (l'initiateur n'a pas de clé statique ; le répondant transmet la sienne) est analogue à TLS unidirectionnel. Noise_XX traite le cas où les deux parties doivent échanger leurs clés. Noise_IK peut revenir à Noise_XXfallback si la clé statique supposée par l'initiateur pour le répondant est incorrecte (par exemple après une rotation de clé). Le modèle de repli permet au répondant de signaler «‫vous avez utilisé la mauvaise clé ; voici ma nouvelle clé publique » sans révéler aux observateurs extérieurs qu'un repli a eu lieu, ce qui préserve l'opacité du protocole.

WhatsApp et Signal utilisent Noise_XX pour établir des canaux sécurisés entre les clients et les serveurs. Le protocole binaire de WhatsApp utilise Noise_XX avec Curve25519, ChaChaPoly et SHA-256. La clé statique du client est sa clé d'identité à long terme. Après la poignée de main Noise, la couche applicative exécute une authentification supplémentaire (enregistrement auprès de Signal, vérification du numéro de téléphone). L'accord de clés X3DH (Diffie-Hellman triple étendu) effectue quatre opérations DH afin d'établir un secret partagé entre deux utilisateurs au moyen d'un échange de messages asynchrone ; il ne s'agit pas d'un modèle Noise standard, mais il utilise des concepts similaires de mélange DH. Le Double Ratchet prend ensuite le relais pour le chiffrement continu des messages.

Noise et TLS 1.3 répondent au même problème (l'échange de clés authentifié), mais selon des philosophies différentes. TLS 1.3 est un protocole unique avec des suites de chiffrement, des formats de certificats (X.509) et des extensions prescrits. Il est conçu pour les navigateurs web et les serveurs : un protocole unique adapté à la plupart des cas. Noise est un cadre : il ne définit ni format de certificat, ni PKI, ni liaison au transport. Cela rend Noise plus petit (l'implémentation complète de Noise de WireGuard fait moins de 400 lignes de code) et facilite son analyse formelle, mais l'application doit gérer séparément la gestion des identités. Noise est préféré pour les systèmes fermés (application-serveur, VPN), où PKI serait disproportionnée ; TLS est préféré pour les systèmes ouverts (web), où l'interopérabilité des certificats est nécessaire.

Les modèles Noise ont été analysés formellement dans le modèle de sécurité eCK (Canetti-Krawczyk étendu). Kobeissi, Bhargavan et Blanchet ont analysé Noise avec Proverif et ont obtenu des preuves d'authentification et de confidentialité des clés pour les 12 modèles Noise fondamentaux. Ces preuves supposent l'hypothèse standard de difficulté de DH (Curve25519), ainsi que la sécurité des fonctions AEAD et de hachage sous-jacentes. La nature compositionnelle de Noise (chaque DH est intégré progressivement) facilite son analyse par rapport aux protocoles complexes de type TLS, qui comportent de nombreuses transitions d'état. La vérification cryptographique de Noise a donné à WireGuard et à WhatsApp un haut niveau de confiance dans la sécurité de leur protocole avant son déploiement.

Pièges courants lors de l'implémentation de Noise : (1) Confusion de modèle : utiliser Noise_IK lorsque la clé statique du répondant n'est pas distribuée de manière fiable à l'avance entraîne une incohérence d'identité (l'initiateur peut chiffrer sans le savoir avec une mauvaise clé). (2) Protection contre les rejeux : Noise fournit une authentification, mais pas une protection contre les rejeux des messages de la phase Transport ; les valeurs uniques (compteur sur 64 bits) doivent être imposées et le retour à zéro (après 2^64 messages) doit déclencher un renouvellement des clés. (3) Intégrité du prologue : le prologue Noise (une chaîne d'octets intégrée à h avant le début de la poignée de main) doit inclure tout le contexte du protocole (version, choix des algorithmes) afin d'empêcher les attaques par rétrogradation. (4) Mauvaise utilisation des PSK : Noise prend en charge des extensions PSK pour mélanger des clés prépartagées ; les PSK doivent avoir une forte entropie et ne doivent pas être des mots de passe utilisateur.

Que signifie la notation de modèle Noise « es » dans une poignée de main ?

Noise est un cadre permettant de construire des protocoles d'échange de clés authentifiés au moyen d'un langage de modèles d'opérations DH. SymmetricState conserve la clé de chaînage (ck), le hachage de transcription (h) et la clé de chiffrement (k), mis à jour par MixKey/MixHash. Noise_XX fournit une authentification mutuelle en 1,5 RTT ; Noise_IK (WireGuard) s'achève en 1 RTT lorsque la clé du répondant est connue. Le hachage de poignée de main h sert de liaison de canal. Noise a été vérifié formellement pour tous les modèles fondamentaux avec Proverif. Il est préféré à TLS pour les protocoles de systèmes fermés (WireGuard, WhatsApp), où PKI est inutile. Une implémentation correcte exige une protection contre les rejeux, l'intégrité du prologue et des PSK à forte entropie.