117 / 736ECL

Eclipse Attack

Der Knoten ist verbunden, doch der Angreifer verdeckt das übrige Netzwerk

Das Internet funktioniert, Verbindungen sind offen, und trotzdem sieht ein Knoten nicht, was in Bitcoin tatsächlich geschieht. Bei einer Eclipse Attack kontrolliert ein Angreifer seine Wege nach außen und entscheidet, welche Nachrichten ankommen.

Eine Eclipse Attack isoliert einen Knoten gezielt von ehrlichen Gegenstellen, während die Verbindung zum Angreifer bestehen bleibt. Ein Full Node ist ein Programm, das die Bitcoin-Regeln selbst prüft. Diese Prüfung läuft weiter, doch der Knoten erhält womöglich nur ein unvollständiges oder veraltetes Bild. Der Angriff macht ungültige Daten nicht gültig, sondern nutzt aus, was der Knoten nicht sehen kann.

Anna nimmt eine Bitcoin-Zahlung an und beobachtet ihren eigenen Knoten: einen Computer mit einem Programm, das am Bitcoin-Netzwerk teilnimmt. Er meldet aktive Verbindungen, doch alle wichtigen Wege nach außen kontrolliert ein Angreifer. Nachrichten kommen an, aber nur solche, die der Angreifer durchlässt. Das ist der Kern einer Eclipse Attack. Eine einzige bösartige Verbindung reicht normalerweise nicht: Ein funktionierender Weg zu einem ehrlichen Knoten kann zurückgehaltene Blöcke liefern und die Kontrolle durchbrechen. Ein Block bündelt Transaktionen, die in die gemeinsame Historie aufgenommen werden. [1] [6]

Ethan Heilman, Alison Kendler, Aviv Zohar und Sharon Goldberg beschrieben 2015 Angriffe auf das damalige Bitcoin-Netzwerk. Sie untersuchten, wie sich die Adresstabellen eines Knotens mit Angreiferadressen füllen lassen, damit er sich nach dem erneuten Verbindungsaufbau nur mit Rechnern des Angreifers verbindet. Sie nutzten die Auswahl der Verbindungen aus, ohne die mathematischen Verfahren etwa hinter digitalen Signaturen zu brechen. Die Studie schlug auch Gegenmaßnahmen vor. Ihre historischen Ergebnisse messen nicht die Erfolgschance gegen die heutige Version von Bitcoin Core. [1] [7]

Nach erfolgreicher Isolation kann der Angreifer auswählen, welche Blöcke und Transaktionen Anna erreichen und welche er zurückhält. Er kann auch die Verbreitung ihrer eigenen Transaktionen verhindern oder deren Ursprung beobachten. Allein die Übernahme der Verbindungen erfordert keine Mehrheit der Mining-Leistung. Das bedeutet aber nicht, dass jeder Folgeangriff ohne weiteren Aufwand gelingt: Neue Blöcke zu erzeugen erfordert beispielsweise echte Arbeit. [1] [6]

Annas Full Node prüft weiterhin Signaturen, Ausgabebedingungen und die zulässige Miner-Belohnung. Unterschreiben bedeutet hier, mit einem privaten Schlüssel, einem geheimen Zahlenwert, einen überprüfbaren Nachweis für die Berechtigung zur Zahlung zu erzeugen. Andere können die Signatur prüfen, ohne diesen geheimen Wert zu kennen. Eine fehlerhafte Transaktion akzeptiert Annas Knoten nicht deshalb, weil sie von der einzigen erreichbaren Quelle stammt. Die Prüfung kann aber keinen gültigen Block entdecken, der nie ankam. Ebenso lässt sich die Echtheit eines zugestellten Briefs feststellen, ohne zu wissen, dass jemand alle neueren Briefe zurückhält. Gültigkeit und Vollständigkeit verfügbarer Informationen sind getrennte Fragen. [5] [9]

Der Knoten kann beim letzten bekannten Block stehen bleiben, während andere fortfahren. Ein isolierter Miner arbeitet womöglich auf einem aufgegebenen Zweig weiter und verliert die erwartete Belohnung. Langes Warten auf einen Block beweist jedoch noch keinen Angriff: Mining ist zufallsabhängig, und auch ein gewöhnlicher Ausfall verursacht Probleme. Entscheidend ist das Zusammenspiel mehrerer Anzeichen, nicht allein eine langsam aktualisierte Anzeige. [1] [5] [8]

Ein Angreifer kann Anna einen gültigen privaten Zweig mit ihrer Zahlung zeigen, während er dieselben Mittel im übrigen Netzwerk anders ausgibt. Nach Wiederherstellung der Verbindung kann ihr Knoten auf einen gültigen Zweig mit mehr angesammelter Arbeit wechseln. Das ist ein Reorg, also der Austausch eines Teils der akzeptierten Historie. Die Zahlung im aufgegebenen Zweig kann ihre Bestätigung verlieren. Der Angreifer muss für seine Blöcke aber Proof of Work liefern. Das ist ein überprüfbares Ergebnis einer rechenaufwendigen Suche, das auch diese Blöcke vorweisen müssen. Die nötige Arbeit können auch Miner liefern, die der Angreifer isoliert hat. Eine erfundene Bestätigungszahl täuscht keinen Full Node; der Erfolg hängt auch von Isolationsdauer und Ressourcen ab. [1] [5] [6]

Die Abwehr soll verhindern, dass sämtliche Verbindungen beim selben Gegner enden. Bitcoin Core gruppiert bekannte Adressen und fördert bei ausgehenden Verbindungen die Netzwerkvielfalt. Eine IP-Adresse bezeichnet ein Ziel im Netzwerk, zu dem das Programm eine Verbindung aufbaut. Unterschiedliche IP-Adressen können dennoch einem Betreiber gehören oder dieselbe Infrastruktur nutzen. Diese Maßnahmen verringern die Konzentration und erschweren den Angriff, beweisen aber nicht die Unabhängigkeit jeder Gegenstelle. [3] [4]

Bitcoin Core prüft mit kurzen feeler-Verbindungen, ob eine weitere Adresse erreichbar ist. Zusätzliche Verbindungen zur Blockweiterleitung haben eine andere Aufgabe: Sie können neue Blockheader — kompakte technische Datensätze der Blöcke — und einen weiteren Blick auf die Fortsetzung der Kette liefern. Nicht jeder feeler lädt also sofort die aktuelle Historie herunter. Der verlinkte Code von Bitcoin Core 29.0 zeigt diese unterschiedlichen Schutzmechanismen. Keiner garantiert allein ein Ende der Isolation. [4] [8]

Eine manuell hinzugefügte bekannte Gegenstelle kann einen weiteren Weg eröffnen, wenn sie erreichbar und tatsächlich mit dem übrigen Netzwerk verbunden ist. Mehrere Verbindungen über einen Anbieter müssen aber nicht unabhängig sein. Sinnvoll ist es, weiterhin gepflegte Software zu verwenden und die Verbindungseinstellungen zu verstehen, statt fremde Adresslisten ungeprüft zu übernehmen. Die eigene Prüfung bleibt erhalten: Vertrauen in die Erreichbarkeit einer Quelle berechtigt diese nicht, ungültige Blöcke zu schicken. [2] [4] [6]

Bei einer Sybil Attack tritt ein Gegner unter vielen Identitäten auf; das kann eine Eclipse Attack erleichtern. Eclipse bezeichnet die erfolgreiche Isolation eines bestimmten Knotens oder einer ausgewählten Gruppe von ehrlichen Quellen. Eine umfassendere Netzwerkteilung trennt dagegen ganze Netzbereiche und muss nicht auf diese Weise entstehen. Für gewöhnliche Nutzer zählt: Ein Full Node ermöglicht unabhängige Prüfung, benötigt aber auch Informationen außerhalb der Kontrolle des Angreifers. [1] [6]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Sybil Attack, Block Propagation, Compact Blocks, Nakamoto Consensus, Bitcoin, Full Node. Auf diesen Eintrag verweisen außerdem Double Spend, Byzantine Generals Problem, Nakamoto Consensus, Sybil Attack.

DOC · 001Heilman et al. — Eclipse Attacks on BitcoinPrimärquelle DOC · 002Bitcoin Developer Guide — P2P NetworkDokumentation DOC · 003Bitcoin Core v29.0 — addrmanDokumentation DOC · 004Bitcoin Core v29.0 — Peer connectionsDokumentation DOC · 005Bitcoin Developer Guide — Block ChainDokumentation DOC · 006Bitcoin Optech — Eclipse attacksDokumentation DOC · 007USENIX Security 2015 — Eclipse Attacks on Bitcoin’s Peer-to-Peer NetworkPrimärquelle DOC · 008Bitcoin Core v29.0 — Message processingDokumentation DOC · 009Bitcoin Core v29.0 — Block validationDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung