BIP324: réflexions sur le chiffrement et le P2P

Contexte

La séance du Bitcoin Core PR Review Club du 25 septembre portait sur une pull request soumise dans le cadre du BIP324.

Porté par Jonas Schnelli, ce Bitcoin Improvement Proposal (BIP) vise à optimiser la couche réseau de Bitcoin Core en créant un nouveau format pour les échanges de messages entre les nœuds du réseau. Cette V2 consiste en plusieurs améliorations :

  • la refonte du format des messages afin de supprimer certaines informations peu utilisées et de produire des messages plus compacts, ce qui permet de réduire la bande-passante consommée
  • un certain nombre d’améliorations et d’optimisation dans le code lui-même, dans le sens de davantage de souplesse et d’évolutivité
  • et surtout, la possibilité de chiffrer les communications entre nœuds.

C’est de ce dernier point que je voudrais particulièrement discuter.

Pourquoi chiffrer les messages P2P ?

Bitcoin est un réseau pair-à-pair anonyme composés de nœuds qui échangent constamment des informations. C’est ainsi par exemple qu’est propagée votre transaction jusqu’à un mineur qui (peut-être) l’ajoutera dans un bloc, c’est aussi ainsi que tout le réseau est au courant quand un nouveau bloc a été miné.

Ces communications entre nœuds ont toujours été en clair (c’est-à-dire sans aucun chiffrement). Cela est cohérent avec le modèle de menace de Bitcoin, qui permet à chaque pair de valider lui-même de façon non équivoque les informations reçues. Contrairement à d’autres systèmes, l’intégrité de l’information et la fiabilité de sa source n’entrent pas en ligne de compte.

Pour le dire autrement, même si je suis connecté à 50 pairs qui essaient de me fournir des informations erronées, il suffit qu’un seul de mes pairs soit honnête pour que je puisse avoir une certitude absolue du consensus sur le reste du réseau. Bitcoin est ainsi réellement anonyme (l’identité des pairs n’a aucune importance) et sans confiance (chaque pair est autonome et ne dépend en rien des autres pour valider les données qu’on lui soumet).

Toutefois ce modèle laisse les nœuds absolument sans protection contre un certains nombres d’attaques :

  • Man-in-the-Middle (MITM) : un attaquant se fait passer pour un de mes pairs et s’interpose entre lui et moi pour soit simplement écouter toutes nos communications (attaques passives), soit les perturber activement (retarder la transmission d’un bloc, modifier un message)
  • BGP hijacking : une attaque très puissante, mais difficile à mettre en œuvre et qui ne concerne pas spécifiquement Bitcoin
  • Surveillance de masse : celle-ci est très facile et peu coûteuse pour un État ou des entités qui ont accès à une large portion du trafic internet comme les FAI. Le trafic généré par le réseau Bitcoin est en effet facilement identifiable.

La proposition de BIP324

BIP324 est une proposition plus large que BIP151, qui ne concernait que le chiffrement, et est aussi liée à BIP150, qui concerne plus spécifiquement l’authentification. Voici en résumé les points les plus importants :

  • La proposition parle de chiffrement opportuniste (“opportunistic encryption“), ce qui implique que le chiffrement n’est pas obligatoire (il est toujours possible de communiquer en clair si besoin) et l’authentification n’est pas nécessaire
  • Dans le cas d’une communication chiffrée, il devient possible de détecter un MITM (le pair n’est pas celui qu’il prétend être), ce qui est totalement impossible dans le modèle actuel
  • Le chiffrement et l’authentification utiliserait les algorithmes chacha20-Poly1305, et Diffie-Hellman pour les échanges de clés, et se débarrasse du checksum généré par un double SHA256, méthode de contrôle d’intégrité coûteuse et peu efficace.

Telle que présentée par Jonas Schnelli dans le BIP, cette proposition présenterait les avantages suivants :

  • Rendre la surveillance de masse du réseau plus difficile et plus coûteuse
  • Offrir une possibilité d’identifier une attaque MITM en cours. La détection nécessite que les deux pairs attaqués disposent d’un canal de communication sûr et distinct (safe side-channel) pour pouvoir comparer les identifiants et démasquer le MITM, ce qui sera peu aisé en pratique. Néanmoins l’attaquant ne peut pas non plus savoir s’il a été démasqué. La simple possibilité de l’être rend en fait cette attaque bien moins attractive
  • Faciliter le chiffrement pour les utilisateurs qui autrement ne sauraient pas utiliser un VPN ou Tor.

BIP324 semble donc être un no-brainer : qui ne voudrait pas d’une cryptographie plus facilement accessible pour tous les utilisateurs de Bitcoin ? La proposition sous sa forme actuelle emporte en effet un large consensus parmi les développeurs de Bitcoin Core, mais elle a également été critiquée par Eric Voskuil, développeur d’une bibliothèque Bitcoin en C++, libbitcoin.

Critiques de la proposition

Ces critiques ont été formulé à différentes occasions et ont donné lieu à des échanges avec Jonas Schnelli. Même si très minoritaire, le point de vue d’Eric me semble intéressant ne serait-ce que comme occasion de penser la question de façon conflictuelle, ce qui est vital à la survie d’un projet comme Bitcoin.

Eric prétend que cette proposition ne mitige en rien les attaques dans le cas où les pairs sont réellement anonymes. Comme nous l’avons vu, détecter un MITM nécessite en effet que les pairs ne soient pas (complètement) anonymes, se fassent confiance (dans une certaine mesure) et disposent d’un canal de communication sûr. Ces assomptions vont à l’encontre des fondamentaux de Bitcoin comme réseau anonyme et sans confiance.

Cela nous amène au cœur de son argument. Pour offrir une réelle protection, le chiffrement doit donc permettre l’authentification des pairs. Or Bitcoin est construit comme un réseau anonyme, car toutes les informations sont validées indépendamment par chaque pair avec les règles du consensus. Bitcoin doit pouvoir fonctionner dans un environnement adverse, sans que l’on puisse identifier certains pairs comme plus “sûr” que d’autres.

Pour Eric, le chiffrement proposé dans BIP324 ne répond donc à aucun problème réel pour les nœuds anonymes d’un réseau P2P, mais bien plutôt à la problématique particulière des clients légers (wallet sur téléphone par exemple) qui sont effectivement très vulnérables car ils ne font aucune vérification et ont donc besoin de faire confiance à leur source d’informations et de l’authentifier. Cette problématique ne concerne donc pas les pairs, et ne devrait donc pas être traitée au niveau du protocole.

En un mot : soit l’authentification n’est pas possible entre pairs de par le modèle de l’anonymat, mais alors le chiffrement n’a que peu d’avantages par rapport à la situation actuelle, soit l’authentification (la confiance ?) devient partie intégrante des interactions entre les pairs, mais Bitcoin fait alors un pas qui l’éloigne du réseau totalement anonyme et sans confiance qu’il est aujourd’hui.

Que tirer de tout ça ?

Ne serait-ce que pour l’optimisation des échanges et la flexibilité pour faire évoluer le protocole, BIP324 représente une avancée importante pour la couche réseau de Bitcoin. Toutefois les contradictions soulevées par Eric spécifiquement sur la partie chiffrement de la proposition me semblent loin d’être infondées.

Voici ma synthèse des arguments pour et contre :

  • S’il s’agit réellement de chiffrement opportuniste, cela aura un impact réel sur les attaques passives (simple écoute / surveillance). Un attaquant qui souhaite surveiller en masse le réseau devra entretenir plusieurs nœuds bien connectés, ce qui sera en effet plus compliqué et plus coûteux qu’aujourd’hui, mais est loin d’être insurmontable.
  • L’impact sur l’analyse de chaîne est nul.
  • Un attaquant actif peut être détecté, ce qui est une amélioration indéniable, même si limité en pratique.
  • Le gain de sécurité et de confidentialité ne sera pleinement réalisé que si l’authentification est possible, et les principaux bénéficiaires seront les clients légers.
  • La possibilité d’authentifier ses pairs a certains avantages, mais représente également un risque à long terme.

Le cœur de la critique d’Eric est que si l’authentification des nœuds devaient se généraliser, cela serait un pas vers un réseau autorisé et non-anonyme. Dans le pire des scénarios, les opérateurs de nœud n’accepteraient comme pair que des nœuds de confiance qu’ils peuvent authentifier (i.e. auxquels ils pensent pouvoir faire confiance), et les pairs anonymes seraient refusés ou à tout le moins tenus en suspicion par défaut.

Pouvoir chiffrer le trafic P2P de son nœud est indéniablement une bonne chose, voire absolument vital dans certaines situations, néanmoins on peut se demander si cette mission n’est pas mieux assurée par des logiciels tiers (Tor, VPN…) comme c’est déjà le cas aujourd’hui, plutôt que directement par le protocole.

Conclusion personnelle

J’ai encore besoin de réfléchir et surtout d’échanger pour me faire un avis définitif sur la question, mais je pense que la proposition actuelle pourrait être précisée. Il semble que le chiffrement opportuniste n’a pas vraiment d’utilité sur un réseau comme Bitcoin, et que l’authentification ne peut se généraliser que dans les cas particuliers où le nœud est dans une relation client/serveur, typiquement avec un client léger.

Peut-être qu’un compromis acceptable serait que :

  • les communications entre pairs anonymes restent en clair
  • il n’y ait pas de chiffrement sans authentification (pas de chiffrement opportuniste)

Ainsi le modèle P2P de Bitcoin resterait inchangé, mais les utilisateurs qui souhaitent établir des connexions spéciales avec des pairs et/ou des clients qui seraient traités différemment auraient une option simple à utiliser intégrée directement dans le protocole.

Références :

Leave a Reply

Your email address will not be published.Required fields are marked *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.