03.08.2013 Aufrufe

Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

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].

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!