La clé, c’est la route : pourquoi Verimesh utilise WireGuard

Beaucoup d’entre nous avons passé plus d’heures que nous ne l’aurions souhaité à regarder des gens tenter d’établir un tunnel IPsec entre deux pare-feu de fournisseurs différents. Tous ceux qui ont connu les guerres des VPN des années 2000 se souviennent de cette sensation : un fichier de configuration avec quarante paramètres, dont la moitié devait correspondre exactement de l’autre côté, et un journal de débogage qui ne vous disait rien quand ce n’était pas le cas.

Puis en 2018, un seul développeur, Jason Donenfeld, a soumis WireGuard pour son inclusion dans le noyau Linux, et Linus Torvalds, quelqu’un qui est célèbre pour ne pas mâcher ses mots, a écrit qu’il ne pouvait « que l’espérer » de le voir fusionné bientôt, l’appelant « une œuvre d’art » par rapport aux « horreurs que sont OpenVPN et IPSec ». C’est un éloge élevé. C’est entré dans le code principal en 2020.

Ainsi, quand Palo Alto Networks, qui vend les appareils de sécurité lourds que WireGuard fait tranquillement paraître surequipés, publie une explication Cyberpedia louant sa petite base de code, la cryptographie fixe et moderne et sa vitesse, cela vaut un moment de réflexion.

Le mesh chiffré en dessous de Verimesh fonctionne sur WireGuard, et nous faisons une chose en plus qui, autant que je sache, personne d’autre ne le fait : la clé de tunnel dérive de la même racine que l’identité de l’application.

Ce que Palo Alto approuve

WireGuard ne répond pas aux paquets qu’il ne peut pas authentifier. Envoyez une sonde à partir d’une clé inconnue et vous n’obtenez rien en retour : pas de bannière, pas de réponse, pas même une socket d’écoute à identifier. Pour un scan de port, le mesh n’existe simplement pas, et vous ne pouvez pas attaquer une surface que vous ne pouvez pas trouver.

Ensuite, il y a la taille. WireGuard compte environ 4 000 lignes de code. OpenVPN en compte environ 100 000. IPsec, en comptant son éventail de normes et d’implémentations, se rapproche de 400 000. Une base de code que vous pouvez lire en un après-midi est une que un être humain peut réellement auditer. Et l’auditabilité à cette échelle est elle-même une propriété de sécurité, que vous ne pouvez pas ajouter après coup à quelque chose deux ordres de grandeur plus grand.

La cryptographie est fixe. Aucune suite de chiffrement configurable, aucune négociation d’algorithme, aucune étape « dégradons-nous à ce que nous supportons tous les deux ». Juste Curve25519 pour l’échange de clés, ChaCha20-Poly1305 pour les données, BLAKE2s pour le hachage, Noise_IKpsk2 pour tenir l’ensemble. Toute la famille des attaques par dégradation n’existe pas ici, car il n’y a rien à négocier.

Et WireGuard route par clé. Sa table de routage cryptokey lie la clé publique de chaque pair aux plages IP que ce pair peut utiliser. En sortie, l’adresse de destination sélectionne la clé du pair, qui sélectionne la clé de session ; en entrée, un paquet décrypté n’est accepté que si sa source se situe dans la plage autorisée de ce pair. Il n’y a pas de vérification séparée « qui êtes-vous » boulonnée à côté d’une vérification « que pouvez-vous envoyer ». La clé publique est la route. L’identité et la portée s’avèrent être le même fait.

Une racine, pas deux

Dans pratiquement tous les déploiements WireGuard que j’ai vus, les clés ont leur propre vie. Quelqu’un exécute wg genkey, remet la moitié publique, range la moitié privée quelque part, et se retrouve avec une clé réseau qui n’a rien à voir avec l’identité de confiance de l’application au-dessus. Deux racines de confiance réconciliées par une feuille de calcul et les bonnes intentions.

Dans Verimesh, il y a une seule racine. Les clés de tunnel Curve25519 de chaque organisation sont ancrées dans son propre matériel de gestion décentralisée des clés (DKMS). La même infrastructure d’identité sur laquelle la couche application fonctionne déjà. Personne ne les émet. Il n’y a pas d’autorité de certification dans le chemin décidant quels tunnels sont permis, et aucun écart entre qui vous êtes au niveau réseau et qui vous êtes au-dessus.

Parce que les clés remontent au matériel clé propre de l’organisation, chaque tunnel peut être vérifié par rapport au journal des événements clés : vous pouvez demander quelle identité a établi quel tunnel et quand, et vérifier la réponse cryptographiquement plutôt que de faire confiance au propre compte de lui-même du serveur. Lorsque les clés font rotation, elles le font en synchronisation avec la pré-rotation DKMS (construite sur KERI), de sorte que l’identité du tunnel survit au cycle de vie des clés au lieu de se casser quand une clé change. Et puisque l’ensemble est auto-hébergé, aucun intermédiaire ne se place entre les deux en possédant le flux de données.

Alors pourquoi ne pas simplement utiliser mTLS, qui lie déjà l’identité dans la poignée de main de transport ?

Parce que garder les couches séparées, c’est l’intérêt. WireGuard déplace des paquets authentifiés et chiffrés entre des pairs qui détiennent la bonne clé, puis s’arrête. Il ne sait pas ce qu’est un retrait de consentement, quelle autorisation un message porte, ou si une credential a été révoquée. Cette logique appartient au-dessus du fil, dans DKMS. mTLS a tendance à attirer l’autorisation vers le bas dans la poignée de main de transport jusqu’à ce que vous ne puissiez plus auditer les deux séparément. Nous les gardons séparés à dessein, et les construisons sur la même racine.

Souverain jusqu’au fil

La pile est Open Source de haut en bas. WireGuard est dans le noyau ; la couche DKMS au-dessus est la nôtre, publiée sous la licence AGPLv3. Aucun plan de contrôle SaaS ne se place dans le chemin. Aucun tiers qui peut être assigné à comparaître pour les clés, personne qui consigne tranquillement qui a parlé à qui. Pour la santé suisse, où les données ne peuvent pas quitter le pays et la confiance ne peut pas quitter l’institution, cela doit tenir jusqu’au transport. La souveraineté qui s’arrête au niveau de l’application et loue sa tuyauterie réseau à quelqu’un d’autre n’est pas vraiment la souveraineté.

Ce que nous abandonnons

Aucune architecture n’est gratuite, et les gens qui gèrent ces systèmes peuvent le sentir quand vous prétendez le contraire. WireGuard demande trois échanges, dont nous sommes transparents :

D’abord, c’est un tunnel de couche 3. Il porte des paquets IP, pas des flux, vous ne disposez donc pas du multiplexage de flux natif qu’un transport basé sur TLS ou QUIC vous offre gratuitement. Tout ce qui a besoin de multiplexage le construit au-dessus du tunnel. Pour un mesh transportant des échanges authentifiés entre institutions, c’est discutablement le bon endroit pour le faire, mais c’est une véritable contrainte, pas une non-question.

Deuxièmement, la surface de configuration des pairs croît avec le mesh. WireGuard n’expédie pas de plan de contrôle qui remet et révoque les pairs de manière centrale ; chaque nœud connaît les pairs avec lesquels il communique. Dans un petit mesh gouverné de concentrateurs et de nœuds, c’est une fonctionnalité. Rien de central à compromettre. À grande échelle, cela devient du travail réel, et administrer les clés via DKMS est ce qui l’empêche de s’effondrer dans le cauchemar de la feuille de calcul d’avant.

Troisièmement, c’est plus jeune qu’IPsec. Palo Alto met cela sur la liste des inconvénients et cela a du sens. Mais la chose qui rend WireGuard jeune est la même chose qui le rend auditable : Donenfeld a jeté trois décennies d’optionnalité accumulée et a recommencé. C’est le genre d’échange que nous faisons volontiers.

La question quantique

WireGuard a une couche de clé pré-partagée optionnelle qui mélange un secret symétrique dans la poignée de main. Cela achète une chose : le trafic capturé aujourd’hui ne devient pas lisible plus tard même si l’échange de courbe elliptique finit par être cassé. L’attaque de « magasiner maintenant, décrypter plus tard » cesse de fonctionner. Ce n’est pas la même chose que la sécurité post-quantique au sens du NIST, et nous en sommes conscients. C’est une couverture efficace.

La route passant par la couverture a un nom : Rosenpass, un projet Open Source qui exécute un véritable échange de clés post-quantique devant cette fente de clé pré-partagée. C’est un chemin d’intégration pour le mesh, pas quelque chose que Verimesh expédie aujourd’hui.

Ce qui est le nôtre, c’est ce qui se passe ensuite. Parce que les clés de tunnel dérivent de DKMS, adopter des algorithmes post-quantiques est une rotation de clé de routine sur le journal des événements clés existant. Pas une réémission de certificat forcée et en bloc sur tout l’actif. Le transport émis par CA ne peut pas dire cela.

Une racine, du fil jusqu’en haut

Un mesh où la clé réseau et l’identité de l’application se développent à partir du même matériel DKMS ferme la couture où vivent la plupart des attaques intéressantes et presque tous les ennuyeux échecs d’audit : l’écart entre qui le réseau pense que vous êtes et qui l’application pense que vous êtes. WireGuard nous donne un transport suffisamment simple pour avoir confiance ; DKMS lui donne la même identité que tout le reste dans Verimesh de confiance déjà.

C’est le transport en dessous du déploiement Verimesh avec HIN, en dessous de tout dans l’architecture de confiance, où le chemin complet de la clé au tunnel au message audité est présenté de bout en bout. Ce qui fonctionne au-dessus est Verimesh lui-même.

La bonne tuyauterie est celle dont vous n’avez jamais à penser. C’est toute l’idée.