116 / 691SYBIL

Sybil attack

Une attaque Sybil permet à un adversaire de présenter de nombreuses identités réseau. Bitcoin sépare le nombre de pairs du poids de consensus et lie la production de blocs à Proof of Work.

La résistance Sybil n’interdit pas les faux pairs. Multiplier les identités ne crée ni signatures de clés d’autrui, ni pièces valides, ni travail ; cela peut toutefois soutenir des attaques de routage, d’isolement eclipse et de surveillance.

John Douceur a décrit l’attaque Sybil en 2002 : une entité se fait passer pour plusieurs participants indépendants. Les pseudonymes sont faciles à créer, mais obtenir des adresses ou connexions adaptées peut coûter des ressources. [John R. Douceur — The Sybil Attack]

Bitcoin n’a pas de registre mondial prouvant qu’un nœud correspond à une personne. Une autre adresse IP ne prouve pas non plus, à elle seule, un opérateur indépendant. [John R. Douceur — The Sybil Attack] [Bitcoin Developer Guide — P2P Network]

Un Full Node vérifie les règles de consensus indépendamment. Une majorité de pairs connectés ne peut rendre valide une transaction invalide par vote. [Satoshi Nakamoto — Bitcoin whitepaper] [The Bitcoin Backbone Protocol]

Proof of Work lie le poids du choix d’une chaîne valide au travail cumulé. Annoncer davantage d’identités n’augmente pas à lui seul la puissance de hachage ou le travail de la chaîne. [Satoshi Nakamoto — Bitcoin whitepaper] [The Bitcoin Backbone Protocol]

Multiplier les identités ne permet pas de falsifier la signature d’autrui, créer des pièces hors des règles d’émission ou imposer un bloc invalide. Vérifier ces règles reste la tâche du Full Node. [Satoshi Nakamoto — Bitcoin whitepaper] [The Bitcoin Backbone Protocol]

Les pairs contrôlés peuvent concurrencer les autres pour les places dans les tables d’adresses et les connexions de la victime. S’ils aident à capturer ses connexions pertinentes, une attaque eclipse peut en résulter ; de nombreuses identités seules ne prouvent pas l’isolement complet. [Bitcoin Developer Guide — P2P Network] [Heilman et al. — Eclipse Attacks on Bitcoin]

La diversité des connexions sortantes, le regroupement des adresses et les connexions d’essai feeler de Bitcoin Core limitent la concentration. Ce sont des défenses, pas une preuve d’indépendance de chaque pair ni une garantie contre l’isolement. [Bitcoin Core v29.0 — Peer connections] [Heilman et al. — Eclipse Attacks on Bitcoin]

Les adresses IP et de services Tor servent à acheminer le trafic, pas de titres de participation au consensus. Plusieurs adresses peuvent appartenir à un opérateur et plusieurs utilisateurs partager un chemin réseau. [Bitcoin Developer Guide — P2P Network] [Bitcoin Core v29.0 — Peer connections]

Proof of Work limite l’abus d’identités dans le choix de l’historique, mais ne résout pas tous les abus P2P. L’inondation, la surveillance et la manipulation de la disponibilité des messages nécessitent un modèle de menace distinct. [John R. Douceur — The Sybil Attack] [Heilman et al. — Eclipse Attacks on Bitcoin] [The Bitcoin Backbone Protocol]

Un compteur public de nœuds joignables ne compte ni personnes ni voix sur les règles. La sécurité s’évalue par les ressources adverses, les relations réseau et la validation indépendante, pas par le seul nombre d’identités. [John R. Douceur — The Sybil Attack] [Bitcoin Developer Guide — P2P Network] [The Bitcoin Backbone Protocol]

Pour une vision complète, lisez aussi Nakamoto consensus, Eclipse attack, Selfish mining, Block propagation. Cette entrée est également citée par Byzantine Generals Problem, Eclipse attack.

DOC · 001John R. Douceur — The Sybil AttackSource primaire ↗DOC · 002Satoshi Nakamoto — Bitcoin whitepaperSource primaire ↗DOC · 003Bitcoin Developer Guide — P2P NetworkDocumentation ↗DOC · 004Bitcoin Core v29.0 — Peer connectionsDocumentation ↗DOC · 005Heilman et al. — Eclipse Attacks on BitcoinSource primaire ↗DOC · 006The Bitcoin Backbone ProtocolSource primaire ↗
Sources d’abord · Pas un conseil financier