Secret Handshakes: Difference between revisions
No edit summary |
|||
(37 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== 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 <math>G(M, *)</math> besteht aus einer Menge <math>M</math> und einer Verknüpfung <math>*</math>. Weiterhin ist in der Menge <math>M</math> das neutrale Element der Gruppe <math>G</math> 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 === |
|||
[[Image:Secret_Handshakes_Zyklische_Gruppen.png|thumb|Beispiel (zyklische) Gruppen]] |
|||
Eine endliche zyklische Gruppe <math>G(M, *)</math> heißt zyklisch, wenn die Menge <math>M</math> mindestens ein Element <math>g</math> mit der Eigenschaft <math>M = \{g^1, g^2, g^3, ... , g^n\}</math> enthält. |
|||
Man nennt <math>g</math> dann erzeugendes Element der Gruppe. <math>n</math> stellt die Ordnung der Gruppe dar. Gruppen mit einer primen Ordnung <math>q</math> sind immer zyklisch. |
|||
=== bilineare Abbildungen === |
|||
Ein weiteres wichtiges Thema zum Verständnis der Secret Handshakes sind bilineare Abbildungen. |
|||
Eine Abbildung <math>f:~E \times F \to G</math> nennt man bilinear, wenn folgenes gilt: |
|||
* für festes <math>x\,\!</math>: Die Abbildung <math>f(x, \cdot):~F \to G</math> ist linear. |
|||
* für festes <math>y\,\!</math>: Die Abbildung <math>f(\cdot, y):~E \to G</math> ist linear. |
|||
=== speziell benötigte lineare Abbildung === |
|||
[[Image:Secret_Handshakes_Bilineares_Diffie_Hellman_Problem.png|thumb|das bilineare Diffie-Hellman-Problem]] |
|||
Bei den Secret Handshakes wird eine spezielle bilineare Abbildung <math>\hat e:~G_1 \times G_1 \to G_2</math> benötigt. Diese muss folgende Eigenschaften besitzen: |
|||
* <math>G_1</math> und <math>G_2</math> sind zyklische Gruppen mit der Primordnung <math>q</math>. |
|||
* <math>\forall a, b \in Z_q:~\hat e(aP, bQ) = \hat e(P, Q)^{ab}</math> |
|||
<math>Z_q</math> soll hier für einen Restklassenring stehen. |
|||
Modifizierte [[Weil]]- und [[Tate]]-Paarungen über supersinguläre [[elliptische Kurven]] sind Beispiele für solche bilinearen 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 [[Hashfunktion]]en benötigt. |
|||
erste [[Hashfunktion]]: <math>H_1:~\{0,1\}^* \to G_1</math> |
|||
* Abbildung beliebiger Zeichenketten auf die zyklische Gruppe <math>G_1</math> |
|||
zweite [[Hashfunktion]]: <math>H_2:~\{0,1\}^* \to \{0,1\}^*</math> |
|||
* Abbildung beliebiger Zeichenketten auf Zeichenketten fester Länge |
|||
* kollisionsresistent |
|||
* z. B. SHA-1 |
|||
== Allgemeines Prinzip == |
== 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 <math>G_1</math>. Jede Gruppe besitzt ein Master-Secret <math>s_G \in Z_q</math>. Von den Pseudonymen darf nicht auf eine Kommunikationspartei geschlossen werden können. |
|||
[TODO] |
|||
Beispiel: |
|||
Alice' Daten: <math>('p65748392a', priv_A \in G_1)</math> |
|||
Pseudonym: <math>'p65748392a'\,\!</math> |
|||
Secret Point: <math>priv_A = s_G \cdot H_1('p65748392a')</math> |
|||
Bobs Daten: <math>('xy6542678d', priv_B \in G_1)</math> |
|||
Pseudonym: <math>'xy6542678d'\,\!</math> |
|||
Secret Point: <math>priv_B = s_G \cdot H_1('xy6542678d')</math> |
|||
Bei einem Secret Handshakes tauschen Alice und Bob ihre Pseudonyme aus und berechnen mit Hilfe des erhaltenen Pseudonyms des anderen einen Sitzungsschlüssel. |
|||
Alice: <math>K_A = \hat e (H_1('xy6542678d'), priv_A)</math> |
|||
Bob: <math>K_B = \hat e (priv_B,H_1('p65748392a'))</math> |
|||
Stimmen diese beiden Sitzungsschlüssel überein, so wissen Alice und Bob, dass sie der selben Gruppe angehören. |
|||
<math>K_A = \hat e (H_1('xy6542678d'), priv_A)</math> |
|||
<math>= \hat e (H_1('xy6542678d'), s_G \cdot H_1('p65748392a'))</math> |
|||
<math>= \hat e (H_1('xy6542678d'), H_1('p65748392a'))^{s_G}</math> |
|||
<math>= \hat e (s_G \cdot H_1('xy6542678d'), H_1('p65748392a')</math> |
|||
<math>= \hat e (priv_B,H_1('p65748392a')) = K_B</math> |
|||
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 == |
== Pairing Based Handshake Schema == |
||
Das Pairing Based Handshake Schema (PBH) wird durch die folgenden 5 Funktionen definiert. |
|||
[TODO] |
|||
<math>U</math> Menge von möglichen Nutzern |
|||
<math>G</math> Menge von Gruppen |
|||
<math>A</math> Menge von Administratoren |
|||
<math>PBH.CreateGroup:~G \to (0,1)^{{}*{}}</math> |
|||
* wird von einem Administrator aus <math>A</math> ausgeführt |
|||
* Ausgabe ist ein zufälliges Master Secret <math>s_G</math> aus <math>Z_q</math> für eine Gruppe aus <math>G</math> |
|||
<math>PBH.AddUser:~U \times G \times (0,1)^{{}*{}} \to (0,1)^{{}*{}}</math> |
|||
* wird von einem Administrator aus <math>A</math> ausgeführt |
|||
* Eingabe: Nutzer, Gruppe, Master Secret <math>S_G</math> der Gruppe |
|||
* generiert eine Liste von Pseudonymen <math>id_{U1}, \ldots, id_{Ut} \in (0,1)^{{}*{}}</math> (Anzahl der geplanten Handshakes) |
|||
* generiert eine Liste von Secret Points passend zu den Pseudonymen <math>priv_{Ui} = s_g \cdot H_1(id_{Ui})</math> |
|||
<math>PBH.TraceUser:~(0,1)^{{}*{}} \to U</math> |
|||
* wird von einem Administrator aus <math>A</math> ausgeführt |
|||
* wertet Mitschrift eines Handshakes aus |
|||
* Er kann als einziger den verwendeten Pseudonymen die wirklichen Nutzer zuordnen. |
|||
<math>PBH.RemoveUser:~(0,1) ^{{}*{}} \times U \to (0,1)^{{}*{}}</math> |
|||
* entfernt einen Nutzer aus einer Gruppe |
|||
* wird von einem Administrator aus <math>A</math> 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 |
|||
<math>PBH.Handshake(A,B)\,\!</math> |
|||
* der eigentliche Handshake |
|||
== Ablauf im Detail == |
== Ablauf im Detail == |
||
[[Image:Ausgangssituation.jpg|thumb]] |
|||
[TODO] |
|||
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 <math>id_A</math> auswählt und dies zusammen mit einer zufälligen Zahl <math>rand_A</math> an Bob übermittelt. (Schritt 1) |
|||
[[Image:Ablauf.jpg|thumb]] |
|||
Bob generiert nun seinerseits eine zufällige Zahl <math>rand_B</math> und berechnet zusammen mit einem seiner eigenen Pseudonyme <math>id_B</math> und dem dazugehörigen Secret Point <math>priv_B</math> die Zahl |
|||
:<math>V_1 = H_2 ( \hat e ( H_1 ( id_A ), priv_B ) || id_A || id_B || rand_A || rand_B || 0)\,\!</math> |
|||
Diese Zahl schickt er nun zusammen mit seinem Pseudonym und der zufälligen Zahl an Alice. (Schritt 2) |
|||
Alice kann jetzt mit Hilfe von <math>V_1</math> und ihres eigenen Secret Points die Gruppenzugehörigkeit von Bob überprüfen indem sie noch einmal |
|||
:<math>V_1 = H_2( \hat e(priv_A,H_1(id_B)) || id_A || id_B || rand_A || rand_B || 0)\,\!</math> |
|||
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 |
|||
:<math>V_2 = H_2(\hat e(priv_A,H_1(id_B)) || id_A || id_B || rand_A || rand_B || 1)\,\!</math> |
|||
und sendet diesen Wert an Bob. (Schritt 3) |
|||
Bob kann nun mit diesem Wert die analoge Überprüfung wie Alice vorher mit <math>V_1</math> 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: |
|||
:<math>S = H_2(\hat e(priv_A,H_1(id_B)) || id_A || id_B || rand_A || rand_B || 2)\,\!</math> (für Alice - analog für Bob) |
|||
== Sicherheit gegen Abhören == |
== Sicherheit gegen Abhören == |
||
Ein potenzieller Beobachter kann nur in Erfahrung bringen, welche Pseudonyme ausgetascht wurden. (<math>id_A,~id_B</math>) |
|||
[TODO] |
|||
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. (<math>id_A,~id_B,~\hat e(H_1(id_A), priv_B),~\hat e(priv_A, H_1(id_B))</math>) |
|||
'''Aber:''' |
|||
<math>\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}</math> |
|||
Dies stellt das Problem des diskreten Logarithmus dar, welches als schwer lösbar gilt. Somit bleibt das Master Secret <math>s_G</math> der Gruppe auf jeden Fall geheim. |
|||
== Zusätzliche Eigenschaften == |
== Zusätzliche Eigenschaften == |
||
Vom vorgestellten Schema sind folgende Eigenschaften bereits umgesetzt: Forward Repudiability, Indistinguishability to Eavesdroppers, Unlinkability, Collusion Resistance und Traceability. |
|||
[TODO] |
|||
=== 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 weiterer 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 == |
== Anpassung des TLS Handshakes == |
||
[[Image:Secret_Handshakes_TLS_Anpassung.png|thumb]] |
|||
[TODO] |
|||
Um Secret Handshakes zu implementieren, muss der normale TLS-Handshake nur minimal angepasst werden. |
|||
* Austausch der Zufallszahlen <math>rand_A</math> und <math>rand_B</math> über ''ClientHello'' und ''ServerHello'' (keine Anpassung) |
|||
* Austausch der Pseudonyme <math>id_A</math> und <math>id_B</math> über ''ServerKeyExchange'' über ''ClientKeyExchange'' (Anpassung notwendig) |
|||
* Verwendung des gemeinsamen PBH-Sitzungsschlüssels als TLS PreMaster Secret |
|||
* Übertragung der Zahlen <math>V_1</math> und <math>V_2</math> über die jeweiligen ''Finished'' Nachrichten (keine Anpassung) |
|||
== Quellen == |
|||
== Beweisskizze für die formale Sicherheit == |
|||
* '''Secret Handshakes from Pairing-Based Key Agreements (2003)''' Dirk Balfanz, Glenn Durfee, Narendar Shankar, Diana Smetters, Jessica Staddon, Hao-Chi Wong. [http://www.parc.com/csl/members/balfanz/publications/handshakes.pdf] |
|||
[TODO] |
Latest revision as of 11:13, 12 September 2007
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 besteht aus einer Menge und einer Verknüpfung . Weiterhin ist in der Menge das neutrale Element der Gruppe 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
Eine endliche zyklische Gruppe heißt zyklisch, wenn die Menge mindestens ein Element mit der Eigenschaft enthält. Man nennt dann erzeugendes Element der Gruppe. stellt die Ordnung der Gruppe dar. Gruppen mit einer primen Ordnung sind immer zyklisch.
bilineare Abbildungen
Ein weiteres wichtiges Thema zum Verständnis der Secret Handshakes sind bilineare Abbildungen.
Eine Abbildung nennt man bilinear, wenn folgenes gilt:
- für festes : Die Abbildung ist linear.
- für festes : Die Abbildung ist linear.
speziell benötigte lineare Abbildung
Bei den Secret Handshakes wird eine spezielle bilineare Abbildung benötigt. Diese muss folgende Eigenschaften besitzen:
- und sind zyklische Gruppen mit der Primordnung .
soll hier für einen Restklassenring stehen.
Modifizierte Weil- und Tate-Paarungen über supersinguläre elliptische Kurven sind Beispiele für solche bilinearen 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:
- Abbildung beliebiger Zeichenketten auf die zyklische Gruppe
zweite Hashfunktion:
- 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 . Jede Gruppe besitzt ein Master-Secret . Von den Pseudonymen darf nicht auf eine Kommunikationspartei geschlossen werden können.
Beispiel:
Alice' Daten:
Pseudonym:
Secret Point:
Bobs Daten:
Pseudonym:
Secret Point:
Bei einem Secret Handshakes tauschen Alice und Bob ihre Pseudonyme aus und berechnen mit Hilfe des erhaltenen Pseudonyms des anderen einen Sitzungsschlüssel.
Alice:
Bob:
Stimmen diese beiden Sitzungsschlüssel überein, so wissen Alice und Bob, dass sie der selben Gruppe angehören.
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.
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
- 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
- wird von einem Administrator aus ausgeführt
- wertet Mitschrift eines Handshakes aus
- Er kann als einziger den verwendeten Pseudonymen die wirklichen Nutzer zuordnen.
- entfernt einen Nutzer aus einer Gruppe
- wird von einem Administrator aus 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
- 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 auswählt und dies zusammen mit einer zufälligen Zahl an Bob übermittelt. (Schritt 1)
Bob generiert nun seinerseits eine zufällige Zahl und berechnet zusammen mit einem seiner eigenen Pseudonyme und dem dazugehörigen Secret Point die Zahl
Diese Zahl schickt er nun zusammen mit seinem Pseudonym und der zufälligen Zahl an Alice. (Schritt 2)
Alice kann jetzt mit Hilfe von und ihres eigenen Secret Points die Gruppenzugehörigkeit von Bob überprüfen indem sie noch einmal
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
und sendet diesen Wert an Bob. (Schritt 3)
Bob kann nun mit diesem Wert die analoge Überprüfung wie Alice vorher mit 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:
- (für Alice - analog für Bob)
Sicherheit gegen Abhören
Ein potenzieller Beobachter kann nur in Erfahrung bringen, welche Pseudonyme ausgetascht wurden. ()
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. ()
Aber:
Dies stellt das Problem des diskreten Logarithmus dar, welches als schwer lösbar gilt. Somit bleibt das Master Secret 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 weiterer 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 und über ClientHello und ServerHello (keine Anpassung)
- Austausch der Pseudonyme und über ServerKeyExchange über ClientKeyExchange (Anpassung notwendig)
- Verwendung des gemeinsamen PBH-Sitzungsschlüssels als TLS PreMaster Secret
- Übertragung der Zahlen und ü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]