Attaque par éclipse

Principe

L'attaque par éclipse vise à isoler un nœud Bitcoin du reste du réseau pair-à-pair. Plutôt que d'attaquer le protocole, l'attaquant manipule la vision qu'a la victime du réseau : il l'« éclipse » du vrai Bitcoin et la connecte uniquement à des nœuds qu'il contrôle. À partir de là, l'attaquant peut lui montrer une fausse chaîne, retarder ses transactions, censurer ses paiements, ou la convaincre d'une double-dépense fictive.

Comment l'attaque se déroule

Bitcoin Core maintient par défaut 8 connexions sortantes (l'attaquant ne contrôle pas leur choix) et accepte jusqu'à 117 connexions entrantes (l'attaquant peut les saturer s'il le souhaite). Une attaque par éclipse opportuniste exploite plusieurs vecteurs :

1. Saturer la table d'adresses : l'attaquant inonde le nœud d'adresses IP qu'il contrôle via les messages addr, qui finissent par remplir la table addrman du nœud.
2. Attendre un redémarrage : au prochain démarrage, le nœud tirera ses 8 peers sortants parmi cette table polluée.
3. Occuper toutes les connexions entrantes : multiplier les connexions depuis les IP attaquantes.
4. Isolement complet : 100 % des pairs sont contrôlés.

La recherche de 2015 par Heilman, Kendler, Zohar et Goldberg a démontré qu'avec 4 600 IP et 6 jours de patience, on peut éclipser un nœud Bitcoin Core 0.10. Bitcoin Core a depuis renforcé l'algorithme addrman et durci la sélection des peers.

Conséquences possibles

| Cible | Impact | |---|---| | Marchand acceptant 0-conf | Double-dépense facile | | Mineur isolé | Gaspille du hashrate sur fork | | Wallet SPV | Peut être trompé par fausse Merkle proof | | Nœud Lightning | Force-close manipulé | | Validateur de retrait BTC sur sidechain | Validation frauduleuse |

Mitigations natives dans Bitcoin Core

Bitcoin Core a accumulé depuis 2015 plusieurs défenses :

| Mitigation | Effet | |---|---| | Tables tried et new séparées | Limite la pollution d'addrman | | Outbound peers garantis depuis 2 sources distinctes | Diversité forcée | | Anchor connections | 2 peers persistants entre redémarrages | | ASMAP | Limite à un par autonomous system | | Block-relay-only peers | Connexions « bloc seul » diversifiées | | Diversification IPv6/IPv4/Tor/I2P | Pluralité des couches |

Attaques dérivées

• Erebus : éclipse par contrôle de la topologie BGP en amont, beaucoup plus puissante.
• Sybil : générer beaucoup d'identités fausses, brique de base d'une éclipse.
• Time bandit : combinée à un mineur isolé, manipulation des timestamps.

Conseils pratiques

• Faire tourner son nœud sur réseau diversifié (clearnet + Tor + I2P).
• Activer addnode= pour quelques pairs de confiance.
• Activer asmap (fichier disponible sur GitHub Bitcoin Core).
• Toujours valider les confirmations avec un autre nœud avant d'accepter de gros paiements.

À retenir

L'attaque par éclipse ne casse pas la cryptographie ni le consensus, mais détourne la vision du réseau. C'est l'une des classes d'attaques les plus subtiles, surtout dangereuse pour les nœuds isolés (offshore wallets, mineurs solo). La défense est avant tout topologique. Voir Erebus et ASMAP.