Preuves à divulgation nulle et dVPN : Confidentialité Web3

Le problème de la confiance dans les VPN traditionnels

Vous êtes-vous déjà demandé pourquoi nous confions l'intégralité de notre vie numérique à un fournisseur de VPN en espérant simplement qu'il ne soit pas trop curieux ? C'est assez aberrant qu'en 2025, notre meilleure défense en matière de vie privée repose encore sur la "parole d'honneur" d'une entreprise centralisée.

La plupart des services traditionnels vantent leurs politiques "no-logs" (sans journaux d'activité), mais en tant qu'expert réseau, je vois la réalité au niveau des paquets. Même s'ils n'enregistrent pas votre historique de navigation, ils voient toujours votre adresse IP réelle et vos données de connexion au moment où vous vous identifiez.

• Points de défaillance centralisés : Les fournisseurs classiques s'appuient sur des clusters qu'ils contrôlent. Si un gouvernement émet une assignation ou si un pirate obtient un accès "root", vos données sont là, exposées dans la mémoire vive (RAM).
• Le déficit de confiance : Vous devez les croire sur parole. Une étude de 2024 publiée par ExpressVPN souligne que les utilisateurs n'ont d'autre choix que de se fier à l'honnêteté du fournisseur, car il n'existe aucun moyen technique de vérifier ce qui se passe réellement dans leur infrastructure backend.
• Lois sur la conservation des données : Dans de nombreuses juridictions, les fournisseurs d'accès à Internet (FAI) et les sociétés de VPN sont légalement contraints de conserver certaines métadonnées, ce qui rend le "no-logs" juridiquement impossible dans ces régions.

J'ai passé des années à étudier la surveillance exercée par les FAI, et le problème reste systématiquement l'intermédiaire. Si le serveur doit connaître votre identité pour vous authentifier, cette information devient une faille potentielle.

D'après Wikipédia, les preuves à divulgation nulle de connaissance (Zero-Knowledge Proofs ou ZKP) ont été conçues dès 1985 pour résoudre précisément ce dilemme : "prouver son identité sans révéler de secrets". Nous voyons enfin ce concept passer des publications mathématiques au code informatique concret.

Quoi qu'il en soit, le véritable problème ne vient pas seulement des acteurs malveillants, mais de l'architecture elle-même. Nous avons besoin d'un système où le réseau peut vérifier que vous avez payé ou que vous possédez un droit d'accès, sans jamais savoir qui vous êtes réellement.

Dans la section suivante, nous verrons comment les ZKP renversent la situation pour résoudre définitivement ce problème de confiance.

Au fait, qu'est-ce qu'une preuve à divulgation nulle de connaissance (ZKP) ?

Si vous avez déjà essayé d'expliquer la cryptographie à quelqu'un qui n'est pas un mordu des réseaux, vous connaissez la difficulté. Pourtant, les preuves à divulgation nulle de connaissance (ou Zero-Knowledge Proofs - ZKP) sont assez intuitives si l'on oublie un instant les nombres premiers pour imaginer une grotte magique.

La méthode classique pour vulgariser ce concept est l'allégorie de la grotte d'Ali Baba. Imaginez une grotte circulaire avec deux chemins, A et B, qui se rejoignent au fond devant une porte magique. Peggy connaît le mot secret pour ouvrir cette porte ; Victor veut la preuve qu'elle ne ment pas, mais Peggy refuse de lui révéler le mot de passe.

Pour le prouver, Peggy entre dans la grotte pendant que Victor attend à l'extérieur. Victor crie alors : « Sors par le chemin A ! ». Si Peggy est devant la porte, elle l'ouvre et apparaît par le bon chemin. S'ils répètent l'opération 20 fois et qu'elle ne se trompe jamais, les mathématiques confirment qu'elle connaît presque certainement le mot secret. Pourquoi ? Parce qu'à chaque tour réussi, la probabilité qu'elle ait simplement eu de la chance est divisée par deux. Après 20 tours, les chances qu'elle soit une impostrice tombent à environ une sur un million. C'est ce que nous appelons la « robustesse » (soundness) dans l'univers mathématique.

Comme le souligne Concordium, il s'agit d'un changement de paradigme : on passe du « partage de données » au « partage de preuves ». Pour qu'un protocole soit réellement considéré comme une ZKP, il doit valider trois critères techniques :

• Complétude (Completeness) : Si l'affirmation est vraie, un prouveur honnête convaincra toujours le vérificateur. Aucun « faux négatif » n'est admis dans la logique.
• Robustesse (Soundness) : Si Peggy ment, elle ne devrait pas pouvoir tromper Victor, sauf par une chance infime et astronomique. Selon le NIST, on parle souvent de « ZKP de connaissance », où l'on prouve que l'on possède le « témoin » (witness), c'est-à-dire le secret.
• Divulgation nulle de connaissance (Zero-knowledge) : C'est le point crucial. Victor n'apprend rien sur le mot de passe lui-même, seulement que Peggy le détient.

Dans mon domaine, nous considérons généralement l'identité comme un risque (un liability). Si un nœud dVPN connaît votre clé publique, cela constitue une trace numérique au niveau du paquet. La ZKP inverse cette logique.

Un article de 2024 de Concordium mentionne que, pour les entreprises, la confidentialité devient une « exigence de base » plutôt qu'une simple fonctionnalité. Qu'il s'agisse de prouver que vous avez plus de 18 ans pour un site marchand ou de vérifier un dossier de santé, la ZKP nous permet de traiter la logique métier sans jamais exposer les données brutes.

Voyons maintenant comment cela permet concrètement de masquer votre adresse IP au sein d'un réseau décentralisé.

L'application des ZKP à l'écosystème dVPN

Alors, comment concrètement intégrer ces mathématiques de « caverne magique » dans un dVPN ? C'est une chose d'en discuter de manière théorique, mais lorsqu'on traite des paquets de données bruts arrivant sur un nœud, la réalité est bien plus complexe. Dans un réseau standard, le serveur vérifie généralement votre identité via une base de données — ce qui constitue une faille de confidentialité majeure.

L'objectif ici est d'instaurer une authentification anonyme. Nous voulons que le nœud sache que vous détenez le droit d'utiliser la bande passante, sans pour autant connaître votre identité ou votre historique de facturation.

La plupart des projets dVPN modernes se tournent vers les zk-SNARKs (Succinct Non-Interactive Arguments of Knowledge). Comme nous l'avons vu précédemment, ces protocoles sont idéaux car ils ne nécessitent pas de multiples échanges de données entre les parties.

• Preuves d'abonnement : Vous pouvez prouver sur la blockchain que vous avez payé un forfait mensuel. Le nœud vérifie une « preuve » que votre portefeuille appartient à l'ensemble des comptes « ayant payé », sans jamais avoir accès à l'adresse de votre portefeuille.
• Contrôle d'accès : Au lieu d'utiliser un identifiant et un mot de passe qu'un fournisseur d'accès à Internet (FAI) pourrait intercepter ou qu'un nœud pourrait enregistrer, vous envoyez une preuve cryptographique. C'est l'équivalent de présenter un badge « vérifié » sans avoir à montrer sa carte d'identité.
• Réputation des nœuds : Les nœuds peuvent également utiliser les ZKP pour prouver leur intégrité — par exemple, démontrer qu'ils n'ont pas altéré les paquets — sans pour autant dévoiler l'architecture interne de leur serveur.

Dans un réseau P2P, votre adresse IP est pratiquement votre adresse domiciliaire. Si un opérateur de nœud est malveillant, il pourrait enregistrer chaque IP qui se connecte. En utilisant les ZKP pour le « handshake » (la phase d'établissement de la connexion), nous séparons l'« identité » de la « connexion ».

Cloudflare a d'ailleurs commencé à utiliser des « preuves un-parmi-plusieurs » (one-out-of-many proofs) dès 2021 pour l'attestation Web privée. Cela permet concrètement à un utilisateur de prouver qu'il appartient à un groupe d'utilisateurs autorisés (comme les « abonnés payants ») sans révéler de quel utilisateur spécifique il s'agit. Si un géant du secteur utilise cette technologie pour vérifier du matériel sans fuite de données, il est certain que les dVPN font de même pour sécuriser les sessions utilisateurs.

Des projets comme SquirrelVPN implémentent actuellement ces handshakes basés sur les zk-SNARKs pour garantir que même le nœud auquel vous êtes connecté n'ait absolument aucune idée de qui vous êtes réellement.

Dans la section suivante, nous examinerons comment ces preuves permettent de faire fonctionner l'aspect économique du partage de bande passante sans compromettre la sécurité des participants.

Minage de bande passante et récompenses tokenisées

Considérez le « minage de bande passante » comme le Airbnb de l'internet. Vous autorisez des inconnus à emprunter un couloir numérique au sein de votre réseau domestique et, en échange, vous recevez une rémunération sous forme de tokens. Cependant, sans les preuves à divulgation nulle de connaissance (ZKP), ces inconnus — ou le réseau lui-même — pourraient en voir beaucoup trop sur ce qui se passe chez vous.

Dans une architecture de pair à pair (P2P), nous devons prouver deux choses : que le nœud a effectivement acheminé les données et que l'utilisateur dispose bien des crédits nécessaires pour payer. Historiquement, cela signifiait que le réseau devait tracer chaque paquet, ce qui constituait une faille de confidentialité massive.

• Preuve de routage (Proof of Routing) : Nous utilisons les ZKP pour vérifier qu'un nœud a traité un volume de trafic spécifique. Le nœud fournit une « preuve » à la blockchain qui correspond au « reçu » de l'utilisateur, mais aucune des parties ne révèle la charge utile réelle ou la destination des paquets.
• Incitations tokenisées : Les opérateurs génèrent des revenus en fonction de la disponibilité (uptime) et du débit vérifiés. Puisque la vérification repose sur le zero-knowledge, le réseau n'a pas besoin de connaître l'identité réelle de l'opérateur pour envoyer les tokens dans son portefeuille.
• Échange équitable : Comme le souligne Wikipedia, ces protocoles garantissent qu'un « prouveur » (le nœud) peut convaincre le « vérificateur » (le réseau) que le travail a été accompli sans révéler les données sensibles inhérentes à ce travail.

Honnêtement, j'ai vu assez de cas de surveillance par les fournisseurs d'accès à internet (FAI) pour savoir que si vous n'anonymisez pas la couche de paiement, vous ne protégez pas réellement votre vie privée. Si votre adresse de portefeuille est liée à votre adresse IP résidentielle et à vos journaux de trafic, l'aspect « VPN » du dVPN devient pratiquement inutile.

Ensuite, nous allons examiner comment nous empêchons le réseau de ralentir tout en effectuant ces calculs mathématiques complexes — il s'agit de l'aspect « Succinct » (le 'S' de zk-SNARKs) de l'énigme.

Les défis techniques des ZKP dans les réseaux

Soyons honnêtes : j'adore les mathématiques derrière les preuves à divulgation nulle de connaissance (ZKP), mais intégrer cela dans un réseau en direct est un véritable casse-tête. C'est une chose de prouver que l'on détient un secret sur un tableau blanc, c'en est une autre de le faire pendant qu'un utilisateur tente de streamer de la vidéo 4K via un nœud décentralisé.

Le côté « Succinct » des zk-SNARKs est censé accélérer les choses, mais la génération de ces preuves consomme encore énormément de cycles CPU. Si votre smartphone doit effectuer des calculs intensifs juste pour authentifier un paquet, votre batterie va fondre et votre latence va exploser.

D'après mon expérience en analyse de paquets, chaque milliseconde compte pour le routage. En ajoutant des ZKP, vous imposez essentiellement une « taxe computationnelle » sur chaque poignée de main (handshake).

• Surcharge CPU (Overhead) : Générer une preuve est bien plus complexe que de la vérifier. La plupart des utilisateurs de dVPN utilisent des mobiles ou des routeurs bas de gamme qui ne sont pas vraiment des supercalculateurs ; le côté « prouveur » devient alors un goulot d'étranglement.
• Bugs de circuits : Si les mathématiques ne sont pas parfaites, on se retrouve avec des « circuits sous-contraints ». Des rapports de sécurité de cabinets comme Trail of Bits ont souligné qu'une immense majorité des bugs SNARK proviennent de ces failles logiques, où un attaquant pourrait potentiellement falsifier une preuve.
• Latence réseau : Les preuves interactives nécessitent des échanges incessants. Même avec les versions non interactives, la taille brute de certaines preuves peut poser problème. Par exemple, les zk-STARKs sont un autre type de ZKP qui ne nécessite pas de « configuration de confiance » (trusted setup), ce qui est plus sécurisé, mais leurs preuves sont beaucoup plus volumineuses et peuvent saturer la bande passante que vous essayez justement de préserver.

En réalité, la plupart des développeurs cherchent encore cette « zone de compromis idéale » où la sécurité est maximale sans que la connexion ne ressemble à du bas débit des années 90.

Quoi qu'il en soit, nous allons voir maintenant comment l'industrie tente concrètement de résoudre ce problème de latence pour que nous puissions enfin concilier confidentialité totale et performance.

L'avenir d'un Internet résistant à la censure

Alors, quel est l'objectif final de tout cet arsenal mathématique ? Très honnêtement, nous assistons à un changement de paradigme total où la « confidentialité dès la conception » (privacy by design) n'est plus un simple slogan marketing, mais une réalité ancrée dans le code même du réseau.

À mesure que nous progressons vers les DePIN (Réseaux d'Infrastructures Physiques Décentralisés), l'ancien modèle consistant à confier son identité à un fournisseur de VPN centralisé paraîtra aussi archaïque que les connexions bas débit. L'avenir appartient à la « divulgation sélective » : prouver exactement ce qui est nécessaire, et rien de plus.

La prochaine ère d'Internet ne sera pas définie par ceux qui collectent le plus de données, mais par ceux qui sauront s'en passer. C'est ici qu'interviennent les zkVM (machines virtuelles à divulgation nulle de connaissance). Elles nous permettent d'exécuter une logique complexe — comme vérifier si un utilisateur se trouve dans une région restreinte ou s'il possède un abonnement valide — hors chaîne (off-chain), pour n'en publier ensuite qu'une preuve minuscule.

• Passage à l'échelle de la confidentialité : Des outils comme RISC Zero ou Succinct Labs permettent désormais aux développeurs d'écrire une logique de preuve à divulgation nulle (ZKP) dans des langages standards comme Rust. Cela signifie que les dVPN peuvent monter en charge sans subir la lourde « taxe computationnelle » évoquée précédemment.
• Résistance à la censure : Lorsqu'un nœud ignore votre identité et la nature des contenus auxquels vous accédez, il devient beaucoup plus difficile pour un gouvernement de contraindre ce nœud à vous bloquer.
• Adoption par les entreprises : Comme le soulignait récemment Concordium, les entreprises commencent à percevoir les données comme une responsabilité risquée (liability). Si elles ne détiennent pas vos données, elles ne peuvent pas les perdre lors d'une faille de sécurité.

Quoi qu'il en soit, bien que cette technologie en soit encore à ses débuts, la direction est claire. Nous bâtissons un Internet où la vie privée n'est plus une option à demander, mais un paramètre par défaut au niveau du protocole. On se retrouve très vite pour une prochaine analyse technique.