La clé est la route : pourquoi Verimesh s’exécute sur WireGuard

Beaucoup d’entre nous avons passé plus d’heures que nous ne l’aimerions à admettre en regardant des gens essayer de mettre en place un tunnel IPsec entre deux pare-feu de fournisseurs différents. Quiconque a vécu les guerres VPN des années 2000 se souvient 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 inclusion dans le noyau Linux, et Linus Torvalds, quelqu’un qui a la réputation de ne pas mâcher ses mots, a écrit qu’il ne pouvait « qu’espérer » que cela soit fusionné bientôt, l’appelant « une œuvre d’art » à côté des « horreurs qu’est OpenVPN et IPSec ». C’est un grand compliment. C’est arrivé en mainline en 2020.

Donc quand Palo Alto Networks, qui vend les appliances de sécurité lourdes que WireGuard rend discrètement surconçues, publie un explicitateur Cyberpedia qui fait l’éloge de sa petite base de code, de sa cryptographie moderne fixe et de sa vitesse, cela vaut la peine d’y consacrer un moment.

Le maillage chiffré en dessous de Verimesh s’exécute sur WireGuard, et nous faisons une chose en plus 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 en retour : pas de bannière, pas de réponse, pas même un socket d’écoute à identifier. Pour un balayage de port, le maillage n’existe simplement pas, et vous ne pouvez pas attaquer une surface que vous ne pouvez pas trouver.

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

La cryptographie est fixe. Pas de suites de chiffrement configurables, pas de négociation d’algorithme, pas d’étape « utilisons ce que nous supportons tous les deux ». 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 par dégradation n’existe pas ici, car il n’y a rien à négocier.

Et WireGuard effectue un routage par clé. Sa table de routage cryptokey relie 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échiffré 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 « qui êtes-vous » séparé boulonné à côté d’un contrôle « que pouvez-vous envoyer ». La clé publique est la route. L’identité et la accessibilité s’avèrent être le même fait.

Une racine, pas deux

Dans presque tous les déploiements WireGuard que j’ai vus, les clés vivent une vie qui leur est propre. Quelqu’un exécute wg genkey, distribue 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é sur laquelle l’application au-dessus lui fait confiance. Deux racines de confiance réconciliées par un tableur et les bonnes intentions.

Dans Verimesh il y a une racine, et tout en dépend. Chaque organisation a sa propre identité, construite sur Decentralized Key Management (DKMS) — la même infrastructure d’identité sur laquelle la couche application s’exécute déjà. Sous cette identité organisationnelle, chaque connexion est établie par un Iris Agent qui détient sa propre identité d’agent : un actif vérifiable, enraciné dans le matériel DKMS de l’organisation, qui représente un nœud du maillage plutôt que l’institution dans son ensemble. Les clés de tunnel Curve25519 dérivent de cette identité d’agent — pas d’une chaîne que quelqu’un a générée une fois avec wg genkey et collée dans une config. 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 d’agent, sous sa propre racine. Aucun écart entre qui vous êtes au niveau réseau et qui vous êtes au-dessus.

Cette couche intermédiaire n’est pas une cérémonie. C’est ce qui rend le maillage pratique. Une organisation peut lancer 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 groupement de cliniques — chacun avec sa propre identité d’agent sous la même racine organisationnelle, chacun d’eux vérifiablement la même institution. Et le réseau peut se déplacer à sa propre cadence : quand une clé de tunnel doit changer, vous faites tourner l’identité d’agent dont elle dérive, sans toucher à l’identité organisationnelle ou aux clés d’application au-dessus. Le fil peut s’agiter en dessous tandis que l’identité de l’institution reste exactement où elle est.

Parce que chaque identité d’agent remonte au matériel clé de l’organisation, chaque tunnel peut être vérifié par rapport au journal d’événements clés : vous pouvez demander quelle identité a établi quel tunnel et quand, et vérifier la réponse de façon cryptographique plutôt que de faire confiance au compte rendu du serveur sur lui-même. Quand les clés tournent, elles tournent en synchronisation avec la pré-rotation DKMS (construite sur KERI), donc l’identité du tunnel survit 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 place 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 garder 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é, et ensuite il 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 à 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ées 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 place dans le chemin. Aucun tiers qui puisse être assigné à comparaître pour les clés, personne ne consigne 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 plomberie réseau à quelqu’un d’autre n’est pas vraiment la souveraineté.

Ce que nous sacrifions

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

Premièrement, 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 transportant l’échange authentifié entre institutions, c’est arguablement 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 pas de plan de contrôle qui distribue et révoque les pairs de façon centralisée ; chaque nœud connaît les pairs avec lesquels il communique. Dans un petit maillage gouverné de hubs et de nœuds, c’est une caractéristique. Rien de central à compromettre. À grande échelle, cela devient du vrai travail, et administrer les clés via DKMS est ce qui empêche cela de s’effondrer dans le cauchemar du tableur d’avant.

Troisièmement, c’est plus jeune qu’IPsec. Palo Alto met ceci sur la liste des inconvénients et cela a du sens. 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 genre de compromis que nous faisons volontiers.

La question quantique

WireGuard dispose d’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 par courbe elliptique est finalement cassé. L’attaque de stockage aujourd’hui-déchiffrement ultérieurement cesse de fonctionner. Ce n’est pas la même chose que la sécurité post-quantique au sens 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 vrai échange de clés post-quantique devant cette place 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 vient ensuite. Parce que les clés de tunnel dérivent d’une identité DKMS, adopter les algorithmes post-quantiques est une rotation banale de cette identité sur le journal d’événements clés existant — la couche réseau se déplaçant sur sa propre cadence à nouveau, cette fois vers un algorithme plus fort. Pas une réémission de certificat forcée et tout-d’un-coup à travers un domaine entier. Les transports émis par CA ne peuvent 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é sur laquelle tout le reste de Verimesh fait déjà confiance.

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

La bonne plomberie est celle dont vous n’avez jamais besoin de penser. C’est toute l’idée.