Systems Architecture Secret Handshakes Erik Neumann, Daniel Uhlig

2 May Systems Architecture Gliederung  Autoren  Einleitung  Mathematische Grundlagen  Allgemeines Prinzip  Pairing Based Handshake Schema (PBH)  Ablauf im Detail  Sicherheit gegen Abhören  Zusätzliche Eigenschaften ➔ Rollenauthentifizierung  Anpassung des TLS Handshakes  Beweisskizze für die formale Sicherheit

3 May Systems Architecture 1. Autoren  Glenn Durfee, Narendar Shankar, Diana Smetters, Jessica Staddon, Hao-Chi Wong  Dirk Balfanz - ehemaliger Mitarbeiter beim SAR-Lehrstuhl Das Paper entstand in Zusammenarbeit der Autoren am Palo Alto Research Center (PARC).

4 May Systems Architecture 2. Einleitung  Was sind Secret Handshakes? - Authentifizierung einer Gruppenmitgliedschaft - Anonymität im Falle des Misserfolgs - endgültiges Ziel: Session Key aushandeln - Anpassung des SSL/TLS Handshakes  Warum sind sie interessant? - Anonymität im Internet wird immer wichtiger - illegale Szenarien liegen nahe - politische Verfolgung / staatl. Überwachung - Schutz der Privatsphäre - auch übliches Client-Server-Szenario

5 May Systems Architecture 3. Gruppen  Gruppe - besteht aus einer Menge und einer Verknüpfung -besitzt ein neutrales Element -besitzt ein inverses Element zu jedem -Verknüpfung ist assoziativ  zyklische Gruppe - Eine endliche Gruppe mit Elementen heißt zyklisch, wenn es ein Element gibt mit der Eigenschaft heißt dann erzeugendes Element der Gruppe. - stellt die Ordnung der Gruppe dar -Gruppen mit einer primen Ordnung sind immer zyklisch.

6 May Systems Architecture 3. zyklische Gruppen - Beispiele

7 May Systems Architecture 3. bilineare Abbildungen Abbildung: mit der Eigenschaft:

8 May Systems Architecture 3. benötigte bilineare Abbildung bilineare Abbildung: mit der Eigenschaft: und Modifizierte Weil - und Tate - Paarungen über supersinguläre elliptische Kurven: effizient berechenbar nicht degenerativ bilineares Diffie-Hellman Problem gilt als schwer berechenbar schwer berechenbar

9 May Systems Architecture 3. Hashfunktion von Zeichenketten nach Punkten in z.B. ASCII Werte + Mod Operation kollisionsresistent von Zeichenketten nach Zeichenketten in fester Länge z. B. SHA-1

10 May Systems Architecture 4. Allgemeines Prinzip (1) pro Gruppe: Master Secret Alice' Daten: Pseudonym: Secret Point: Bobs Daten: Pseudonym: Secret Point:  Initiale Daten:

11 May Systems Architecture 4. Allgemeines Prinzip (2)  Austausch der Pseudonyme:

12 May Systems Architecture 4. Allgemeines Prinzip (3)  Berechnung des Sitzungsschlüssels:

13 May Systems Architecture 5. Pairing Based Handshake Schema (PBH) Menge von möglichen Nutzern Menge von Gruppen Menge von Administratoren wird von einem Administrator aus ausgeführt Ausgabe ist ein zufälliges Master Secret aus für eine Gruppe aus

14 May Systems Architecture 5. Pairing Based Handshake Schema (PBH) Menge von möglichen Nutzern Menge von Gruppen Menge von Administratoren wird von einem Administrator aus ausgeführt Eingabe: Nutzer, Gruppe, Master Secret der Gruppe generiert eine Liste von Pseudonymen (Anzahl der geplanten Handshakes) generiert eine Liste von Secret Points passend zu den Pseudonymen

15 May Systems Architecture 5. Pairing Based Handshake Schema (PBH) Menge von möglichen Nutzern Menge von Gruppen Menge von Administratoren wird von einem Administrator aus ausgeführt wertet Mitschrift eines Handshakes aus Er kann als einziger den verwendeten Pseudonymen die wirklichen Nutzer zuordnen.

16 May Systems Architecture 5. Pairing Based Handshake Schema (PBH) Menge von möglichen Nutzern Menge von Gruppen Menge von Administratoren wird von einem Administrator aus ausgeführt schlägt alle an diesen Nutzer ausgehändigten Pseudonyme nach fügt diese der RevokedUserList hinzu überreicht allen verbleibenden Nutzern diese neue Liste der eigentliche Handshake

17 May Systems Architecture 6. Ablauf (1) Alic e Bo b W W W Initiale Verbindung kommt irgendwie zustande... Mitglied in G1 Mitglied in G2 Ziel: Feststellen ob G1 == G2

18 May Systems Architecture 6. Ablauf (2) Alic e Mitglied in G1 Bo b Mitglied in G2 : ein Pseudonym von Alice : eine von Alice generierte Zufallszahl

19 May Systems Architecture 6. Ablauf (3) Alic e Mitglied in G1 Bo b Mitglied in G2  Bob generiert seinerseits  und berechnet nun:

20 May Systems Architecture 6. Ablauf (4) Alic e Mitglied in G1 Bo b Mitglied in G2  Alice verifiziert durch Berechnung von Alic e Mitglied in G1 Bo b Mitglied in G2  und berechnet nun

21 May Systems Architecture 6. Ablauf (5)  Bob verifiziert durch Berechnung von  jetzt kann er den Session Key S berechnen Alic e Mitglied in G1 Bo b Mitglied in G2

22 May Systems Architecture 6. Ablauf (6)  Bob und Alice haben jetzt jeweils den Session Key, falls die Verifikation von und erfolgreich war  G1==G2  bei nicht erfolgreicher Verifikation waren zumindest die für Kommunikation gewünschten Gruppen nicht gleich  möglicherweise sind Alice und Bob in der gleichen Gruppe, wollten aber mit verschiedenen in Interaktion treten  das shared secret wäre unterschiedlich und der erfolgreiche Handshake dadurch unmöglich

23 May Systems Architecture 7. Was weiß ein potentieller Beobachter? wenn die Hashfunktion 'geknackt' worden sein sollte: Sitzungsschlüssel Aber: Problem des diskreten Logarithmus Master Secret der Gruppe bleibt geheim

24 May Systems Architecture 8. Zusätzliche Eigenschaften  traceability ➔ Verfolgung von Eindringlingen ist möglich  forward repudiability ➔ Abstreitbarkeit der Gruppenmitgliedschaft  indistinguishability to eavesdroppers ➔ Beobachter lernen nichts aus den Handshakes  collusion resistance ➔ Eindringlinge zerstören nicht die Sicherheit des Systems  unlinkability ➔ Handshakes eines User sind von anderen nicht unterscheidbar  verschiedene Rollen in den einzelnen Gruppen ➔ angepasste Authentifizierung

25 May Systems Architecture 8. Rollenauthentifizierung  nur eine geringfügige Anpassung des Handshakes ist notwendig  die AddUser-Methode erzeugt nun Listen von Pseudonym/secret point – Paaren, wobei der secret point nun auch von der Rolle abhängig ist  bei den Berechnungen von, und wird die vom jeweiligen User gewünschte Rolle des Gegenübers an das erhaltene Pseudonym angehängt  Die Rollen werden nicht explizit übertragen!  Probleme?

26 May Systems Architecture 9. Anpassung des TLS Handshakes ClientHello ServerHello ServerKeyExchange ServerHelloDone ClientKeyExchange TLS PreMaster Secret TLS Master Secret ChangeCipherSpec Finished ChangeCipherSpec Finished

27 May Systems Architecture Beweisskizze für die formale Sicherheit  Def. GetPair (Spiel): - Step 1: Der Angreifer kann mit beliebigen Personen interagieren und korrumpiert dabei eine Menge U' von Personen, d.h. er erhält ihre Pseudonyme und secret points. - Step 2: Der Angreifer sucht sich eine Person U* aus (U* ist nicht in U'). - Step 3: Der Angreifer gibt auf Eingabe das Paar aus, wobei nicht in der Menge der erhaltenen Pseudonyme aus Step 1 sein darf.  Lemma: Für einen probabilistischen, polynomiellen Angreifer A, gibt es einen probabilistischen, polynomiellen Algorithmus B, so dass folgendes gilt :

28 May Systems Architecture Beweisskizze für die formale Sicherheit (2)  Beweisskizze: - B erhält eine Instanz des BDH-Problems (P, aP, bP, cP) - eine Umgebung für A für das GetPair-Spiel wird simuliert - die secret points der korrumpierten Personen aus Step 1 werden von bP, der secret point für wird von aP und der secret point von U* wird von cP abgeleitet - P wird benutzt um Hashwerte zu generieren - A muss nun mit Hilfe der erhaltenen Daten berechnen - B benutzt das erhaltene um das BDH-Problem zu lösen - B reduziert also das BDH-Problem auf das GetPair-Spiel - da A ein Algorithmus mit polynomieller Laufzeit ist, kann er das BDH- Problem unmöglich in angemessener Zeit lösen und damit hat er auch wenig Chancen das GetPair-Spiel zu gewinnen

29 May Systems Architecture Quellen  Secret Handshakes from Pairing-Based Key Agreements (Paper)  Peter Hartmann: Mathematik für Informatiker  Wikipedia