La cryptographie d'un tunnel VPN

Un tunnel VPN repose sur trois opérations cryptographiques distinctes : un échange de clés qui établit un secret partagé sans qu'il transite sur le réseau, un chiffrement qui rend les données illisibles, et une authentification qui garantit qu'aucun octet n'a été modifié. Comprendre comment ces trois briques s'articulent permet de trier les vrais critères de sécurité des arguments marketing.

L'échange de clés

Le problème fondamental est de se mettre d'accord sur une clé secrète alors que tout ce qui passe sur le réseau est observable. La solution est l'échange Diffie-Hellman : chaque partie génère une paire de valeurs, s'envoie la partie publique, et combine sa partie privée avec la partie publique reçue pour obtenir un secret identique des deux côtés, qu'un observateur ne peut pas reconstituer.

Les tunnels modernes utilisent la variante sur courbe elliptique, avec la courbe Curve25519 (fonction X25519) : elle offre un niveau de sécurité équivalent à un module Diffie-Hellman classique de 3072 bits pour des calculs bien plus rapides et une implémentation moins sujette aux erreurs. OpenVPN et IKEv2 permettent aussi des groupes Diffie-Hellman classiques, dont certains, trop courts, sont aujourd'hui déconseillés. Un point essentiel : l'échange de clés éphémère doit être distinct de l'authentification. Utiliser directement une clé RSA de serveur pour chiffrer la clé de session, sans échange éphémère, prive le tunnel de confidentialité persistante.

La confidentialité persistante et la rotation des clés

La confidentialité persistante signifie que la compromission d'une clé, aujourd'hui, ne permet pas de déchiffrer le trafic enregistré hier. Elle s'obtient en dérivant des clés de session éphémères à chaque établissement, puis en les renouvelant périodiquement. WireGuard impose un nouvel échange au moins toutes les deux minutes d'activité, et bien avant qu'un compteur de messages ou de temps n'atteigne ses limites de sécurité. OpenVPN et IKEv2 renégocient leurs clés à intervalle configurable, généralement toutes les heures. Ce renouvellement est ce qui borne, dans le temps, la quantité de trafic qu'une clé unique protège — et donc l'ampleur des dégâts si elle fuite.

Le chiffrement authentifié

Chiffrer sans authentifier est une faute : un attaquant peut alors modifier le texte chiffré et, dans certains cas, en déduire le clair. Les tunnels actuels emploient un chiffrement authentifié avec données associées (AEAD), qui produit en une seule opération le texte chiffré et une étiquette d'authentification ; à la réception, une étiquette qui ne correspond pas entraîne le rejet pur et simple du paquet.

Deux familles dominent. AES-256-GCM est très rapide sur les processeurs dotés d'instructions AES dédiées, présentes sur la quasi-totalité des machines de bureau récentes. ChaCha20-Poly1305 est un chiffrement de flux qui n'a pas besoin d'accélération matérielle : il est plus rapide qu'AES sur les processeurs qui en sont dépourvus, typiquement d'anciens téléphones ou des équipements réseau modestes. WireGuard n'utilise que ChaCha20-Poly1305 ; OpenVPN et IKEv2 négocient l'un ou l'autre. Chaque paquet est chiffré avec un nombre à usage unique (nonce) qui ne doit jamais être réutilisé avec la même clé, contrainte qui est l'une des sources d'erreurs d'implémentation les plus classiques.

La dérivation de clés

Le secret brut issu de l'échange Diffie-Hellman n'est pas utilisé tel quel. Il passe par une fonction de dérivation — HKDF, ou la fonction de dérivation intégrée au cadre Noise pour WireGuard — qui en extrait plusieurs clés distinctes : une pour chaque sens de communication, parfois une pour l'authentification des en-têtes. Séparer les clés par usage évite qu'une faiblesse dans un contexte n'affecte les autres.

L'authentification des pairs

Dériver un secret ne sert à rien si l'on ne sait pas avec qui on l'a dérivé. Trois approches coexistent. WireGuard identifie chaque pair par sa clé publique, déclarée à l'avance de part et d'autre : simple, mais sans infrastructure de révocation. OpenVPN et IKEv2 utilisent des certificats X.509, avec une autorité de certification, ce qui permet la révocation mais ajoute une chaîne de confiance à maintenir. Une clé pré-partagée peut compléter l'un ou l'autre, notamment pour ajouter une résistance aux futurs ordinateurs quantiques. Le défaut le plus grave, côté client, est de ne pas vérifier le certificat du serveur : le tunnel se monte alors avec n'importe qui.

« Chiffrement de grade militaire » : ce que ça vaut

La formule revient dans presque toutes les publicités de VPN. Elle ne veut rien dire de précis : AES-256 est un standard public, publié, utilisé pour protéger aussi bien des communications gouvernementales que des connexions bancaires ou des sauvegardes personnelles. Sa robustesse théorique n'est contestée par personne et n'est pas le point faible d'un tunnel. Mettre en avant « AES-256 » comme argument différenciant revient à vanter le fait d'avoir des freins sur une voiture.

Ce qui distingue réellement deux implémentations se situe ailleurs : la qualité du générateur d'aléa qui produit les clés, l'absence de repli silencieux vers un algorithme affaibli si la négociation échoue, la gestion correcte des nonces, la vérification stricte de l'identité du serveur, la rapidité des mises à jour quand une faille est publiée dans la bibliothèque sous-jacente, et l'existence d'un audit du code. Ce sont ces éléments qu'il faut chercher, pas un nombre de bits.

Tailles de clés et équivalences

Comparer des tailles de clés entre familles d'algorithmes n'a de sens qu'à travers la notion de niveau de sécurité, exprimé en bits. Une clé symétrique de 128 bits offre déjà une marge considérable ; 256 bits couvrent la menace quantique sur le chiffrement symétrique. Côté échange de clés, une clé X25519 de 256 bits procure un niveau de sécurité d'environ 128 bits, jugé équivalent à un module Diffie-Hellman classique de 3072 bits ou à une clé RSA de 3072 bits. Autrement dit, une courbe elliptique « courte » n'est pas plus faible qu'un grand nombre RSA : les échelles ne sont pas les mêmes. Réclamer « toujours plus de bits » sans préciser l'algorithme est un contresens.

Vérifier la cryptographie d'un service

Sans lire le code, quelques éléments sont observables. La documentation doit indiquer précisément le protocole, la courbe ou le groupe d'échange, le chiffrement AEAD et la fréquence de renouvellement des clés — un service qui reste vague sur ces points en dit long. Le client doit refuser de se connecter si la vérification du serveur échoue, et non basculer silencieusement en mode non authentifié. Un test de capture réseau lors de l'établissement, comparé à la spécification du protocole annoncé, permet de confirmer qu'il s'agit bien de ce qui est promis. Enfin, l'existence d'un audit de sécurité applicatif publié, distinct de l'audit de non-journalisation, est le meilleur indicateur disponible.

Les risques réels

Les incidents cryptographiques marquants des dernières années n'ont presque jamais porté sur les algorithmes eux-mêmes, mais sur leur mise en œuvre : bogues de dépassement mémoire dans une bibliothèque TLS, générateurs d'aléa prévisibles sur certains équipements, mauvaise validation de certificats, réutilisation de nonces. À plus long terme, l'arrivée d'ordinateurs quantiques capables de casser Diffie-Hellman sur courbe elliptique menace la confidentialité persistante : un adversaire qui enregistre aujourd'hui du trafic chiffré pourrait le déchiffrer plus tard. Des mécanismes hybrides, combinant un échange classique et un échange résistant au quantique, commencent à être déployés pour parer ce scénario.

Ce qu'il faut retenir

Un tunnel sûr combine un échange de clés éphémère sur courbe elliptique, un chiffrement authentifié moderne, une rotation régulière des clés et une vérification stricte de l'identité du serveur. Le nombre de bits d'AES n'est pas un critère de choix ; la qualité de l'implémentation et l'existence d'un audit en sont. Le protocole qui encadre tout cela est décrit sur la page protocoles VPN comparés, et la manière dont un fournisseur protège ses serveurs sur la page architecture serveur.