Byzantinische Fehlertoleranz durch Gruppenkommunikation am Beispiel des Rampart-Toolkit Frank Mattauch

Transkript

1 1 Hauptseminar: Moderne Konzepte für weitverteilte Systeme: Peer-to-Peer-Netzwerke und fehlertolerante Algorithmen (DOOS) Byzantinische Fehlertoleranz durch Gruppenkommunikation am Beispiel des Rampart-Toolkit Frank Mattauch 1

2 2 Begriffsbildung 2 Rampart = Wehrgang, Wall, Schutzwall Toolkit = Werkzeug Rampart-Toolkit = Schutschildwerkzeug oder Werkzeug für einen Schutzschild

3 3 Was ist das Rampart-Toolkit? 3 Kern besteht aus Protokollen Byzantinische Fehlertoleranz bei zuverlässigem und atomaren Gruppenmulticast Erstes System, das dies demonstrierte

4 4 Verteiltes System ohne Redundanz 4

5 5 Verteiltes System mit Redundanz 5

6 6 State Machine Replication - Eigenschaften 6 Dienst implementiert durch mehrere Server. Eigenschaften der Server: Identisch Deterministisch Haben selben Anfangszustand

7 7 State Machine Replication - Szenario 7

8 8 State Machine Replication - Ablauf 8 1. Anfragen von Clients mittels atomarem Multicastprotokoll

9 9 State Machine Replication - Ablauf 9

10 10 State Machine Replication - Ablauf Anfragen von Clients mittels atomarem Multicastprotokoll 2. Reihenfolge erhaltende Bearbeitung bei den Servern

11 11 State Machine Replication - Ablauf 11

12 12 State Machine Replication - Ablauf Anfragen von Clients mittels atomarem Multicastprotokoll 2. Reihenfolge erhaltende Bearbeitung bei den Servern 3. Output-Voting beim Client

13 13 State Machine Replication - Ablauf 13

14 14 State Machine Replication - Reihenfolgeerhaltung 14

15 15 Annahmen zur Umgebung der Protokolle von Rampart 15 Verwendung digitaler Signaturen Private Schlüssel bei Severprozessen, öffentliche bei allen anderen Erste Schlüsselverteilung kann manuell erfolgen Öffentliche Schlüssel sind nach einem Ausfall wieder herstellbar

16 16 Annahmen zur Umgebung der Protokolle von Rampart 16 Schlüssel eines neuen Servers wird verteilt, bevor dieser in Aktion tritt Existenz eines Kommunikationskanals Zuverlässig Authentifizierbar Punkt-zu-Punktverbindung

17 17 Annahmen zur Umgebung der Protokolle von Rampart 17 Keine Annahmen zur Art der Fehler, da byzantinische Fehler Weniger als ein Drittel der Gruppenmitglieder fehlerhaft Gesamte System ist asynchron

18 18 Protokollschichten des Rampart-Toolkit 18

19 19 Gruppenmitgliedschaftsprotokoll 19

20 20 Gruppenmitgliedschaftsprotokoll - Aufgaben 20 Erstellen von Gruppensichten Ausliefern neuer Gruppensichten Hinzufügen und Entfernen von Gruppenmitgliedern Für Änderungen ausreichende Mehrheit notwendig

21 21 Gruppenmitgliedschaftsprotokoll - Gruppensichten 21

22 22 Gruppenmitgliedschaftsprotokoll - Gruppensichten 22

23 23 Gruppenmitgliedschaftsprotokoll - Gruppensichten 23 Böswillige Änderungen einer Gruppensicht nur durch Denial-of-Service Angriffe Evtl. keine Einigung auf eine Gruppensicht möglich, wenn alle Mitglieder zu schnell wechseln Kostenintensiv durch RSA

24 24 Echomulticast 24

25 25 Echomulticast - Aufgaben 25 Sicherstellen, dass jeder korrekte Prozess einer Gruppensicht dieselbe Nachricht an die nächsthöhere Schicht, den zuverlässigen Multicast, liefert

26 26 Echomulticast - Ablauf Multicasten einer Nachricht

27 27 Echomulticast - Ablauf 27

28 28 Echomulticast - Ablauf Multicasten einer Nachricht 2. Signieren der Nachricht und Antwort als Echo senden

29 29 Echomulticast - Ablauf 29

30 30 Echomulticast - Ablauf Multicasten einer Nachricht 2. Signieren der Nachricht und Antwort als Echo senden 3. Warten auf Echos und senden der Echos als Paket an die Gruppe

31 31 Echomulticast -Ablauf 31

32 32 Echomulticast - Ablauf 1. Multicasten einer Nachricht 2. Signieren der Nachricht und Antwort als Echo senden 3. Warten auf Echos und senden der Echos als Paket an die Gruppe 4. Überprüfen auf korrekte Signaturen selbe Sichtnummer 32

33 33 Echomulticast - Ablauf Falls Überprüfung erfüllt: Weitergabe der Nachricht

34 34 Zuverlässiger Multicast 34

35 35 Zuverlässiger Multicast - Aufgaben 35 Alle korrekten Gruppenmitglieder bekommen dieselben Nachrichten trotz böswilliger Multicasts manipulierter Mitlieder (ohne Reihenfolge!) Liefern von Gruppensichten

36 36 Zuverlässiger Multicast - Eigenschaften 36

37 37 Zuverlässiger Multicast - Eigenschaften 37

38 38 Zuverlässiger Multicast - Eigenschaften 38

39 39 Zuverlässiger Multicast - Eigenschaften 39 Nachricht ist Gruppensicht Multicastnachricht eines Gruppenmitglieds Fortschritt des Protokolls kann von der Entfernung eines Guppenmitglieds abhängen

40 40 Zuverlässiger Multicast - Ablauf 40 Zwei Fälle: 1. Keine Änderung der Gruppenzugehörigkeit: Zuverlässiger Multicast führt Echomulticast aus Reicht Nachrichten von Echomulticastschicht einfach weiter 2. Änderung der Gruppenzugehörigkeit

41 41 Zuverlässiger Multicast - Ablauf 41 Änderung der Gruppenzugehörigkeit: Zwei Fälle: 1. Keine weiter Änderung der Gruppenzugehörigkeit während eines Protokolldurchlaufs 2. Änderungen sind notwendig (z.b. Flush oder Ende -Nachricht wird vom Prozess nie empfangen)

42 42 Zuverlässiger Multicast - Ablauf 42 Änderung der Gruppenzugehörigkeit und keine weitere Änderung während eines Protokolldurchlaufs: 1. Multicast einer neuen Gruppensicht

43 43 Zuverlässiger Multicast - Ablauf 43

44 44 Zuverlässiger Multicast - Ablauf 44 Änderung der Gruppenzugehörigkeit und keine weitere während eines Protokolldurchlaufs: 1. Multicast einer neuen Gruppensicht 2. Bei Empfang: Prozess unterlässt zuverlässige Multicasts Ende -Nachricht senden Auf Ende-Nachrichten der anderen warten

45 45 Zuverlässiger Multicast - Ablauf 45

46 46 Zuverlässiger Multicast - Ablauf 46

47 47 Zuverlässiger Multicast - Ablauf 47

48 48 Zuverlässiger Multicast - Ablauf 48 Änderung der Gruppenzugehörigkeit und keine Änderung während eines Protokolldurchlaufs 1. Multicast einer neuen Gruppensicht 2. Bei Empfang: Prozess unterlässt zuverlässige Multicasts Ende -Nachricht senden Auf Ende-Nachrichten der anderen warten

49 49 Zuverlässiger Multicast - Ablauf 3. Nach Empfang aller Ende -Nachrichten: Flush -Nachricht senden Auf Flush -Nachrichten der anderen warten 4. Weiterreichen der Sicht an die atomare Multicastschicht 5. Wiederaufnahme des zuverlässigen Multicasts 49

50 50 Zuverlässiger Multicast - Ablauf 50

51 51 Zuverlässiger Multicast - Ablauf 51

52 52 Zuverlässiger Multicast - Ablauf 52

53 53 Zuverlässiger Multicast - Ablauf 53

54 54 Zuverlässiger Multicast - Ablauf 54 Änderung der Gruppenmitgliedschaft und Änderung während eines Protokolldurchlaufs: 1. Empfang einer neuen Sicht 2. Keine neuen Prozesse mehr in Gruppensicht aufnehmen 3. Nicht reagierende Mitglieder entfernen und neue Sicht erstellen

55 55 Zuverlässiger Multicast - Ablauf 4. Wiederhole bis Weitergabe von Verwaltungsinformation und Gruppensicht an atomare Multicastschicht möglich 55

56 56 Atomarer Multicast 56

57 57 Atomarer Multicast - Aufgaben 57 Alle korrekten Gruppenmitglieder liefern dieselbe Nachricht in derselben Reihenfolge (Unterschied zuverlässiger Multicast!)

58 58 Atomarer Multicast - Sequencer 58

59 59 Atomarer Multicast - Sequencer 59 Ausgewähltes Gruppenmitglied: Sequencer Sequencer legt Reihenfolge-Nachrichten fest

60 60 Atomarer Multicast - Prinzipieller Ablauf 60

61 61 Atomarer Multicast - Prinzipieller Ablauf 61

62 62 Atomarer Multicast - Prinzipieller Ablauf 62

63 63 Atomarer Multicast - Prinzipieller Ablauf 63

64 64 Atomarer Multicast - Prinzipieller Ablauf 64

65 65 Atomarer Multicast - Ablauf, Sonderfall 65 Situation: Neue Sicht wird geliefert Ungelieferte Nachrichten der alten Sicht vorhanden Erst Lieferung der Nachrichten der alten Sicht in deterministischer Reihenfolge, dann Lieferung der neuen Sicht

66 66 Atomarer Multicast - Sicherheit, Problemstellung Situation: Sequencer verhindert Weitergabe der Nachrichten an Anwendung Mögliche Wege: 66 Reihenfolge-Nachricht wird nie gesendet Sequencer ordnet Senden einer nicht existenten Nachricht an; andere Nachrichten müssen warten

67 67 Atomarer Multicast - Sicherheit, Lösung 67 Entfernung des Sequencers nach Timeout, wenn Nachricht erfolgreich an Prozess ausgeliefert und Reihenfolge-Nachricht fehlt

68 68 Clients - Ablauf 68 Client muss nur einen Server lokalisieren können: Broadcast (Externer) Hinweis Vorgehen: 1. Client schickt Anfrage an beliebigen Server

69 69 Clients - Ablauf 69

70 70 Clients - Ablauf 70 Vorgehen: 1. Client schickt Anfrage an beliebigen Server 2. Server schickt Anfrage mit atomarem Multicast an Servergruppe

71 71 Clients - Ablauf 71

72 72 Clients - Bewertung 72 Vorteile: Client muss nur einen Server lokalisieren können Server sammelt Anfragen von Clients und schickt nur ein Paket

73 73 Clients - Bewertung 73 Nachteile: Client schickt Anfrage an Server, Server arbeitet fehlerhaft; Manipulation oder Blockieren der Anfrage Beide Fälle können erkannt werden

74 74 Output-Voting 74 Zwei Output-Voting Protokolle: 1. Output-Voting bei Clients 2. Output-Voting bei Servern

75 75 Output-Voting - Bewertung 75 Output-Voting bei Clients Nachteil: Client muss jeden Server selbst identifizieren

76 76 Output-Voting - Bewertung 76 Output-Voting bei Servern Vorteil: Client muss nicht jeden Server selbst identifizieren, sondern nur den Dienst Nachteile: Schlüssel des Dienstes muss unter den Servern verteilt werden (Aufwand!)

77 77 Output-Voting - Bewertung 77 Evtl. Spezialhardware für RSA notwendig

78 78 Zusammenfassung 78 State Machine Replication Atomarer Multicast Gruppenmitgliedschaft Echomulticast Zuverlässiger Multicast Atomarer Multicast bei Servern

79 79 Zusammenfassung 79 Atomarer Multicast bei Clients Output-Voting