Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
306<br />
A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />
305<br />
A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />
8 Verteilte Berechnungsprotokolle<br />
7 Umrechenbare Autorisierungen<br />
(Credentials)<br />
Gegeben sei die sehr allgeme<strong>in</strong>e Aufgabe, daß n Teilnehmer Ti zusammen e<strong>in</strong>e Berechnung durchführen<br />
wollen. Jeder Teilnehmer soll se<strong>in</strong>en Input Ii zur Berechnung beitragen <strong>und</strong> am Schluß se<strong>in</strong>en<br />
Output Oi erhalten, der als Funktion fi aller Inputs spezifiziert ist. Folgende <strong>Sicherheit</strong>seigenschaften<br />
sollen erreicht werden:<br />
Größtmögliche Vertraulichkeit:<br />
Ke<strong>in</strong> Teilnehmer soll über Inputs von anderen Teilnehmern mehr erfahren, als er aus se<strong>in</strong>em<br />
Output schließen kann.<br />
Größtmögliche Integrität:<br />
Ke<strong>in</strong> Teilnehmer soll, nachdem er se<strong>in</strong>en Input gegeben hat, die Werte der Outputs bee<strong>in</strong>flussen<br />
können.<br />
Größtmögliche Verfügbarkeit:<br />
Ke<strong>in</strong> Teilnehmer soll, nachdem er se<strong>in</strong>en Input gegeben hat, e<strong>in</strong>em anderen Teilnehmer se<strong>in</strong>en<br />
Output vorenthalten können.<br />
E<strong>in</strong>e Übersicht für e<strong>in</strong>e umrechenbare Autorisierung wird <strong>in</strong> [Cha8_85, Chau_87] gegeben. Dort ist<br />
jeweils nicht erwähnt, daß wegen des geme<strong>in</strong>samen RSA-Modulus alle Organisationen die Credential-<br />
Signaturen nicht selbst leisten können, sondern von e<strong>in</strong>er Signaturorganisation leisten lassen müssen.<br />
Denn wer e<strong>in</strong> Paar zue<strong>in</strong>ander <strong>in</strong>verser RSA-Exponenten kennt, kann den Modulus faktorisieren<br />
[Hors_85 Seite 187, MeOV_97 Seite 287].<br />
In me<strong>in</strong>er Übersicht ist der Fall e<strong>in</strong>er festen <strong>und</strong> zu Beg<strong>in</strong>n bekannten Menge von Credentials<br />
beschrieben.<br />
E<strong>in</strong>e detaillierte Protokollbeschreibung ist <strong>in</strong> [Chau2_90] zu f<strong>in</strong>den.<br />
In [ChEv_87] ist beschrieben, wie die Prüfung, ob die Pseudonyme richtig gebildet s<strong>in</strong>d, so<br />
durchgeführt werden kann, daß die Wahrsche<strong>in</strong>lichkeit, daß unentdeckt falsche darunter s<strong>in</strong>d,<br />
exponentiell kle<strong>in</strong> im Prüfungsaufwand wird.<br />
In [Cha1_88] ist beschrieben, wie Credentials, die zu Beg<strong>in</strong>n nicht bekannt s<strong>in</strong>d, ausgestellt<br />
werden können.<br />
In [Bura_88] <strong>und</strong> [ChAn_90] s<strong>in</strong>d weitere Sorten umrechenbarer Autorisierungen beschrieben.<br />
Alle drei <strong>Sicherheit</strong>seigenschaften sollen auch gelten, wenn sich mehrere Teilnehmer zusammenschließen.<br />
Sie sollen dann nicht mehr erfahren, als was sie aus ihren geme<strong>in</strong>samen Outputs schließen<br />
können.<br />
Nachdem der letzte von ihnen se<strong>in</strong>en Input gegeben hat, sollen sie die Werte der Outputs nicht<br />
mehr bee<strong>in</strong>flussen <strong>und</strong> anderen nicht mehr vorenthalten können.<br />
Leider ist mir ke<strong>in</strong>e Anwendung dieser re<strong>in</strong> digitalen Identitäten bekannt. Denn es reicht nicht, daß<br />
z.B. die Autorisierung „Führersche<strong>in</strong>“ nur zwischen den Pseudonymen e<strong>in</strong>er Person umgerechnet<br />
werden kann. Die Autorisierung „Führersche<strong>in</strong>“ sollte auch nur das biologische Wesen nutzen<br />
können, das die Prüfung bestanden hat. Man muß das beschriebene Verfahren also für (fast?) alle<br />
Anwendungen so erweitern, daß <strong>in</strong> der Protokollphase „Pseudonyme vere<strong>in</strong>baren“, Pseudonyme an<br />
Körpermerkmale geb<strong>und</strong>en werden. Ob es untere<strong>in</strong>ander h<strong>in</strong>reichend nicht verkettbare, aber<br />
andererseits h<strong>in</strong>reichend genau meßbare Körpermerkmale gibt, ist e<strong>in</strong>e Frage außerhalb der<br />
Informatik. Gibt es sie, ist die Erweiterung der beschriebenen Protokolle kanonisch.<br />
E<strong>in</strong>e Erweiterung auf der Basis sicherer, d.h. unausforschbarer biometrischer Hardware, vgl.<br />
§6.2.1.2.2, die mit e<strong>in</strong>em h<strong>in</strong>reichend genau meßbaren Körpermerkmal auskommt, ist <strong>in</strong> [Bleu_99]<br />
beschrieben.<br />
Es gibt nun zwei gänzlich unterschiedliche Möglichkeiten, diese Aufgabe zu lösen:<br />
1. Alle Teilnehmer senden ihre Inputs an e<strong>in</strong>en zentralen Rechner, dem alle vertrauen (müssen).<br />
Dieser zentrale Rechner führt die Berechnungen durch <strong>und</strong> sendet jedem Teilnehmer se<strong>in</strong>en<br />
Output. Zwischen jedem Teilnehmer <strong>und</strong> dem zentralen Rechner sollte so verschlüsselt<br />
werden, daß Konzelation <strong>und</strong> Authentikation gewährleistet s<strong>in</strong>d, vgl. Bild 8-1. Vertraut<br />
man dieser Verschlüsselung <strong>und</strong> dem zentralen Rechner sowie der Verfügbarkeit des Kommunikationsnetzes,<br />
ist das gestellte Problem gelöst. Bzgl. der Verfügbarkeit <strong>und</strong> Integrität der<br />
Outputs kann man den zentralen Rechner zum<strong>in</strong>dest pr<strong>in</strong>zipiell im Nachh<strong>in</strong>e<strong>in</strong> kontrollieren,<br />
wenn alle Nachrichten digital signiert werden <strong>und</strong> e<strong>in</strong>e Zusammenarbeit von zentralem Rechner<br />
<strong>und</strong> Teilnehmern ausgeschlossen werden kann (sonst könnten sie sich im Nachh<strong>in</strong>e<strong>in</strong> die<br />
für ihre Handlungen nötigen digitalen Signaturen zuschanzen). Leider ist der zentrale Rechner<br />
bezüglich Vertraulichkeit nahezu unkontrollierbar, vgl. §1.2.2 <strong>und</strong> §2.1.<br />
2. Die Teilnehmer führen e<strong>in</strong> verteiltes Berechnungsprotokoll (Multi-Party Computation<br />
Protocol) durch, vgl. Bild 8-2. Bei solch e<strong>in</strong>em Protokoll gibt es ke<strong>in</strong>e zentrale Instanz, der<br />
alle vertrauen müssen. Aber auch hier ist, wenn auch realistischeres Vertrauen nötig:<br />
• Entweder muß darauf vertraut werden, daß e<strong>in</strong> Angreifer weniger als e<strong>in</strong> Drittel aller<br />
Teilnehmer umfaßt. Dann s<strong>in</strong>d <strong>in</strong>formationstheoretisch sichere verteilte Berechnungsprotokolle<br />
bekannt [BeGW_88, ChCD1_88].<br />
• Oder es muß mit e<strong>in</strong>er kryptographischen Annahme gearbeitet werden. Dann kann der<br />
Anteil des Angreifers an den Teilnehmern aber beliebig se<strong>in</strong> [ChDG_88].<br />
• E<strong>in</strong> neueres Protokoll erfordert nur, daß e<strong>in</strong>e der beiden gerade skizzierten Restriktionen<br />
für den Angreifer zutrifft [Chau_90].