Eines der Grundprinzipien des Bitcoin-Netzwerks ist Transparenz: Sämtliche Daten, seien es ganze Blöcke oder einzelne Transaktionen sind öffentlich und mit nur wenig Aufwand einsehbar. Bitcoin ist außerdem ein dezentrales Netzwerk, das auf einem sogenannten Peer-to-Peer-Protokoll aufbaut, also vielen gleichberechtigten Teilnehmern (Nodes), die untereinander laufend Transaktionen, Blöcke und sonstige Protokollnachrichten austauschen. Während sogar der Inhalt dieses Artikels verschlüsselt zu deinem Rechner oder Smartphone übertragen wurde, läuft diese Kommunikation im P2P-Protokoll von Bitcoin bislang grundsätzlich unverschlüsselt und ohne Authentifizierung ab.
Das ist auch kein großes Problem, denn die übertragenen Daten sind schließlich ohnehin nicht geheim und müssen vor niemandem geschützt werden – oder etwa doch? An dieser Stelle müssen wir den Fokus von Bitcoin im Allgemeinen etwas abwenden und uns alleine auf das P2P-Protokoll konzentrieren. Denn es gibt ein paar theoretische Schwachstellen, die mit den Eigenschaften der aktuellen Protokollversion einhergehen, die wir uns gleich etwas näher anschauen werden. Das vom Bitcoin-Entwickler Jonas Schnelli ins Leben gerufene BIP-324 (Bitcoin Improvement Proposal) schlägt deshalb eine neue, überarbeitete Version des P2P-Protokolls vor und will eine Verschlüsselung für sämtliche Protokollnachrichten einführen, um eben diese Schwachstellen abzuschwächen.
Lese-Tipp: Stratum V2: Wie Bitcoin-Mining effizienter und unabhängiger wird!
Der Status Quo
Bitcoin-Transaktionen und Blöcke müssen und werden auch immer öffentlich bleiben. Daran wird natürlich auch die zweite Version des P2P-Protokolls nichts ändern. Doch es gibt keinen Grund, warum individuelle Nachrichten zwischen zwei Teilnehmern im Bitcoin-Netzwerk in Klartext lesbar und identifizierbar sein sollten. Im Gegenteil, denn schließlich können diese Nachrichten recht einfach mitgelesen werden. So können z.B. Internetanbieter, Beitreiber eines öffentlichen WLAN-Netzwerkes oder sonstige unerwünschte Gäste diverse Rückschlüsse ziehen, darunter beispielsweise:
- Es ist nachvollziehbar, z.B. für einen Internetanbieter, dass jemand überhaupt eine Bitcoin-Node betreibt.
- Transaktionen können theoretisch auf ihre ursprüngliche Quelle zurückgeführt werden, sofern Protokollnachrichten großflächig beobachtet werden, was ein Risiko für die Privatsphäre einzelner Nutzer darstellen kann.
- Nachrichten können durch einen Man-In-The-Middle-Angriff (MITM) abgefangen und blockiert werden. Einzelne Transaktionen zu blockieren ist zwar nicht wirklich nachhaltig effektiv, für Bitcoin-Miner, die gerade einen gültigen Block gefunden haben, ist es allerdings fatal, wenn die Veröffentlichung von diesem auch nur wenige Sekunden verzögert wird.
- Unabhängig davon, ob nun irgendein manipulativer Angriff durchgeführt wird oder nicht, haben Bitcoin-Nodes gar keine eindeutige Möglichkeit, diesen überhaupt zu erkennen. Nachrichten sind nicht nur unverschlüsselt, sondern werden außerdem nicht auf ihre Integrität, also ihre Unversehrtheit, geprüft.
Sicherlich könnte man diese Liste mit einigen weiteren theoretischen Angriffsvektoren fortführen. Es soll an dieser Stelle aber nicht darum gehen, die aktuelle Protokollversion schlecht zu reden. Die angesprochenen Schwachstellen sind wie erwähnt recht theoretisch und würden bei erfolgreicher Ausnutzung nicht Bitcoin als Ganzes, sondern "nur" einzelne Teilnehmer bedrohen. Doch Verbesserungspotenzial ist definitiv geboten!
Was ist mit Tor?
Bevor wir uns nun endlich mit BIP-324 befassen, müssen wir noch kurz über das Tor-Netzwerk sprechen. Für viele Betreiber einer Bitcoin-Node, vor allem für die klassische "Wohnzimmer-Node", ist die Nutzung von Tor ein beliebtes Mittel, um die oben angesprochenen Schwachstellen zu adressieren. Das ist auch völlig legitim! Denn die auf Protokollebene von Bitcoin fehlende Transportverschlüsselung wird mehr oder weniger von Tor übernommen, womit ein ähnlicher Effekt, wie wir ihn gleich bei BIP-324 sehen werden, erzielt werden kann.
Doch die Nutzung von Tor ist für Bitcoin-Nodes leider nicht die ideale, universelle Lösung. Von grundsätzlich mit Tor einhergehenden Verzögerungen eimal abgesehen, die z.B. für Bitcoin-Miner ein Ausschlusskriterium sind, gibt es einige weitere Unsicherheiten. Neben bereits bekannten theoretischen Angriffsvektoren ist die Integration von Tor für Protokolle abgesehen von HTTP nicht ausreichend untersucht.
Viel besser und eleganter wäre es, direkt beim P2P-Protokoll von Bitcoin anzusetzen!
Die neue Version
Im BIP-324 wird die Einführung einer optimistischen Transportverschlüsselung sämtlicher Nachrichten im P2P-Protokoll von Bitcoin vorgeschlagen. Mit "optimistisch" ist hier gemeint, dass die Verschlüsselung nicht zwingend notwendig ist, sondern nur angestrebt wird. Sollte die andere Node veraltete Software nutzen oder einfach keine Lust auf Verschlüsselung haben, lässt man es einfach bleiben. Man will sich schließlich nicht von bestimmten Teilnehmern im Bitcoin-Netzwerk unnötigerweise abschotten.
Die konkrete technische Umsetzung würde natürlich den Rahmen dieses Beitrags sprengen. Grob zusammengefasst wird auf ein bewährtes und standardisiertes Verschlüsselungsverfahren gesetzt, das zusammen mit einem weiteren Verfahren zur Integritätssicherung kombiniert wird (ChaCha20Poly1305). Somit sind Nachrichten nicht nur davor geschützt, einfach so mitgelesen zu werden, sondern direkte Manipulation der übertragenen Daten würde außerdem beim Empfänger, also der anderen Bitcoin-Node, sofort auffallen. Darüber hinaus werden einige Maßnahmen ergriffen, um die Protokollnachrichten an sich unauffälliger aussehen zu lassen, z.B. was ihre Länge oder sich wiederholende Muster angeht.
Doch was bringt uns dieses technische Bla-Bla denn nun konkret? Zunächst sollte man sich klarmachen, dass die zu Beginn vorgestellten Schwachstellen eigentlich nie "absolut" eliminiert, sondern lediglich erschwert werden können. Und genau das ist auch der Fall.
- Für einen erfolgreichen MITM-Angriff muss ein Angreifer jetzt selbst aktiv werden und kann nicht mehr "einfach nur zuhören". Ein solcher Angriff wird ab einer bestimmten Größenordnung zunehmend kostspielig und damit unwahrscheinlich.
- Die Privatsphäre des Betreibers einer Node wird verbessert, da z.B. für einen Internetanbieter nicht mehr so einfach ersichtlich ist, dass es sich bei den übertragenen Daten um Bitcoin-spezifische Nachrichten handelt.
- Direkte Manipulation von Nachrichten wird durch den Integritätsschutz verhindert, während sie im Kontext eines MITM-Angriffes deutlich kostspieliger wird.
- Das Blockieren von Nachrichten (z.B. bei einem gefundenen Block eines Miners) ist zwar theoretisch immer noch möglich, allerdings muss man dafür erst einmal wissen, welche Daten überhaupt blockiert werden müssen – diese sind schließlich verschlüsselt und erscheinen nach außen beliebig, also "pseudozufällig".
Fazit
Wie die Autoren von BIP-324 selbst schreiben, ist die vorgeschlagene Verschlüsselung von Protokollnachrichten grundsätzlich besser, als überhaupt keine Verschlüsselung zu nutzen und bringt eigentlich keine nennenswerten Nachteile mit sich. Da es sich außerdem um eine Änderung auf Protokollebene handelt und die Konsensregeln von Bitcoin nicht angerührt werden, ist keine Hard- oder Soft-Fork für dieses Upgrade notwendig. Kombiniert mit der Abwärtskompatibilität zu Nodes, die noch die alte Protokollversion nutzen, gibt es also auch unter diesem Aspekt nichts, vor dem man sich fürchten müsste. Die Autoren lassen zudem viel Spielraum für zukünftige Protokollupdates, beispielsweise die Möglichkeit, authentifizierte Verbindungen aufzubauen, sodass man die Identität bestimmter Teilnehmer im Netzwerk durch ihre digitale Signatur eindeutig verifizieren kann.
Natürlich handelt es sich hier nicht um ein Allheilmittel, das sämtliche, wenn auch theoretische, Probleme beseitigt, sondern vielmehr um einen Schritt in die richtige Richtung. Wir sind gespannt, wie lange es noch dauern wird, bis die neue Protokollversion Einzug in einen neuen Release von Bitcoin Core finden wird. Bei der Implementierung von kryptografischen Verfahren sollte man sich jedenfalls lieber zu viel, als zu wenig Zeit nehmen.
