DER BYZANTINISCHE FEHLER: ABWEHR EINER ATTACKE

- Falk Borgmann

Über die Verteidigung verteilter Systeme

Im vorangegangenen Beitrag zum Byzantinischen Fehlermodell haben wir gezeigt, wie bereits ein Anteil von einem Drittel an gekaperten Knoten den Consensus verhindern und die Vertrauenswürdigkeit des gesamten Clusters zerstören kann. Daraus ergibt sich die folgerichtige Frage, wie ein System aufgebaut sein muss, um „Byzantine-Fault-tolerant“ zu sein.

Nach den Prinzipien der „Byzantine-Fault-Tolerance“ ist ein verteiltes System dann unangreifbar, wenn mehr als zwei Drittel der an einem Cluster beteiligten Knoten korrekt arbeiten. Der Anteil an von Angreifern gekaperten Instanzen muss also unterhalb der Ein-Drittel-Grenze bleiben. Um diese Annahme zu bestätigen, simulieren wir auch in diesem Beitrag ein Angriffs-Szenario, diesmal aber auf einen Vier-Knoten-Cluster. Ziel der Transaktion soll auch hier exemplarisch die Vereinbarung eines Termins zu einer bestimmten Uhrzeit sein.

Deep Shore

Abbildung 1: intakter Vier-Knoten-Cluster

Knoten A löst den Prozess aus, indem er die Nachricht mit dem Terminvorschlag „16.30 Uhr“ zeitgleich an die Knoten B, C und D versendet. Die Knoten B, C und D wiederum bestätigen sich gegenseitig und dem Versender, die Information mit dem Inhalt „16.30 Uhr“ erhalten zu haben. Die Informationen sind auf allen Instanzen homogen, die Transaktion ist validiert, der Consensus erreicht. Das Treffen findet also um 16.30 Uhr statt.

Deep Shore

Abbildung 2: Attacke im Vier-Knoten-Cluster

In dieser Abbildung wurde Knoten A durch einen Angreifer unter feindliche Kontrolle gebracht. Über diesen gekaperten Knoten werden drei unterschiedliche Uhrzeiten an die Peers geschickt, um Verwirrung über den tatsächlichen Termin zu stiften. Die loyalen Instanzen stellen anhand ihrer Peers sofort fest, dass sie widersprüchliche Informationen erhalten haben – allerdings können sie nicht ohne Weiteres ermitteln, wer der Urheber dieses Problems ist. Ohne diese Feststellung ist eine Bereinigung und Absicherung des Systems nicht möglich. Genauso wenig kann anhand der vorliegenden Informationen eine gültige Terminvereinbarung erfolgen.

Deep Shore

Abbildung 3: Validierung im Vier-Knoten-Cluster

Die Herausforderung für jeden einzelnen der loyalen Knoten besteht also darin, a) festzustellen, welche der Peer-Knoten vertrauenswürdig sind und b) dabei ein Quorum von über zwei Drittel gegenüber den illoyalen Knoten zu erreichen. Im Fall eines Vier-Knoten-Systems müssen also mindestens drei intakte Instanzen den einen feindlichen Knoten isolieren. Erreicht wird das über einen einfachen Gegenvorschlag: Stellt beispielsweise Knoten C die Nicht-Qualifizierbarkeit einer empfangenen Nachricht fest, sendet er zur Validierung einen eigenen Vorschlag mit dem Inhalt „16.30 Uhr“ an alle Peers. Die intakten Knoten B und D bestätigen diesen Wert sowohl gegenüber dem Sender als auch untereinander. Lediglich der fremdbestimmte Knoten A sendet auch hier einen abweichenden Wert „14.00 Uhr“ in den Cluster zurück bzw. versucht sich gegenüber C mit einer korrekten Rückmeldung zu verstecken, was zunächst auch gelingt. Somit erhält C eine Bestätigung von allen Instanzen und nimmt an, dass „16.30“ Uhr klappt. Aus der Sicht von D und B bestätigen jeweils zwei der anderen drei Knoten ebenfalls den Vorschlag „16.30 Uhr“. Da es keinen Grund gibt, diesem Quorum aus drei zu misstrauen, werden D und B den Vorschlag ebenfalls als Konsens akzeptieren – die Transaktion „16.30 Uhr“ ist gültig. A ist gegen drei Instanzen also machtlos. Für D und B hat sich mit dem Vorgehen gleichzeitig A als derjenige zu erkennen gegeben, der inkonsistente Informationen schickt. Außer C wissen nun alle, wer der Angreifer ist. Über eine Validierungsnachricht könnten nun D oder B die Enttarnung von A anstoßen, so dass auch C die abweichenden Antworten von A bewusst werden. Da gleichzeitig die drei loyalen Knoten gemeinsam das System-Quorum erfüllen, kann Knoten A im weiterem Verlauf aus dem System ausgeschlossen werden.

Dieses vereinfachte Lösungsmodell berücksichtigt natürlich nicht alle Umstände einer realen Transaktion. Zum Beispiel werden einzelne Nachrichten innerhalb des Clusters nicht komplett zeitgleich ausgetauscht. Stattdessen ist der Ablauf in einem verteilten System immer sequenziell, so dass die Erkenntnis, bei welchem Knoten es sich um die infizierte Instanz handelt, real erst nach dem Abschluss des Validierungsprozesses feststeht. Ein Schutzmechanismus wirkt also erst für spätere Transaktionen vollständig.

Um den Modellablauf zu vervollständigen, wäre der konkrete Prozess des Ausschlusses eines infizierten Knotens zu betrachten. Dabei kommt nach der Identifikation des feindlichen Knotens ein Mechanismus zum Einsatz, bei dem die loyalen Knoten einen Vorschlag in Umlauf bringen, die aus ihrer Sicht als illoyal identifizierte Instanz A aus dem System auszuschließen. Dieser Mechanismus könnte als eine Validierungsnachricht im Cluster „beantragt“ werden. Da die drei korrekt funktionierenden Knoten sich einig wären und gemeinsam das Quorum erreichen, würde ein gültiger Konsens darüber hergestellt, dass diese Maßnahme korrekt ist. Der Angriff wäre also abgewehrt und das System vertrauenswürdig im Sinne einer „Byzantine Fault Tolerance“.

Teilen