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

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

204<br />

A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />

203<br />

A. Pfitzmann: Datensicherheit <strong>und</strong> Kryptographie; TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr<br />

Verwendung e<strong>in</strong>es Konzelationssystems, so daß ihre Wege über ihre Länge <strong>und</strong> Codierung, zusammen<br />

ihr äußeres Ersche<strong>in</strong>ungsbild, nicht verfolgt werden können.<br />

Damit dieses Verfolgen des Weges auch über zeitliche oder räumliche Zusammenhänge nicht<br />

möglich ist, muß jeder MIX jeweils mehrere Nachrichten gleicher Länge von genügend vielen unterschiedlichen<br />

Absendern110 abwarten (oder ggf. auch selbst erzeugen oder von Teilnehmerstationen<br />

erzeugen lassen – sofern nichts Nützliches zu senden ist, eben bedeutungslose Nachrichten, die von<br />

der Teilnehmerstation des Empfängers oder bei geeigneter Verschlüsselungsstruktur <strong>und</strong> Adressierung<br />

bereits von e<strong>in</strong>em der folgenden MIXe ignoriert werden), sie dazu puffern <strong>und</strong> nach der Umcodierung<br />

umsortiert, d.h. <strong>in</strong> anderer zeitlicher Reihenfolge bzw. auf anderen Leitungen ausgeben.<br />

E<strong>in</strong>e geeignete Reihenfolge ist etwa die alphabetische Ordnung der umcodierten Nachrichten. (Solch<br />

e<strong>in</strong>e von vornhere<strong>in</strong> vorgegebene Reihenfolge ist besser als e<strong>in</strong>e zufällige, da so der verborgene<br />

Kanal (covert -, hidden channel) der „zufälligen“ Reihenfolge für e<strong>in</strong> eventuell im jeweiligen MIX<br />

vorhandenes Trojanisches Pferd geschlossen wird. Da auch die Anzahl der jeweils gleichzeitig zu<br />

mixenden Nachrichten sowie die Zeitverhältnisse exakt vorgegeben werden können <strong>und</strong> dem MIX<br />

das Erzeugen von Nachrichten verboten werden kann, braucht der MIX ke<strong>in</strong>erlei Handlungsspielraum<br />

<strong>und</strong> damit braucht ke<strong>in</strong>erlei Möglichkeit zu bestehen, über die e<strong>in</strong> eventuell im MIX vorhandenes<br />

Trojanisches Pferd e<strong>in</strong>em nicht empfangsberechtigten Empfänger verborgen Information zukommen<br />

lassen kann, vgl. §1.2.2 <strong>und</strong> [PoKl_78, Denn_82 Seite 281].)<br />

Die zum Zwecke des Verbergens zeitlicher oder räumlicher Zusammenhänge zusammen gemixten,<br />

d.h. zusammen gepufferten (oder erzeugten), umcodierten <strong>und</strong> umsortiert (beispielsweise <strong>in</strong> alphabetischer<br />

Reihenfolge) ausgegebenen Nachrichten gleicher Länge werden als e<strong>in</strong> Schub (batch<br />

[Chau_81 Seite 85]) bezeichnet. 111<br />

Mit dem Zurückschalten vom F-Modus <strong>in</strong> den A-Modus wird das Verfahren zum anonymen<br />

Mehrfachzugriff neu <strong>in</strong>itialisiert, um Auswirkungen von Fehlern der Schicht 1 (physical) auf<br />

die Schicht 2 (data l<strong>in</strong>k) rückgängig zu machen. Alle gerade geschilderten Schritte s<strong>in</strong>d <strong>in</strong> Bild<br />

5-21 zusammengefaßt.<br />

Natürlich gibt es h<strong>und</strong>erte von Variationen dieses Fehlerlokalisierungs- <strong>und</strong> -behebungsprotokolls,<br />

über deren Zweckmäßigkeit geurteilt werden kann, sobald die Wahrsche<strong>in</strong>lichkeiten von (Mehrfach-)<br />

Fehlern bekannt s<strong>in</strong>d. Ist beispielsweise die Wahrsche<strong>in</strong>lichkeit von Mehrfachfehlern signifikant, so<br />

sollten Hälften des Schlüsselaustauschgraphen, die vom gerade beschriebenen Protokoll nicht getestet<br />

werden, auch getestet werden, was den Aufwand des Protokolls höchstens verdoppelt.<br />

Da die Wahrsche<strong>in</strong>lichkeiten nicht bekannt s<strong>in</strong>d, s<strong>in</strong>d folglich nicht die Details von Fehlerlokalisierung<br />

<strong>und</strong> -behebung <strong>in</strong>teressant, sondern daß sie mit logarithmischem Zeitaufwand (<strong>in</strong> der Zahl<br />

der Stationen) möglich s<strong>in</strong>d.<br />

Es ist beachtenswert, daß bei „Fehlererkennung, -lokalisierung <strong>und</strong> -behebung <strong>in</strong> e<strong>in</strong>em DC-Netz“<br />

die Anonymität trotz Fehlertoleranz nicht abgeschwächt wird, wenn entweder echt zufällig generierte<br />

Schlüssel oder kryptographisch starke PZGs verwendet werden. Durch das E<strong>in</strong>führen der zwei Modi<br />

<strong>und</strong> die Verwendung von Schlüsselzeichen entweder im e<strong>in</strong>en oder aber im anderen Modus bleibt im<br />

A-Modus die Anonymität jederzeit <strong>in</strong> ihrem ursprünglichen Umfang garantiert.<br />

A-Modus F-Modus<br />

Sender <strong>und</strong><br />

Empfänger<br />

nicht geschützt<br />

Anonyme Nachrichtenübertragung<br />

durch<br />

überlagerndes Senden<br />

Zusätzlich zum Puffern, Umcodieren <strong>und</strong> Umsortieren von Nachrichten gleicher Länge muß jeder<br />

MIX darauf achten, daß jede Nachricht nur e<strong>in</strong>mal gemixt wird – oder anders herum gesagt: Nachrichtenwiederholungen<br />

ignoriert werden. E<strong>in</strong>e E<strong>in</strong>gabe-Nachricht stellt genau dann e<strong>in</strong>e Nachrichtenwiederholung<br />

dar, wenn sie schon e<strong>in</strong>mal bearbeitet wurde <strong>und</strong> die jeweils zugehörigen Ausgabe-<br />

Nachrichten von Unbeteiligten verkettbar (beispielsweise gleich) wären. (Wann dies genau der Fall<br />

ist, hängt vom verwendeten Umcodierungsschema ab <strong>und</strong> wird deshalb zusammen mit den Umcodierungsschemata<br />

weiter unten diskutiert.)<br />

Wird e<strong>in</strong>e Nachricht <strong>in</strong>nerhalb e<strong>in</strong>es Schubes mehrfach bearbeitet, so entstehen über die Häufigkeiten<br />

der E<strong>in</strong>gabe- <strong>und</strong> Ausgabe-Nachrichten dieses Schubes unerwünschte Entsprechungen: e<strong>in</strong>er<br />

E<strong>in</strong>gabe-Nachricht, die n-mal auftritt, entspricht e<strong>in</strong>e Ausgabe-Nachricht, die ebenfalls n-mal auftritt.<br />

Treten alle E<strong>in</strong>gabe-Nachrichten e<strong>in</strong>es Schubes verschieden häufig auf, so schützt das Umcodieren<br />

dieses Schubes also überhaupt nicht.<br />

Wird e<strong>in</strong>e Nachricht <strong>in</strong> mehreren Schüben bearbeitet, so können zwischen diesen Schüben nichtleere<br />

Durchschnitte (<strong>und</strong> Differenzen) gebildet werden, <strong>in</strong>dem jeweils der Durchschnitt (die Differenz)<br />

Fehlererkennung<br />

Fehlerlokalisierung<br />

Ausgliederung<br />

der defekten<br />

Komponenten<br />

Fehlerzustandsbehebung<br />

der PZGs,<br />

Initialisierung des<br />

Zugriffsprotokolls<br />

Bild 5-21: Fehlererkennung, -lokalisierung <strong>und</strong> -behebung beim DC-Netz<br />

5.4.6 MIX-Netz: Schutz der Kommunikationsbeziehung<br />

110 Die Forderung „Nachrichten von genügend vielen unterschiedlichen Absendern“ ist e<strong>in</strong>e schwierig zu erfüllende<br />

Forderung: 1. s<strong>in</strong>d <strong>in</strong> manchen Kommunikationsnetzen, z.B. dem Internet, e<strong>in</strong>e<strong>in</strong>deutige Teilnehmeridentitäten nicht<br />

gegeben, d.h. Teilnehmer können sich beliebig viele unterschiedliche Identitäten zulegen. MIX-Varianten, die selbst<br />

dann noch s<strong>in</strong>nvoll e<strong>in</strong>gesetzt werden können, s<strong>in</strong>d <strong>in</strong> [Kesd_99] beschrieben. 2. ist selbst dann, wenn e<strong>in</strong>e<strong>in</strong>deutige<br />

Teilnehmeridentitäten gegeben s<strong>in</strong>d, deren Prüfung ab dem zweiten durchlaufenen MIX alles andere als trivial, vgl.<br />

Aufgabe 5-20.<br />

111 E<strong>in</strong>e im Internet verbreitete MIX-Implementierung (MIXmaster) arbeitet etwas anders: Bei ihr wird <strong>in</strong> e<strong>in</strong>em Pool<br />

e<strong>in</strong>e M<strong>in</strong>destanzahl an Nachrichten gehalten <strong>und</strong> nach dem Mixen e<strong>in</strong>er neu e<strong>in</strong>getroffenen Nachricht dann zwischen<br />

dieser <strong>und</strong> den im Pool enthaltenen e<strong>in</strong>zelnen Nachrichten e<strong>in</strong>e Zufallsauswahl getroffen, welche Nachricht ausgegeben<br />

wird. Wird Poolgröße+1 gleich Schubgröße gewählt, ist die durchschnittliche Verzögerungszeit bei der<br />

Poolimplementierung doppelt so groß – dafür ist die Unverkettbarkeit von E<strong>in</strong>gabe- <strong>und</strong> Ausgabenachrichten höher.<br />

Da bei Kommunikationsdiensten oftmals garantiert werden muß, daß e<strong>in</strong>e maximale Verzögerungszeit nicht<br />

überschritten wird <strong>und</strong> bei der Poolimplementierung ke<strong>in</strong>e Garantie gegeben werden kann, ersche<strong>in</strong>t mir die<br />

schubweise Implementierung vorteilhaft.<br />

Statt zusätzlich zum Empfänger auch den Sender verborgen zu halten, kann man zunächst versuchen,<br />

nur deren Verb<strong>in</strong>dung geheimzuhalten <strong>und</strong> so die Anonymität der Kommunikation herzustellen.<br />

Diese Idee wird durch das Verfahren der umcodierenden MIXe verwirklicht [Chau_81,<br />

Cha1_84].<br />

Bei diesem von David Chaum 1981 für elektronische Post vorgeschlagenen Verfahren werden<br />

Nachrichten von ihren Sendern nicht notwendigerweise auf dem kürzesten Weg zu ihren Empfängern<br />

geschickt, sondern über mehrere möglichst bezüglich ihres Entwurfes, ihrer Herstellung [Pfit_86<br />

Seite 356] <strong>und</strong> ihres Betreibers [Chau_81, Cha1_84 Seite 99] unabhängige sowie Nachrichten<br />

gleicher Länge puffernde, umcodierende <strong>und</strong> umsortierende Zwischenstationen, sogenannte MIXe,<br />

geleitet. Jeder MIX codiert Nachrichten gleicher Länge um, d.h. ent- oder verschlüsselt sie unter

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!