Secret Handshakes

Einleitung

Secret Handshakes ermöglichen es die Mitgliedschaft in einer Gruppe zu authentifizieren und gleichzeitig die eigene Anonymität im Falle des Misserfolgs sicherzustellen. In der Praxis stellen sie eine Erweiterung des SSL- bzw. TLS-Handshakes dar, der lediglich dazu dient einen Session Key für eine gesicherte Kommunikation auszuhandlen.

Secret Handshakes sollen ein geeignetes Mittel darstellen um Anonymität im Netzwerk/Internet sicherzustellen und die Privatsphäre von Personen und Institutionen zu schützen. Schon im üblichen Client-Server-Szenario können sie Anwendung finden um z.B. den Inhalt von Webservern vor Fremden zu verstecken und nur berechtigten Klienten Zutritt zu verschaffen.

Mathemathische Grundlagen

Um die nachfolgende Funktionsweise eines Secret Handshakes besser zu verstehen, gehen wir zunächst kurz auf die verwendeten mathematischen Konstrukte ein.

Gruppen

Eine Gruppe G(M, *) besteht aus einer Menge M und einer Verknüpfung *. Weiterhin ist in der Menge M das neutrale Element der Gruppe G enthalten. Ein Gruppe besitzt ein inverses Element. Abschließend ist die Verknüpfung einer Gruppe assoziativ.

Bei Secret Handshakes werden allerdings zyklische Gruppen verwendet.

zyklische Gruppen

Beispiel (zyklische) Gruppen

Eine endliche zyklische Gruppe G(M, *) heißt zyklisch, wenn die Menge M mindestens ein Element g mit der Eigenschaft M = {g¹, g², g³, ... , g^n} enthält. Man nennt g dann erzeugendes Element der Gruppe. n stellt die Ordnung der Gruppe dar. Gruppen mit einer primen Ordnung q sind immer zyklisch.

bilineare Abbildungen

Ein weiteres wichtiges Thema zum Verständnis der Secret Handshakes sind bilineare Abbildungen.

Eine Abbildung f: E x F → G nennt man bilinear, wenn folgenes gilt:

• für festes x: Die Abbildung f(x, ·): F → G ist linear.
• für festes y: Die Abbildung f(·, y): E → G ist linear.

speziell benötigte lineare Abbildung

das bilineare Diffie-Hellman-Problem

Bei den Secret Handshakes wird eine spezielle bilineare Abbildung ê: G_1 x G_1 → G_2 benötigt. Diese hat muss folgende Eigenschaften besitzen:

• G_1 und G_2 sind zyklische Gruppen mit der Primordnung q
• für alle a, b Element aus Z_q gilt: ê(aP, bQ) = ê(P, Q)^ab

Z_q soll hier für einen Restklassenring stehen.

Modifizierte Weil- und Tate-Paarungen über supersinguläre [elliptische Kurven] sind Beispiele für solche bilineare Abbildungen. Diese sind effizient berechenbar, nicht degenerativ und das bilineare Diffie-Hellman-Problem gilt für sie als schwer berechenbar.

Hashfunktionen

Für die Umsetzung der Secret Handshakes werden nun noch zwei Hashfunktionen benötigt.

erste Hashfunktion: H_1: {0,1}* → G_1

• Abbildung beliebiger Zeichenketten auf die zyklische Gruppe G_1

zweite Hashfunktion: H_2: {0,1}* → {0,1}*

• Abbildung beliebiger Zeichenketten auf Zeichenketten fester Länge
• kollisionsresistent
• z. B. SHA-1

Allgemeines Prinzip

Zunächst erhält jede der beiden Kommunikationsparteien von einem Gruppenadministrator Zugangsdatenvon für eine Gruppe in Form eines Zweier-Tupels bestehend aus einem Pseudonym und einem Secret Point aus $G_{1}$. Jede Gruppe besitzt eines Master-Secret $s_{G}\in Z_{q}$. Von den Pseudonymen darf nicht auf eine Kommunikationspartei geschlossen werden können.

Beispiel:

Alice' Daten: $('p65748392a',priv_{A}\in G_{1})$

Pseudonym: $'p65748392a'\,\!$

Secret Point: $priv_{A}=s_{G}\cdot H_{1}('p65748392a')$

Bobs Daten: $('xy6542678d',priv_{B}\in G_{1})$

Pseudonym: $'xy6542678d'\,\!$

Secret Point: $priv_{B}=s_{G}\cdot H_{1}('xy6542678d')$

Bei einem Secret Handshakes tauschen Alice und Bob ihre Pseudonyme aus und berechnen mit Hilfe des erhaltenen Pseudonyms des anderen einen Sitzungsschlüssel.

Alice: $K_{A}={\hat {e}}(H_{1}('xy6542678d'),priv_{A})$

Bob: $K_{B}={\hat {e}}(priv_{B},H_{1}('p65748392a'))$

Stimmen diese beiden Sitzungsschlüssel überein, so wissen Alice und Bob, dass sie der selben Gruppe angehören.

$K_{A}={\hat {e}}(H_{1}('xy6542678d'),priv_{A})$

$={\hat {e}}(H_{1}('xy6542678d'),s_{G}\cdot H_{1}('p65748392a'))$

$={\hat {e}}(H_{1}('xy6542678d'),H_{1}('p65748392a'))^{s_{G}}$

$={\hat {e}}(s_{G}\cdot H_{1}('xy6542678d'),H_{1}('p65748392a')$

$={\hat {e}}(priv_{B},H_{1}('p65748392a'))=K_{B}$

Stimmen diese Schlüssel nicht überein, so hat weder Alice noch Bob etwas über die Gruppenzugehörigkeit des jeweils anderen gelernt. Damit eine Zuordnung von Pseudonymen zu Nutzern durch einen potenziellen Beobachter nicht möglich ist, erhält jedes Mitglied einer Gruppe sogar eine ganze Liste der erwähnten Zweier-Tupel. So kann für jeden Handshake ein neues Paar benutzt werden.

Pairing Based Handshake Schema

Das Pairing Based Handshake Schema (PBH) wird durch die folgenden 5 Funktionen definiert.

$U$ Menge von möglichen Nutzern

$G$ Menge von Gruppen

$A$ Menge von Administratoren

$PBH.CreateGroup:~G\to (0,1)^{{}*{}}$

• wird von einem Administrator aus $A$ ausgeführt
• Ausgabe ist ein zufälliges Master Secret $s_{G}$ aus $Z_{q}$ für eine Gruppe aus $G$

$PBH.AddUser:~U\times G\times (0,1)^{{}*{}}\to (0,1)^{{}*{}}$

• wird von einem Administrator aus $A$ ausgeführt
• Eingabe: Nutzer, Gruppe, Master Secret $S_{G}$ der Gruppe
• generiert eine Liste von Pseudonymen $id_{U1},\ldots ,id_{Ut}\in (0,1)^{{}*{}}$ (Anzahl der geplanten Handshakes)
• generiert eine Liste von Secret Points passend zu den Pseudonymen $priv_{Ui}=s_{g}\cdot H_{1}(id_{Ui})$

$PBH.TraceUser:~(0,1)^{{}*{}}\to U$

• wird von einem Administrator aus $A$ ausgeführt
• wertet Mitschrift eines Handshakes aus
• Er kann als einziger den verwendeten Pseudonymen die wirklichen Nutzer zuordnen.

$PBH.RemoveUser:~(0,1)^{{}*{}}\times U\to (0,1)^{{}*{}}$

• entfernt einen Nutzer aus einer Gruppe
• wird von einem Administrator aus $A$ ausgeführt
• Der Administrator schlägt alle an diesen Nutzer ausgehändigten Pseudonyme nach.
• fügt diese der RevokedUserList hinzu
• überreicht allen verbleibenden Nutzern diese neue Liste

$PBH.Handshake(A,B)\,\!$

• der eigentliche Handshake

Ablauf im Detail

Der gesamte Handshake besteht im wesentlichen aus 3 Schritten.

Am Anfang besteht (irgendwie) eine ungesicherte Verbindung zwischen den beiden, die den Handshake ausführen wollen.

Alice beginnt nun indem sie eines ihrer Pseudonyme $id_{A}$ auswählt und dies zusammen mit einer zufälligen Zahl $rand_{A}$ an Bob übermittelt. (Schritt 1)

Bob generiert nun seinerseits eine zufällige Zahl $rand_{B}$ und berechnet zusammen mit einem seiner eigenen Pseudonyme $id_{B}$ und dem dazugehörigen Secret Point $priv_{B}$ die Zahl

$V_{1}=H_{2}({\hat {e}}(H_{1}(id_{A}),priv_{B})||id_{A}||id_{B}||rand_{A}||rand_{B}||0)\,\!$

Diese Zahl schickt er nun zusammen mit seinem Pseudonym und der zufälligen Zahl an Alice. (Schritt 2)

Alice kann jetzt mit Hilfe von $V_{1}$ und ihres eigenen Secret Points die Gruppenzugehörigkeit von Bob überprüfen indem sie noch einmal

$V_{1}=H_{2}({\hat {e}}(priv_{A},H_{1}(id_{B}))||id_{A}||id_{B}||rand_{A}||rand_{B}||0)\,\!$

berechnet und mit dem von Bob erhaltenen Wert vergleicht. (Man sieht, dass Fairness nicht garantiert wird, da Alice den Handshake hier bei einem Misserfolg vorzeitig abbrechen könnte und in diesem Fall schon mehr wüsste als Bob.) Im Folgenden berechnet Alice nun noch

$V_{2}=H_{2}({\hat {e}}(priv_{A},H_{1}(id_{B}))||id_{A}||id_{B}||rand_{A}||rand_{B}||1)\,\!$

und sendet diesen Wert an Bob. (Schritt 3)

Bob kann nun mit diesem Wert die analoge Überprüfung wie Alice vorher mit $V_{1}$ durchführen. Entweder schlagen beide Tests fehl oder beide sind erfolgreich. Im Falle des Erfolgs können nun beide für sich einen Session Key für die weitere Kommunikation aushandeln ohne ihn extra austauschen zu müssen (die gleiche Vorschrift ist natürlich nötig). Eine Möglichkeit wäre:

$S=H_{2}({\hat {e}}(priv_{A},H_{1}(id_{B}))||id_{A}||id_{B}||rand_{A}||rand_{B}||2)\,\!$ (für Alice - analog für Bob)

Sicherheit gegen Abhören

Ein potenzieller Beobachter kann nur in Erfahrung bringen, welche Pseudonyme ausgetascht wurden. ($id_{A},~id_{B}$)

Sollte in einem sehr unwahrscheinlichen Fall die Hashfunktion "geknackt" worden sein, kann der Beobachter theoretisch Wissen darüber erlangen, welcher Sitzungsschlüssel aktuell verwendet wird. ($id_{A},~id_{B},~{\hat {e}}(H_{1}(id_{A}),priv_{B}),~{\hat {e}}(priv_{A},H_{1}(id_{B}))$)

Aber:

${\hat {e}}(H_{1}(id_{A}),H_{1}(id_{B}))^{S_{G}}~mod~q~=~{\hat {e}}(H_{1}(id_{A}),H_{1}(id_{B}))^{S_{G}}$

Dies stellt das Problem des diskreten Logarithmus dar, welches als schwer lösbar gilt. Somit bleibt das Master Secret $s_{G}$ der Gruppe auf jeden Fall geheim.

Zusätzliche Eigenschaften

Vom vorgestellten Schema sind folgende Eigenschaften bereits umgesetzt: Forward Repudiability, Indistinguishability to Eavesdroppers, Unlinkability, Collusion Resistance und Traceability.

Forward Repudiability

Es ist trotz eines erfolgreichen Handshakes nicht möglich die Gruppenmitgliedschaft des anderen Teilnehmers nachzuweisen selbst wenn die eigenen Geheimnisse (die Secret Points) veröffentlicht werden. Der Grund dafür ist, dass ein Protokoll eines erfolgreichen Handshakes allein mit diesen Informationen generiert werden könnte, so dass dieses Protokoll keinen Beweis darstellen kann.

Indistinguishability to Eavesdroppers

Das Beobachten eines Handshakes gibt keinerlei Auskunft über die Gruppenmitgliedschaften der Beteiligten oder über den Erfolg des Handshakes. (Der Umstand weiter Kommunikation nach dem Handshakes könnte dies allerdings zunichte machen.)

Unlinkability

Die Nutzung von Listen von Pseudonymen für jeden einzelnen Nutzer macht es unmöglich, dass ein Beobachter anhand zweier (oder mehrerer) Handshakes feststellen kann, ob die gleichen Nutzer beteiligt waren. Listen von Pseudonymen erhöhen allerdings den Aufwand und könnten somit auf Grund von Performanceverbesserungen zu Lasten der Sicherheit aufgegeben werden. (Die Verwaltung von Revocation-Listen wird so wesentlich leichter.)

Collusion Resistance und Traceability

Selbst wenn eine Menge von Nutzern die eigenen Geheimnisse untereinander austauscht, bleibt das System sicher. Um das Gruppengeheimnis aus den Geheimnissen der Menge zu berechnen wäre es wiederum nötig das bilineare Diffie-Hellman-Problem zu lösen. (Collusion Resistance) Wenn andere Nutzer durch die Menge der konspirativen Nutzer korrumpiert werden, kann wenigestens einer aus dieser Menge festgestellt und anhand seiner benutzten Pseudonyme verfolgt werden. (Traitor tracing)

Rollen

Als weitere Eigenschaft sind verschiedene Rollen innerhalb der Gruppen vorstellbar. Dazu muss während der Authentifizierung nur das Pseudonym des Gegenübers mit der Rolle, die man von ihm erwartet, konkateniert werden. Der weitere Verlauf ist analog. Desweiteren sind nun natürlich alle Secret Points abhängig von Pseudonym und Rolle.

Anpassung des TLS Handshakes

Um Secret Handshakes zu implementieren, muss der normale TLS-Handshake nur minimal angepasst werden.

• Austausch der Zufallszahlen $rand_{A}$ und $rand_{B}$ über ClientHello und ServerHello (keine Anpassung)
• Austausch der Pseudonyme $id_{A}$ und $id_{B}$ über ServerKeyExchange über ClientKeyExchange (Anpassung notwendig)
• Verwendung des gemeinsamen PBH-Sitzungsschlüssels als TLS PreMaster Secret
• Übertragung der Zahlen $V_{1}$ und $V_{2}$ über die jeweiligen Finished Nachrichten (keine Anpassung)

Quellen

• Secret Handshakes from Pairing-Based Key Agreements (2003) Dirk Balfanz, Glenn Durfee, Narendar Shankar, Diana Smetters, Jessica Staddon, Hao-Chi Wong. [1]