Sicherheit in einem offenen Internet * ein Widerspruch in sich?

Verteilte Algorithmen und
Datenstrukturen
Christian Scheideler
Institut für Informatik
Universität Paderborn
Verteilte Algorithmen und
Datenstrukturen
Vorlesung: Mi 14-16 Uhr, F0.530
Übung:
Mi 16-17 Uhr, F0.530
Webseite: http://www.cs.uni-paderborn.de/?id=10640
Prüfung:
• 50%: Softwareprojekt
• 50%: mündliche Prüfung
• Notenverbesserung um 0,3: Präsentation in
Übung
Voraussetzungen: Grundkenntnisse in Algorithmen und Datenstrukturen
Verteilte Algorithmen und
Datenstrukturen
Übungsaufgaben:
• wöchentliche Ausgabe und Abgabe am
Mittwoch
• teils theoretisch, teils praktisch
Skript und Übungsaufgaben: Webseite
Bücherempfehlungen: kein Buch (Vorlesung
basiert auf neuesten Ergebnissen)
Verteilte Algorithmen und
Datenstrukturen
Inhalt:
1. Einführung
2. Netzwerktheorie
3. Routing und Scheduling
4. Hashing und Caching
5. Verteilter Konsens und Transaktionen
6. Dynamische Netzwerke für Zusammenhang
(Cliquen, Cliquegraphen und Expander)
7. Dynamische Netzwerke für Routing
(Verankerte und dezentrale Netzwerke)
8. Verteilte Datenstrukturen
9. Drahtlose Netzwerke
Einführung
Übersicht:
• Motivation
• Was ist Robustheit?
• Das Subjects Paradigma
(Grundlage für verteilte Programme)
• Die Simulationsumgebung
• Beispiele
Einführung
Sequentielle Algorithmen
und Datenstrukturen
Verteilte Algorithmen
und Datenstrukturen
Einführung
Was sind Kernprobleme für verteilte Systeme?
Verteilte Systeme
• Jedes verteilte System benötigt einen
zusammenhängenden Wissensgraph über
die Teilnehmer.
• Solch ein Graph: Overlaynetzwerk
Verteilte Algorithmen und
Datenstrukturen
Inhalt:
1. Einführung
2. Netzwerktheorie
3. Routing und Scheduling
4. Hashing und Caching
5. Verteilter Konsens und Transaktionen
6. Dynamische Netzwerke für Zusammenhang
(Cliquen, Cliquegraphen und Expander)
7. Dynamische Netzwerke für Routing
(Verankerte und dezentrale Netzwerke)
8. Verteilte Datenstrukturen
9. Drahtlose Netzwerke
Verteilte Systeme
Skalierbares Overlaynetzwerk:
• Hoher Durchsatz an Nachrichten
• Jede Nachricht benötigt nur geringe Zeit
Verteilte Algorithmen und
Datenstrukturen
Inhalt:
1. Einführung
2. Netzwerktheorie
3. Routing und Scheduling
4. Hashing und Caching
5. Verteilter Konsens und Transaktionen
6. Dynamische Netzwerke für Zusammenhang
(Cliquen, Cliquegraphen und Expander)
7. Dynamische Netzwerke für Routing
(Verankerte und dezentrale Netzwerke)
8. Verteilte Datenstrukturen
9. Drahtlose Netzwerke
Verteilte Systeme
Skalierbares Speichersystem:
• Hoher Durchsatz an read/write Operationen
• Jede Operation benötigt nur geringe Zeit
Verteilte Algorithmen und
Datenstrukturen
Inhalt:
1. Einführung
2. Netzwerktheorie
3. Routing und Scheduling
4. Hashing und Caching
5. Verteilter Konsens und Transaktionen
6. Dynamische Netzwerke für Zusammenhang
(Cliquen, Cliquegraphen und Expander)
7. Dynamische Netzwerke für Routing
(Verankerte und dezentrale Netzwerke)
8. Verteilte Datenstrukturen
9. Drahtlose Netzwerke
Verteilte Systeme
In offenen verteilten System kann sich die
Menge der Teilnehmer stark mit der Zeit
verändern.
Problem: wie erhalten wir die Funktionalität
eines verteilten Systems??
Verteilte Systeme
Drei grundlegende Ansätze:
server-basiert
verankert
peer-to-peer
strukturierte Overlaynetzwerke
Verteilte Algorithmen und
Datenstrukturen
Inhalt:
1. Einführung
2. Netzwerktheorie
3. Routing und Scheduling
4. Hashing und Caching
5. Verteilter Konsens und Transaktionen
6. Dynamische Netzwerke für Zusammenhang
(Cliquen, Cliquegraphen und Expander)
7. Dynamische Netzwerke für Routing
(Verankerte und dezentrale Netzwerke)
8. Verteilte Datenstrukturen
9. Drahtlose Netzwerke
Verteilte Datenstrukturen
Transparente Datenstrukturen:
• Verteilte Hashtabelle
• Verteilte Suchstrukturen
• Verteilter Heap
Transparenz: keine extra Links notwendig
Verteilte Systeme
Korrektheit, Skalierbarkeit, Robustheit,...
Verteilte Algorithmen und
Datenstrukturen
Inhalt:
1. Einführung
2. Netzwerktheorie
3. Routing und Scheduling
4. Hashing und Caching
5. Verteilter Konsens und Transaktionen
6. Dynamische Netzwerke für Zusammenhang
(Cliquen, Cliquegraphen und Expander)
7. Dynamische Netzwerke für Routing
(Verankerte und dezentrale Netzwerke)
8. Verteilte Datenstrukturen
9. Drahtlose Netzwerke
Verteilte Systeme
Robustheit:
• Operationen arbeiten korrekt selbst unter
massiven Angriffen
• System kann sich selbständig erholen
Fundamentales Dilemma
• Skalierbarkeit:
Minimiere Ressourcen für Operationen
• Robustheit:
Maximiere Ressourcen für Angriffe
Trotzdem
Skalierbare
erstaunlich
Systemegute
leicht
Lösungen
zu attackieren!!
möglich
Konsensus
5
3
8
2
3
3
3
3
Konsensus
Modell:
• n Spieler
• Jeder Spieler kennt alle anderen
• Zeit verläuft in synchronen Fragerunden
• Pro Fragerunde kann jeder Spieler nur
O(1) viele Fragen stellen / beantworten
5
Was ist Deine Nummer?
8.
8
Konsensus
Alle Spieler ehrlich:
• Minimum-Regel:
x
Was ist Deine Nummer?
y
y.
x:=min{x,y}
Zufälliger Spieler
• Nach O(log n) Runden haben alle Spieler
dieselbe Nummer m.h.W.
Konsensus
Ein Spieler unehrlich:
• Minimum-Regel: unbeschränkte Laufzeit.
5
Was ist Deine Nummer?
1
5.
irgendwann später…
5
Was ist Deine Nummer?
1.
1
Konsensus
Besser: Median-Regel:
z
Nummer?
x
z.
Zufälliger Spieler
Nummer?
y
y.
x:=median{x,y,z}
Zufälliger Spieler
• O(log n) Runden m.h.W.: ehrliche Spieler
• O(log n loglog n): max n gegn. Spieler
DoS-resistentes Informationssystem
Past-Insider-Attacke: Gegner kennt alles
über System bis (unbekannte) Zeit t0
Ziel: skalierbares Informationssystem,
so
Sie sind gefeuert!
dass alles, was nach t0 eingefügt oder
aktualisiert worden ist, sicher (m.h.W.)
gegen past-insider DoS Attacken ist
Robustheit
Entkopplung bzgl. Ort, Zeit und Fluss.
• Ortentkopplung: interagierende Prozesse
müssen nicht ihre physikalischen Orte kennen
• Zeitentkopplung: interagierende Prozesse
müssen nicht zur selben Zeit miteinander
interagieren
• Flussentkopplung: die Ausführung einer Aktion
innerhalb eines Prozesses sollte nicht von
anderen Prozessen abhängen
Gesetze der Robustheit
Entkopplung und Selbsterholung
von jedem Zustand
Nur dann können verteilte Systeme
hochgradig skalierbar und verfügbar sein
Gesetze der Robustheit
Vollständige Kontrolle über Ressourcen
und Informationen
Nur dann können verteilte Prozesse sicher
ausgetauscht werden und miteinander interagieren
Gesetze der Robustheit
1. Eignerzustimmung und Kontrolle
2. Geringste Ausgesetztheit
3. Selbsterholung
4. Entkopplung
[POLA, K. Cameron: The laws of identity, D. Epp:
The eight rules of security,…]
Gesetze der Robustheit
Eignerzustimmung und Kontrolle:
• Eindeutig definierte Zuständigkeiten
• Vollständige Kontrolle über Info & Ressourcen
Geringste Ausgesetztheit:
• Nicht mehr Wissen als notwendig
• Vollst. Kontrolle über Informationsfluss
Selbsterholung:
• Erholung muss von jedem Zustand aus möglich sein
(solange die Plattform noch im legalen Zustand ist)
Entkopplung:
• keine Synchronisation notwendig für die Primitive
Subjects Paradigma
• Subjekte
• Objekte
• Relaypunkte
• Aktionen
Subjects Paradigma
Subjekte:
Wichtig für
• atomar
Verifikation
und Kontrolle!
• gebunden an Ort
• statische Menge an Aktionen
• sequentielle Abarbeitung von Aufgaben
• Objekte und erzeugte Relays und Subjekte lokal
zum Subjekt
• keine Identität, d.h. Informationsaustausch ist
nur über Relays möglich
Subjects Paradigma
atomar, anonym, aktiv, unbeweglich,
enthält Objekte, Relays und Aktionen
atomar, anonym, passiv, beweglich
atomar, Identitäten erzeugbar,
passiv, unbeweglich
atomar, anonym, unbeweglich,
garantierte Terminierung
Subjekt
kann Subjekte erzeugen
kann Objekte besitzen und
Aktionen ausführen
kann Verbindungen aufbauen,
die nicht umlegbar sind
Relaypunkte
Keine Anwender-zugreifbare Identität, aber
(dunkle) Identitätsobjekte erzeugbar
Ausgehende Kante bei Erzeugung festgelegt.
a) ohne Identität
A
b) mit Identität
R
R
R
Erstes Kennenlernen
R
A
B
R
Öffentliche Identität (TAN)
• Subjekte besitzen keine Identität
• Identitäten nicht kopierbar, nur einmal verwendbar
• Relayverbindungen können nicht umgelegt werden
Vorstellung
A
B
R
R>B
C
B>A
A>B
Zustimmung und Kontrolle, geringste Ausgesetztheit?
Delegation von Rechten
Zustimmung und Kontrolle, geringste Ausgesetztheit?
Quelle des Objekts
R
R
R’
R‘‘
Startpunkt des Objekts wird dem Objekt mitgegeben.
Damit kann bei R’’ überprüft werden, wer die Quelle
des Objekts war.
Nachkommen
Ressourcenkontrolle
Mutter
Kind
Kind in derselben Maschine wie Mutter.
Nachkommen
Einfrieren
Löschen
Clones
Erinnerung: Subjekte unbeweglich, atomar
A
A‘
B
A’
Zustimmung und Kontrolle, geringste Ausgesetztheit?
Clones
Objekte prinzipiell völlig offen gegenüber Eigner.
Objekte mit Zugriffsrechten: Clones
A
O
B
S
O
Zustimmung und Kontrolle, geringste Ausgesetztheit?
Erholbarkeit
• Existierende Objekte immer erreichbar, da
immer Subjekt zugeordnet
• Nachkommenbaum der Subjekte immer
zusammenhängend und damit Ressourcenkontrolle lückenlos
• Kommunikation von Kind zu Mutter immer
vorhanden, und damit immer schwacher
Kommunikationszusammenhang der
Subjekte
Subjects Paradigma
• Simulationsumgebung existiert basierend
auf C++
• Vorlesungsseite:
– Einführung in C++
– Link auf frei verfügbaren Compiler
– Subjects Library und Beispielprogramme
Objekte
Object: Basisklasse für Objekte
• Container für dynamische Daten
• keine Identität (nur über Referenz
erreichbar)
• keine Aktionen
• transferierbar, aber hat zu jedem Zeitpunkt
eindeutigen Besitzer (Subjekt)
• Besitzer kann auf alle Anwendungsdaten
innerhalb vom Objekt zugreifen
Objekte
Von Object abgeleitete Klassen:
• Identity: enthält Identität eines Relaypunkts
• Clone: enthält “schlafendes” Subjekt
Objekte dieser Klassen sind nur einmal verwendbar, und
auf deren Inhalte können Subjekte nicht zugreifen.
Benutzerdefinierte Objekte:
ObjectType(<UserObject>)
{
public:
<benutzerdefinierte Variablen>
<evtl. Konstruktor>
};
Relays
Relay: Klasse für Relaypunkte
• nicht transferierbar
• nur eine ausgehende Kante, die bei
Generierung erzeugt wird und dann nicht
mehr umgelegt werden kann
• anonym, aber Identitäten können für
eingehende Kanten generiert und
transferiert werden
Relays
Benutzerdefinierte Relays:
RelayType(<UserRelay>)
{
public:
<benutzerdefinierte Variablen>
<evtl. Konstruktor>
};
Identitäten
Anweisungen:
• new Identity(Relay *r): erzeugt neue
öffentliche Identität von Relay r
• new Identity(Relay *r, Relay *r’): erzeugt
private Identität von r für r’
• delete i: löscht Identität
Clones
Anweisungen:
• publicClone(<UserSubject>,NONE) oder
publicClone(<UserSubject>,<UserObject> *o):
erzeugt öffentliches Clone vom Typ UserSubject
• privateClone(<UserSubject>,NONE, Relay *r)
oder
privateClone(<UserSubject>,<UserObject> *o,
Relay *r): erzeugt privaten Clone vom Typ
UserSubject für Relay r
• delete c: löscht Clone
Subjekte
Subject: Basisklasse für Subjekte
• atomar, anonym
• können Objekte und Relays besitzen
• nicht transferierbar
• Kindsubjekt immer am selben Ort wie Mutter
• frei definierbare, aber von Anfang an fest
vorgegebene Aktionen, die auf alle Anwendungsdaten innerhalb eines Subjekts und deren
Objekte zugreifen können
Subjekte
Benutzerdefiniertes Subjekt:
SubjectType(<UserSubject>)
{
protected:
<benutzerdefinierte Variablen>
<interne benutzerdefinierte Methoden>
public:
FirstAction(<UserSubject>,<Action>)
<benutzerdefinierte Aktionen>
};
Subjekte
Alle extern aufrufbaren Aktionen müssen
folgende Form haben:
Action <UserAction>() {…}
Action <UserAction>(<UserObject> *o) {…}
Start der Subjects-Umgebung:
runSubjects(<UserSubject> *s, <UserObject> *o, t);
// t=0: laufe, bis keine Aufgaben mehr
Subjekte
Reservierte Variablen:
• ulong _debugID: eindeutige Identität für
Debugging
• Relay *parent: Relay zu Muttersubjekt
• ulong source: ID des Relays, von dem
Aufruf kam (lokal eindeutig)
• ulong sink: ID des Relaypunkts, der Aufruf
empfangen hat
Subjekte
Anweisungen:
• new(<UserSubject>,NONE) oder
new(<UserSubject>,<UserObject> *o):
erzeugt neues Subjekt
• wakeupClone(Clone *c): aktiviert Subjekt
im Clone c
• delete(s): löscht Subject (muss Kind sein,
damit möglich)
Wichtig: bei new/delete “()” benutzen!
Subjekte
Anweisungen:
• new Relay: erzeugt neuen Relaypunkt, dessen
ausgehende Kante zum Subjekt selbst zeigt
• new Relay(Identity *i): erzeugt Relaypunkt mit
Verbindung zum Relaypunkt mit Identität i (damit
wird i invalidiert)
• delete r: löscht Relaypunkt r
• call(verb, object | NONE): generiert Anfrage
verb(object) für eigenes Subjekt
• rcall(verb, object | NONE): generiert Anfrage
verb(object) für Ziel von Relay r
Subjekte
Anweisungen:
• wakeup(s): weckt Subjekt s auf (und alle
seine Nachfolger im Stammbaum)
• freeze(s): friert Subjekt s ein (und alle
seine Nachfolger im Stammbaum)
• int idle(): gibt an, ob noch Anfragen für
Subjekt
• int idle(Relay *r): gibt an, ob noch
ausgehende Anfragen für Relay r
Subjects Paradigma
• Ursprung: Hewitts Actor Modell (1973)
für neuronale Netzwerke
• Seitdem hauptsächlich Arbeiten im
Bereich der Betriebssysteme und
Programmiersprachen
(EROS, E Language, Singularity,…)
Beispiele
• Hello-Beispiele und anderes auf der
Webseite
•
•
•
•
SPAM-resistentes Email-System
Robustes DNS
Digital Rights Management
Online Banking
SPAM-resistente Emails
Einsichten:
• Grundlegendes Problem: ungenehmigte
Emails
• Genehmigung muss an Absender und
nicht an Emails geknüpft sein
• Genehmigungen müssen zurücknehmbar
sein
• Die Identität des Absenders (und des
Adressaten) darf nicht transferierbar sein.
SPAM-resistente Emails
Subjects: anfangs kann niemand mit Alice
kommunizieren (nicht einmal die Mutter).
Alice
SPAM-resistente Emails
Alice und Bob sind nicht verbunden:
Alice
Bob
Bob kann keine Nachricht direkt an Alice
schicken.
SPAM-resistente Emails
Erste Kontaktaufnahme:
R
Alice
Bob
R
Öffentliche Identität (TAN)
SPAM von Bob: Alice löscht R
SPAM-resistente Emails
Vorstellung:
Alice
Bob
R
R>B
Carol
B>A
A>B
SPAM-resistente Emails
Problem: Alice will mit David kommunizieren, kennt aber David nicht.
Lösung: System, das Beziehungen zeigt?
(wie Xing, Facebook,…)
Alice
Bob
Carol
David
Robustes DNS
DNS: Hierarchische Menge von Servern
Internet
Root Server
Benutzer
Robustes DNS
Aufgabe des DNS: Namen  IP-Adressen
Aufgabe hier: übersetze Namen in Identitäten
Besserer Schutz?
A A
A
Amazon
Google
Benutzer
Robustes DNS
Aufgabe des DNS: Namen  IP-Adressen
Aufgabe hier: übersetze Namen in Identitäten
Besserer Schutz?
Angreifer
A A
A
Amazon
Angreifer
Google
Angreifer
Benutzer
Robustes DNS
Angreifer
A A
A
Amazon
Google
Benutzer
Google hat festen Link zu Amazon: kein
Angreifer kann Amazon übernehmen
Robustes DNS
A A
A
Amazon
Google
Angreifer
Benutzer
Benutzer hat festen Link zu Google: kein Angreifer
kann Google übernehmen, es sei denn, Benutzer fällt auf Phishing-Atacke rein…
Robustes DNS
Angreifer
A A
A
Amazon
Google
Benutzer
Benutzer versucht, alle Identitäten von Amazon
(z.B. für DoS-Attacke) an sich zu ziehen: Google
kann das erkennen und schließt Benutzer aus.
Robustes DNS
Angreifer
A A
A
Amazon
Google
Benutzer
Problem: Angreifer startet Sybil-Atacken
(d.h. generiert beliebig viele Benutzer)
Digital Rights Management
Problem: Digitaler Content ist kopierbar.
Hardware:
• Kassettenrekorder
• CD-Brenner
• DVD-Brenner
• Blueray-Brenner
Hauptproblem
Software:
• Digitaler Schutz knackbar / umgehbar
Digital Rights Management
Software-Attacken:
• Benutzer installiert Ripping-Software, um
Raubkopien seines Contents zu erstellen
• Benutzer holt sich Content von einer
Tauschbörse
• Legaler Content vom Benutzer wird über
Virus / Trojaner von außen gestohlen
Digital Rights Management
Nutzungsproblem: DRM-Modelle der Provider oft sehr eingeschränkt, was legale
Nutzer verärgert.
Mögliche Modelle für Provider und Nutzer:
1. Content kopierbar, aber nur von einem
Benutzer verwendbar.
2. Content nicht kopierbar, aber beliebig
weitergebbar.
Digital Rights Management
2. Modell: Content nicht kopierbar, aber
beliebig weitergebbar.
Durch Clones umsetzbar:
X
Sony
X
X
Song X
Song X
Alice
X
Bob
Digital Rights Management
2. Modell: Content nicht kopierbar, aber
beliebig weitergebbar.
Vorteil: Nutzer kann X nicht inspizieren, da
Zugriff über Sony-Subjekt kontrolliert.
X
Sony
Alice
Bob
Digital Rights Management
2. Modell: Content nicht kopierbar, aber
beliebig weitergebbar.
Vorteil: X kann nicht von außen (ohne Handlung von Alice) gestohlen werden.
X
Sony
Alice
Bob
Online Banking
Problem: Sichere Transaktionen zwischen
Kunde und Bank
Online Banking
Umsetzung in Subjects-Umgebung:
R
Bank
Kunde
R
Öffentliche Identität (TAN)
Probleme:
• R kommt nicht von Bank
• R wird durch Gegner abgefangen
Online Banking
Probleme:
• R kommt nicht von Bank
• R wird durch Gegner abgefangen
Lösung: Verwende sicheren Offline-Transfer
(persönliche Abholung, Brief)
Weitere Probleme:
• Phishing Attacken auf Kunde
• Kunde möchte von beliebigem Rechner Zugriff
Online Banking
Phishing Attacke auf Kunde:
Bank
Kunde
R
R‘
Angreifer
R’
Angreifer kann keinen Kontakt
zu R herstellen!
Online Banking
Phishing Attacke auf Kunde:
Bank
R‘
R
Angreifer
Kunde
R’
Bank akzeptiert nur Anfragen,
die bei R starten!
Online Banking
Zugriff über beliebigen Rechner:
Verwende z.B. USB-Stick mit Minirechner,
um Emulationsproblem zu umgehen?
Details noch zu klären…
Fragen?