117 / 736ECL

Eclipse Attack

Le nœud est connecté, mais l’attaquant lui cache le reste du réseau

Internet fonctionne, les connexions sont ouvertes, et pourtant le nœud ne voit pas ce qui se passe réellement dans Bitcoin. Lors d’une Eclipse Attack, l’adversaire contrôle ses chemins vers les autres et choisit les messages qui arrivent.

Une Eclipse Attack isole un nœud de ses pairs honnêtes tout en maintenant sa connexion à l’attaquant. Le Full Node, un logiciel qui vérifie lui-même les règles de Bitcoin, poursuit cette vérification, mais peut ne recevoir qu’une vision incomplète ou périmée du réseau. L’attaque ne rend pas valides des données invalides : elle exploite ce que le nœud ne peut pas voir.

Anne reçoit un paiement en bitcoin et surveille son propre nœud : un ordinateur équipé d’un logiciel qui participe au réseau Bitcoin. Celui-ci affiche des connexions actives, mais un adversaire contrôle toutes les voies importantes vers l’extérieur. Des messages arrivent, mais seulement ceux qu’il autorise. C’est le principe d’une Eclipse Attack. Une seule connexion malveillante ne suffit généralement pas : un chemin fonctionnel vers un nœud honnête peut apporter les blocs cachés et briser ce contrôle. Un bloc regroupe des transactions en un lot ajouté à l’historique commun. [1] [6]

Ethan Heilman, Alison Kendler, Aviv Zohar et Sharon Goldberg ont décrit en 2015 des attaques contre le réseau Bitcoin de l’époque. Ils ont étudié comment remplir les tables d’un nœud avec des adresses contrôlées par l’attaquant pour qu’à sa reconnexion, il ne contacte que les ordinateurs de celui-ci. Ils ont exploité le choix des connexions sans casser les mécanismes mathématiques qui protègent notamment les signatures numériques. L’étude proposait aussi des défenses ; ses résultats historiques ne mesurent pas les chances de succès contre la version actuelle de Bitcoin Core. [1] [7]

Une fois l’isolement obtenu, il peut choisir les blocs et transactions qu’il transmet à Anne ou retient. Il peut également empêcher la diffusion des transactions qu’elle émet ou en observer l’origine. Contrôler les connexions ne nécessite pas en soi une majorité de la puissance de minage. Cela ne rend pas toutes les attaques suivantes gratuites : produire de nouveaux blocs exige, par exemple, un travail réel. [1] [6]

Le Full Node d’Anne vérifie toujours les signatures, les conditions de dépense et la récompense autorisée du mineur. Signer signifie ici utiliser une clé privée, une valeur numérique secrète, pour créer une preuve vérifiable de l’autorisation du paiement. Les autres peuvent vérifier la signature sans connaître ce secret. Le nœud d’Anne n’accepte pas une transaction invalide parce qu’elle vient de la seule source disponible. Mais cette vérification ne révèle pas un bloc valide qui n’est jamais arrivé. On peut de même reconnaître une lettre authentique sans savoir que quelqu’un retient toutes les lettres plus récentes. Validité et exhaustivité de l’information disponible sont deux questions distinctes. [5] [9]

Le nœud peut rester au dernier bloc connu pendant que les autres progressent. Un mineur isolé peut même continuer sur une branche abandonnée et perdre la récompense espérée. Une longue attente ne prouve toutefois pas une attaque : le minage est aléatoire et une panne ordinaire peut aussi expliquer le retard. C’est la combinaison d’indices qui compte, pas simplement un affichage qui se rafraîchit lentement. [1] [5] [8]

L’attaquant peut montrer à Anne une branche privée valide contenant son paiement, tout en dépensant les mêmes fonds autrement sur le réseau général. Une fois la connexion rétablie, son nœud peut adopter une branche valide ayant davantage de travail cumulé : un Reorg, c’est-à-dire le remplacement d’une partie de l’historique accepté. Le paiement de la branche abandonnée peut perdre sa confirmation. L’attaquant doit néanmoins fournir Proof of Work pour ses blocs. Il s’agit du résultat vérifiable d’une recherche coûteuse en calculs, exigé aussi pour ces blocs. Ce travail peut également provenir de mineurs que l’attaquant a isolés. Un nombre de confirmations inventé ne trompe pas un Full Node ; le succès dépend aussi de la durée d’isolement et de ses ressources. [1] [5] [6]

Les défenses cherchent à éviter que toutes les connexions aboutissent au même adversaire. Bitcoin Core regroupe les adresses connues et favorise la diversité des réseaux pour les connexions sortantes. Une adresse IP désigne un emplacement sur le réseau auquel le programme se connecte. Des IP différentes peuvent pourtant appartenir au même exploitant ou emprunter la même infrastructure. Ces mesures réduisent la concentration et compliquent l’attaque sans prouver l’indépendance de chaque pair. [3] [4]

Bitcoin Core emploie de brèves connexions feeler pour vérifier si une autre adresse est joignable. Les connexions supplémentaires de relais de blocs ont un autre rôle : elles peuvent fournir de nouveaux en-têtes — de courts relevés techniques des blocs — et une autre vue de la suite de la chaîne. Il serait donc inexact de dire que chaque feeler télécharge immédiatement l’historique à jour. Le code cité de Bitcoin Core 29.0 montre ces défenses distinctes ; aucune ne garantit à elle seule la fin de l’isolement. [4] [8]

Un pair connu ajouté manuellement peut ouvrir un autre chemin s’il est disponible et réellement relié au reste du réseau. Plusieurs connexions passant par le même fournisseur ne sont toutefois pas nécessairement indépendantes. Mieux vaut utiliser un logiciel toujours maintenu et comprendre ses réglages que reprendre aveuglément une liste d’adresses tierce. La vérification personnelle demeure : faire confiance à la disponibilité d’une source ne l’autorise pas à envoyer des blocs invalides. [2] [4] [6]

Une Sybil Attack fait intervenir un adversaire sous de nombreuses identités, ce qui peut faciliter une Eclipse Attack. Eclipse désigne l’isolement réussi d’un nœud précis ou d’un groupe choisi de ses sources honnêtes. Une partition plus large sépare des régions entières du réseau et ne provient pas forcément de cette méthode. Pour l’utilisateur, l’essentiel est qu’un Full Node permet une vérification autonome, mais a aussi besoin d’informations échappant au contrôle de l’attaquant. [1] [6]

Pour une vision complète, lisez aussi Sybil Attack, Block Propagation, Compact Blocks, Nakamoto Consensus, Bitcoin, Full Node. Cette entrée est également citée par Double dépense, Byzantine Generals Problem, Nakamoto Consensus, Sybil Attack.

DOC · 001Heilman et al. — Eclipse Attacks on BitcoinSource primaire DOC · 002Bitcoin Developer Guide — P2P NetworkDocumentation DOC · 003Bitcoin Core v29.0 — addrmanDocumentation DOC · 004Bitcoin Core v29.0 — Peer connectionsDocumentation DOC · 005Bitcoin Developer Guide — Block ChainDocumentation DOC · 006Bitcoin Optech — Eclipse attacksDocumentation DOC · 007USENIX Security 2015 — Eclipse Attacks on Bitcoin’s Peer-to-Peer NetworkSource primaire DOC · 008Bitcoin Core v29.0 — Message processingDocumentation DOC · 009Bitcoin Core v29.0 — Block validationDocumentation
Révisé le: Sources d’abord · Pas un conseil financier