Beiträge

Der Byzantinische Fehler: Attacke auf ein verteiltes System

13.4.2018 / Falk Borgmann, Strategy Consultant, Deepshore GmbH

Über die Angreifbarkeit verteilter Systeme

In diesem und dem nächsten Beitrag befassen wir uns anhand einfacher Beispiele mit der Wirkung von Angriffen nach dem Modell des Byzantinischen Fehlers. Dabei geht es vorrangig um die Frage, unter welchen Umständen innerhalb eines verteilten Systems ein Angriff erfolgreich sein kann.

Das hinter diesem Modell stehende theoretische Problem geht der Legende nach auf die Belagerung von Konstantinopel durch die Osmanen im 15. Jahrhundert zurück. Dabei wurde die Stadt von verschiedenen Einheiten der osmanischen Armee belagert, deren lokale Kommandeure vor der Herausforderung standen, den optimalen Zeitpunkt für einen Angriff untereinander abzustimmen und diesen Angriff in der Folge zu koordinieren.

Um das Ergebnis gleich vorweg zu nehmen: Nach den Regeln eines „Byzantine-Fault-Tolerance“-Modells ist ein verteiltes System dann nicht angreifbar, wenn mehr als zwei Drittel der an einem Cluster beteiligten Knoten korrekt arbeiten. Umgekehrt betrachtet, dürfen also nur weniger als ein Drittel der involvierten Instanzen feindlicher Natur sein. Wie dieses Ergebnis zustande kommt, soll hier nicht weiter erläutert werden – es gibt dazu andernorts mehr als genug an fachlichen Arbeiten in beliebiger Tiefe.

Unser Thema ist die Konsequenz des Modells für die Sicherheit von Blockchain-Umgebungen. Denn nach der Byzantinischen Fehlertheorie reicht in einem kleinen Cluster mit drei Knoten bereits ein einziger erfolgreicher Angriff auf einen Knoten, um einen erfolgreichen Consensus zu verhindern. Und wer jetzt ganz im Sinne der parlamentarischen Demokratie denkt, eine Zwei-Drittel-Mehrheit müsste gegen das eine feindliche Drittel gewinnen, liegt falsch, wie die beiden folgenden Grafiken zeigen:

Deep Shore

Abbildung 1: intakter Drei-Knoten-Cluster

Unsere stark vereinfachte Blockchain enthält drei Knoten innerhalb des Clusters. Um das Beispiel weiter zu vereinfachen, nehmen wir an, es ginge um die Vereinbarung eines gemeinsamen Termins zu einer bestimmten Uhrzeit. Der Knoten mit der Bezeichnung A sendet quasi zeitgleich die Nachricht mit dem Inhalt „16.30 Uhr“ an die Knoten B und C. Die Knoten B und C wiederum bestätigen sich gegenseitig und dem Versender A den Erhalt der Information mit dem Inhalt „16.30 Uhr“. Die Transaktion ist gesichert, die Blockchain intakt, der Termin Konsens.

Deep Shore

Abbildung 2: Drei-Knoten-Cluster nach erfolgreicher 1-Knoten-Attacke

In dieser Abbildung ist Knoten B unter die Kontrolle eines Angreifers gelangt. Wir nehmen gleichzeitig an, dass innerhalb des Clusters die einfache Mehrheit (Quorum), in diesem Fall also zwei Knoten, darüber entscheidet, ob eine Information oder ein Zustand im Cluster als korrekt definiert ist oder nicht.

Der intakte Knoten A sendet die Nachricht „16.30 Uhr“ an seine Peers und erhält sowohl vom intakten Knoten C als auch vom gekaperten Knoten B zunächst die Bestätigung für „16.30 Uhr“. Das Gleiche passiert zwischen Knoten A und C. Es scheint also zunächst alles bestens zu sein, denn nun hat Knoten A eine gültige Bestätigung in seinem lokalen Speicher. Damit ist die Gültigkeit der Gesamttransaktion aber noch nicht hergestellt – denn für den ganzen Cluster ist dies erst der Fall, wenn zwei der drei Knoten die Transaktion sowohl validiert als auch lokal manifestiert haben. Bisher ist das aber nur für A der Fall.

C erhält unterdessen vom gekaperten Knoten B die Information, A habe nicht „16.30 Uhr“, sondern „18.45 Uhr“ übermittelt. Knoten C hat damit zwei sich widersprechende Angaben über den Inhalt der Nachricht – und wird die Nachricht nicht als validiert kennzeichnen. Der fremdgesteuerte Knoten A vailidiert die Originalnachricht natürlich ebenfalls nicht. Und so ist trotz einer Zwei-Drittel-Mehrheit an intakten Knoten kein Consensus möglich. Der geplante Termin platzt, die Byzantinische Attacke war im gesamten Cluster erfolgreich.

Aus unserem Special
»BLOCKCHAIN: COMPLIANCE FÜR DIE BUSINESS CLOUD«
Beitrag 3/6
Teilen: