La clé, c’est la route : pourquoi Verimesh fonctionne sur WireGuard
Beaucoup d’entre nous avons passé plus d’heures que nous ne l’aimerions à regarder des gens essayer de mettre en place un tunnel IPsec entre deux pare-feu de fournisseurs différents. Tous ceux qui ont vécu les guerres VPN des années 2000 se souviennent du sentiment : un fichier de configuration avec quarante paramètres, dont la moitié devaient 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 inclusion dans le noyau Linux, et Linus Torvalds, quelqu’un qui a la réputation de ne pas mâcher ses paroles, a écrit qu’il ne pouvait « qu’espérer » qu’il soit fusionné bientôt, l’appelant « une œuvre d’art » à côté des « horreurs qu’sont OpenVPN et IPSec ». C’est un grand compliment. Il s’est retrouvé dans la branche principale en 2020.
Donc quand Palo Alto Networks, qui vend les appareils de sécurité lourds que WireGuard rend discrètement surengénérés, publie un expliquant Cyberpedia louant sa base de code réduite, sa cryptographie moderne fixe et sa vitesse, cela vaut le coup de s’y arrêter.
Le maillage chiffré sous-jacent à Verimesh fonctionne sur WireGuard, et nous faisons une chose par-dessus qui, autant que je sache, personne d’autre ne fait : la clé du 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 : pas de bannière, pas de réponse, pas même un socket en écoute à identifier. Pour un scan de port, le maillage n’existe simplement pas, et vous ne pouvez pas attaquer une surface que vous ne pouvez pas trouver.
Puis il y a la taille. WireGuard compte environ 4 000 lignes de code. OpenVPN en compte environ 100 000. IPsec, en comptant son déploiement de normes et d’implémentations, s’approche des 400 000. Une base de code que vous pouvez lire en une après-midi est une base de code qu’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 rétrofiter sur quelque chose deux ordres de magnitude plus large.
La cryptographie est fixe. Pas de suites de chiffrement configurables, pas de négociation d’algorithmes, pas d’étape « passons à ce que nous deux supportons ». Simplement Curve25519 pour l’échange de clés, ChaCha20-Poly1305 pour les données, BLAKE2s pour le hachage, Noise_IKpsk2 pour tenir le tout ensemble. Toute la famille des attaques de régression n’existe pas ici, parce qu’il n’y a rien à négocier.
Et WireGuard route par clé. Sa table de routage cryptographique lie la clé publique de chaque pair aux plages d’adresses 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 contrôle séparé « qui êtes-vous » attaché à côté d’un contrôle « que pouvez-vous envoyer ». La clé publique est la route. L’identité et la disponibilité s’avèrent être le même fait.
Une racine, pas deux
Dans presque tous les déploiements de WireGuard que j’ai vus, les clés mènent une vie qui leur est propre. Quelqu’un exécute wg genkey, distribue la moitié publique, archive la moitié privée quelque part, et se retrouve avec une clé réseau qui n’a rien à voir avec l’identité que l’application au-dessus lui fait confiance. Deux racines de confiance réconciliées par une feuille de calcul et de bonnes intentions.
Dans Verimesh, il y a une seule racine, et tout s’y accroche. Chaque organisation a sa propre identité, construite sur Decentralized Key Management (DKMS) — la même infrastructure d’identité sur laquelle la couche application fonctionne déjà. Sous cette identité organisationnelle, chaque connexion est établie par un Iris Agent qui détient sa propre identité agentive : un actif vérifiable, enraciné dans le matériel DKMS de l’organisation, qui représente un nœud sur le maillage plutôt que l’institution dans son ensemble. Les clés de tunnel Curve25519 dérivent de cette identité agentive — pas d’une chaîne que quelqu’un a générée une fois avec wg genkey et collée dans une configuration. Il n’y a pas d’autorité de certification tierce dans le chemin décidant quels tunnels sont autorisés ; l’organisation émet ses propres identités agentives, sous sa propre racine. Aucun écart entre qui vous êtes à la couche réseau et qui vous êtes au-dessus.
Cette couche intermédiaire n’est pas du cérémonial. C’est ce qui rend le maillage pratique. Une organisation peut mettre en place plus d’un nœud — des sites séparés, des centres de données séparés, les deux extrémités d’un groupe clinique — chacun avec sa propre identité agentive sous la même racine organisationnelle, chacun étant vérifiablement la même institution. Et le réseau peut avancer sur son propre rythme : quand une clé de tunnel doit changer, vous faites tourner l’identité agentive dont elle dérive, sans toucher à l’identité organisationnelle ou aux clés d’application au-dessus. Le câble peut bouger sous la surface tandis que l’identité de l’institution reste exactement où elle est.
Parce que chaque identité agentive remonte au matériel clé 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 de manière cryptographique plutôt que de faire confiance au propre compte d’un serveur. Quand les clés tournent, elles tournent en synchronisation avec la pré-rotation DKMS (construite sur KERI), donc l’identité du tunnel survive au cycle de vie de la clé au lieu de se casser quand une clé change. Et comme le tout est auto-hébergé, aucun intermédiaire ne se tient au milieu en possédant le flux de données.
Alors pourquoi ne pas simplement utiliser mTLS, qui lie déjà l’identité à la négociation de transport ?
Parce que maintenir les couches séparées est le point. WireGuard déplace des paquets authentifiés et chiffrés entre des pairs qui détiennent la bonne clé, puis il s’arrête. Il ne sait pas ce qu’est un retrait de consentement, quelle autorisation un message porte, ou si une accréditation a été révoquée. Cette logique appartient au-dessus du câble, dans DKMS. mTLS tend à tirer l’autorisation vers le bas dans la négociation de transport jusqu’à ce que vous ne puissiez plus auditer les deux séparément. Nous les gardons séparés intentionnellement, 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 l’AGPLv3. Aucun plan de contrôle SaaS ne se tient dans le chemin. Aucun tiers qui pourrait être assigné à comparaître pour les clés, personne ne journalise discrètement qui a parlé à qui. Pour les soins de santé suisses, 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 à la couche application et loue sa tuyauterie réseau à quelqu’un d’autre n’est pas vraiment de la souveraineté.
Ce à quoi nous renonçons
Aucune architecture n’est gratuite, et les gens qui gèrent ces systèmes peuvent la 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 transporte des paquets IP, pas des flux, donc vous n’obtenez pas le multiplexage de flux natif qu’un transport basé sur TLS ou QUIC vous donne gratuitement. Tout ce qui a besoin de multiplexage le construit au-dessus du tunnel. Pour un maillage portant un échange authentifié entre institutions, c’est sans doute le bon endroit, mais c’est une vraie contrainte, pas un non-problème.
Deuxièmement, la surface de configuration des pairs croît avec le maillage. WireGuard n’expédie aucun plan de contrôle qui distribue et révoque les pairs de manière centralisée ; chaque nœud connaît les pairs avec lesquels il parle. Dans un petit maillage gouverné de hubs et de nœuds, c’est une fonctionnalité. Rien de central à compromettre. À grande échelle, cela devient un vrai travail, et administrer les clés via DKMS est ce qui l’empêche de s’effondrer dans le cauchemar des feuilles de calcul d’avant.
Troisièmement, c’est plus jeune qu’IPsec. Palo Alto met cela sur la liste des inconvénients et c’est logique. Mais ce 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 type d’échange que nous sommes heureux de faire.
La question quantique
WireGuard a une couche de clé pré-partagée optionnelle qui mélange un secret symétrique dans la négociation. Cela achète une chose : le trafic capturé aujourd’hui ne devient pas lisible plus tard même si l’échange de courbe elliptique est finalement cassé. L’attaque de stockage-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 au-delà de la couverture a un nom : Rosenpass, un projet Open Source qui exécute un véritable échange de clés post-quantique devant cet emplacement de clé pré-partagée. C’est un chemin d’intégration pour le maillage, pas quelque chose que Verimesh expédie aujourd’hui.
Ce qui est nôtre est ce qui se passe ensuite. Parce que les clés de tunnel dérivent d’une identité DKMS, adopter des algorithmes post-quantiques est une rotation routinière de cette identité sur le journal des événements clés existant — la couche réseau se déplaçant sur son propre rythme à nouveau, cette fois vers un algorithme plus fort. Pas une réissuance de certificat forcée, tout à la fois, à travers un domaine entier. Le transport émis par CA ne peut pas dire cela.
Une racine, du fil vers le haut
Un maillage où la clé réseau et l’identité d’application croissent à 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 assez simple pour faire confiance ; DKMS lui donne la même identité que tout le reste dans Verimesh en fait déjà confiance.
C’est le transport sous le déploiement de Verimesh avec HIN, sous tout dans l’Architecture de confiance, où le chemin complet de la clé au tunnel au message audité est exposé de bout en bout. Ce qui s’exécute au-dessus est Verimesh lui-même.
Les bons tuyaux sont ceux auxquels vous n’avez jamais besoin de penser. C’est toute l’idée.
