Systems Architecture Secret Handshakes Erik Neumann, Daniel Uhlig 22.05.2007.

Präsentation zum Thema: "Systems Architecture Secret Handshakes Erik Neumann, Daniel Uhlig 22.05.2007."—  Präsentation transkript:

1 Systems Architecture http://sar.informatik.hu-berlin.de Secret Handshakes Erik Neumann, Daniel Uhlig 22.05.2007

2 2 May 2006 - 2 Systems Architecture http://sar.informatik.hu-berlin.de 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 3 May 2006 - 3 Systems Architecture http://sar.informatik.hu-berlin.de 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 4 May 2006 - 4 Systems Architecture http://sar.informatik.hu-berlin.de 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 5 May 2006 - 5 Systems Architecture http://sar.informatik.hu-berlin.de 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 6 May 2006 - 6 Systems Architecture http://sar.informatik.hu-berlin.de 3. zyklische Gruppen - Beispiele

7 7 May 2006 - 7 Systems Architecture http://sar.informatik.hu-berlin.de 3. bilineare Abbildungen Abbildung: mit der Eigenschaft:

8 8 May 2006 - 8 Systems Architecture http://sar.informatik.hu-berlin.de 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 9 May 2006 - 9 Systems Architecture http://sar.informatik.hu-berlin.de 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 10 May 2006 - 10 Systems Architecture http://sar.informatik.hu-berlin.de 4. Allgemeines Prinzip (1) pro Gruppe: Master Secret Alice' Daten: Pseudonym: Secret Point: Bobs Daten: Pseudonym: Secret Point:  Initiale Daten:

11 11 May 2006 - 11 Systems Architecture http://sar.informatik.hu-berlin.de 4. Allgemeines Prinzip (2)  Austausch der Pseudonyme:

12 12 May 2006 - 12 Systems Architecture http://sar.informatik.hu-berlin.de 4. Allgemeines Prinzip (3)  Berechnung des Sitzungsschlüssels:

13 13 May 2006 - 13 Systems Architecture http://sar.informatik.hu-berlin.de 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 14 May 2006 - 14 Systems Architecture http://sar.informatik.hu-berlin.de 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 15 May 2006 - 15 Systems Architecture http://sar.informatik.hu-berlin.de 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 16 May 2006 - 16 Systems Architecture http://sar.informatik.hu-berlin.de 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 17 May 2006 - 17 Systems Architecture http://sar.informatik.hu-berlin.de 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 18 May 2006 - 18 Systems Architecture http://sar.informatik.hu-berlin.de 6. Ablauf (2) Alic e Mitglied in G1 Bo b Mitglied in G2 : ein Pseudonym von Alice : eine von Alice generierte Zufallszahl

19 19 May 2006 - 19 Systems Architecture http://sar.informatik.hu-berlin.de 6. Ablauf (3) Alic e Mitglied in G1 Bo b Mitglied in G2  Bob generiert seinerseits  und berechnet nun:

20 20 May 2006 - 20 Systems Architecture http://sar.informatik.hu-berlin.de 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 21 May 2006 - 21 Systems Architecture http://sar.informatik.hu-berlin.de 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 22 May 2006 - 22 Systems Architecture http://sar.informatik.hu-berlin.de 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 23 May 2006 - 23 Systems Architecture http://sar.informatik.hu-berlin.de 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 24 May 2006 - 24 Systems Architecture http://sar.informatik.hu-berlin.de 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 25 May 2006 - 25 Systems Architecture http://sar.informatik.hu-berlin.de 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 26 May 2006 - 26 Systems Architecture http://sar.informatik.hu-berlin.de 9. Anpassung des TLS Handshakes ClientHello ServerHello ServerKeyExchange ServerHelloDone ClientKeyExchange TLS PreMaster Secret TLS Master Secret ChangeCipherSpec Finished ChangeCipherSpec Finished

27 27 May 2006 - 27 Systems Architecture http://sar.informatik.hu-berlin.de 10. 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 28 May 2006 - 28 Systems Architecture http://sar.informatik.hu-berlin.de 10. 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 29 May 2006 - 29 Systems Architecture http://sar.informatik.hu-berlin.de Quellen  Secret Handshakes from Pairing-Based Key Agreements (Paper)  Peter Hartmann: Mathematik für Informatiker  Wikipedia