WireGuard® : un modèle de simplicité et d’efficacité

Un protocole simplifié

L’une des premières caractéristiques confirmant la simplicité de WireGuard® évoque l’absence de protocole et cryptographies primitives. En effet, contrairement à d’autres solutions, WireGuard® offre une compatibilité limitée de protocoles et fonctionnalités de chiffrage. L’agilité cryptographique (Cipher agility) favorise considérablement la complexité lorsque des obligations de maintenance sont nécessaires. Une simple faille au sein d’une solution complexifiée nécessitera des mises à jour pour chaque point de terminaison afin d’assurer la sécurité des utilisateurs. Ainsi, plus vous complexifiez le chiffrement de vos données, plus vous serez amené à effectuer des mises à jour.

Au lieu de considérer des fonctionnalités caractérisées par une primitive cryptographique complexe, WireGuard® privilégie des solutions garantissant une sécurité et efficacité cryptographique optimale. Cette technologie utilise ChaCha20 pour le chiffrement symétrique (authentifié avec Poly1305) en utilisant la construction AEAD de RFC7539, Curve25519 pour ECDH, BLAKE2s pour le hachage classique et hachage par clé (décrits dans la RFC7693), SipHash24 pour les clés de hachage et HKDF pour la dérivation de clés (décrit dans RFC5869). À titre comparatif, l’OpenSSL — deuxième protocole le plus simplifié — fonctionne avec 36 algorithmes primaires.

En conséquence, WireGuard® dispose de moins de lignes de code (LoC) par rapport à ses concurrents. Cette caractéristique facilite les traitements avec le protocole et favorise inévitablement des économies relatives aux calculs informatiques. En d’autres termes, cette technologie se veut plus simple et permet d’atteindre les mêmes objectifs depuis une meilleure rapidité et sécurité.

Une combinaison de primitives pour favoriser la sécurité

Au lieu de débuter ses traitements avec un grand nombre de primitives cryptographiques, WireGuard® utilise le Noise framework pour combiner certains éléments sélectionnés et garantir votre sécurité. Noise est une solution dédiée aux protocoles cryptographiques. Celle-ci est basée sur l’échange de clés Diffie-Hellman (DH) où 2 acteurs échangent des messages (prise de contact) avant de générer une clé partagée suite à une séquence d’opérations DH. Cette clé est ensuite utilisée pour envoyer des messages de transport chiffrés.

La séquence et les propriétés des messages de prise de contact sont organisées suivant des modèles prédéfinis. Il existe 12 modèles fondamentaux caractérisés par deux caractères indiquant l’état des clés statiques de l’initiateur et du répondeur. WireGuard® utilise le modèle Noise_IK. La lettre « I » de ce terme technique se réfère à la clé statique de l’initiateur immédiatement transmise au répondeur, et ce, malgré un masquage d’identité réduit ou absent. Enfin, la lettre « K » fait référence à la clé statique du répondeur connue de l’initiateur.

Voici un résumé des éléments constituant le Noise Framework :

• CE : clé publique éphémère du client (générée pour une session unique).
• CES : partage statique-éphémère côté client. Ce processus Diffie-Hellman est réalisé via une clé privée éphémère du client ainsi qu’une clé publique statique associée au destinataire.
• S : clé publique statique. En pratique, le client envoie une clé publique et statique lors d’un 1er message.
• CSS : partage statique-statique côté client. Ce processus Diffie-Hellman est réalisé via la clé statique et privée du client ainsi qu’une clé publique statique associée au destinataire.
• RE : clé publique éphémère du destinataire (générée pour une session unique).
• REE : partage éphémère-éphémère côté destinataire. Ce processus Diffie-Hellman est réalisé via une clé privée éphémère du client ainsi qu’une clé publique éphémère associée au destinataire.
• RES : partage éphémère-statique côté destinataire. Ce processus Diffie-Hellman est réalisé via une clé privée éphémère du client ainsi qu’une clé publique statique associée au destinataire.

En appliquant le modèle Noise_IK, WireGuard® réduit le délai des traitements aller-retour du protocole. En d’autres mots, un seul et unique message de l’émetteur (1) et un message de réponse (2) sont nécessaires pour établir une connexion. Les messages suivants (3, 4, etc.) bénéficient alors de l’authentification de l’émetteur et du destinataire et sont également protégés face à d’éventuelles tentatives d’usurpation d’identité de clé.

Il existe un risque théorique relatif à l’authentification du premier paquet pouvant engendrer une vulnérabilité (tentatives de relecture). Un pirate pourrait alors intercepter ce message afin de le consulter à une date ultérieure en usurpant l’identité de l’émetteur. Cependant, WireGuard® utilise une primitive d’horodatage (TAI64N), une solution idéale pour éviter ce type de scénarios. Seul l’horodatage le plus récent envoyé au client est enregistré et considéré. Les autres paquets seront ainsi rejetés. En cas de redémarrage du serveur, une tentative de relecture restera inefficace. En effet, la reconnexion des clients évoquera des horodatages plus récents supprimant les anciennes informations temporelles.

Grâce à cette primitive d’horodatage, le modèle Noise_IK est caractérisé par une absence de messages non authentifiés et échangés entre l’émetteur et le destinataire. Ainsi, aucune réponse ne sera attribuée aux paquets qui n’ont pas encore été authentifiés. Le serveur fonctionne discrètement en arrière-plan et le protocole reste sécurisé.

Goulot d’étranglement (Bottlenecks) et atténuation DDoS

L’un des goulots d’étranglement majeurs dans le domaine du chiffrement informatique concerne les ressources techniques nécessaires au processeur pour procéder aux chiffrements de données. Par ailleurs, ce processus impose également des économies de performance. En effet, une utilisation intensive du CPU peut favoriser la vulnérabilité d’un système et faciliter des tentatives de piratage. Voilà pourquoi WireGuard® propose une option « de secours » consistant à utiliser des paquets de réponse de cookies au lieu de traiter directement les messages de prise de contact.

Traditionnellement, l’utilisation de cookies peut favoriser une vulnérabilité face aux attaques où le serveur est amené à répondre à des demandes non authentifiées. Toutefois, ce problème peut être résolu en exigeant que tous les messages disposent d’une adresse MAC associée à une clé publique. Cela permet à l’émetteur de s’assurer de la destination du message envoyé. En d’autres termes, l’émetteur n’a pas à rechercher le destinataire, car à une clé publique et associée est utilisée.

Par ailleurs, pour empêcher l’interception d’adresses MAC, celles-ci doivent être chiffrées grâce à une solution AEAD avec un nonce aléatoire et étendu au lieu d’un texte brut. Un champ de données supplémentaire de l’AEAD est utilisé pour lier les réponses des cookies aux messages d’initiation. Ce processus protège l’émetteur des attaques DDoS tentant d’utiliser des messages de cookies frauduleux (considération d’adresses MAC incorrectes).

De cette façon, les cookies sont utilisés en tant que clés pour définir des adresses MAC. Lorsque le destinataire est affecté par une surcharge de traitements, seuls les messages disposant de ces adresses MAC supplémentaires sont acceptés. Grâce à ce processus, les messages de cookie sont réduits suite à la prise de contact ou réponses favorisant une atténuation des attaques DDoS.

De même, lorsqu’un mécanisme de repli est appliqué, le Noise_IK reste valide où deux messages supplémentaires sont transmis :

Deux éléments complémentaires de l’infographie de réponse aux cookies sont ainsi vérifiés :

• TS1 + MAC: le 1er horodatage (ou le plus ancien) et l’adresse MAC du client.
• TS2 + MAC: le 2ème horodatage (ou le plus récent) et l’adresse MAC du client.

Bien que les messages 1 et 3 soient essentiels pour garantir une prise de contact identique, ceux-ci sont caractérisés par un horodatage et une adresse MAC. Le 1er ne peut pas être traité en tant que 3ème message. Cela permet d’éviter les attaques de relecture (replay) tout en atténuant les risques liés aux attaques DDoS.

Faire face aux menaces de suprématie quantique

La suprématie quantique se démocratise progressivement et deviendra une option viable et accessible à plus d’utilisateurs. Celle-ci évoquera également une réelle menace pour le domaine de la cybersécurité. En effet, un scénario réaliste où l’algorithme de Shor permet aux systèmes quantiques de compromettre la cryptographie à clé publique (RSA, DSA, EDSA, etc.) et engendre de véritables inquiétudes.

Ce phénomène troublant favorise certaines options qui n’impliquent aucune clé publique. Celles-ci s’appuieront certainement sur des algorithmes à clé symétrique (ou « clé secrète »), tels que la solution de chiffrement Diffie-Hellman utilisée depuis WireGuard®. En pratique, cette méthode est effectivement efficace pour faire face à l’algorithme de Shor et permet de prévenir les scénarios post-quantiques.

De même, d’après certaines suggestions, les systèmes à clés symétriques pourraient être vulnérables face à une autre menace - l’algorithme de Grover. Toutefois, cet algorithme ne permettra pas aux ordinateurs quantiques de résoudre des problèmes NP-Complets en temps polynomial. En d’autres mots, cela signifie que le délai nécessaire pour compromettre un protocole à clé symétrique via un système quantique serait bien trop important pour révéler une réelle efficacité.

Alors que d’autres algorithmes quantiques tels que le modèle Shor offrent une accélération exponentielle par rapport aux solutions classiques, l’algorithme de Grover ne fournit qu’une accélération quadratique. Ce terme désigne une clé symétrique de 128 bits brutalement forcée en 264 répétitions d’instructions (au lieu de 2128), un procéder insuffisant pour permettre un calcul polynomial.