Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
Sicherheit in Rechnernetzen: - Professur Datenschutz und ...
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