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.

214<br />

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

213<br />

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

Unbeteiligten vollständig. Da hier der Empfänger jedoch den Rückadreßteil R1 kennt, kann er den<br />

Sender beobachten, sofern<br />

1. der Empfänger selbst oder jemand, der mit ihm zusammenarbeitet, die entsprechende Leitung<br />

abhören kann oder die Kooperation des Betreibers oder e<strong>in</strong>es Herstellers des dem MIX-Netz<br />

zugr<strong>und</strong>eliegenden Kommunikationsnetzes hat, oder <strong>in</strong> vielen Fällen wesentlich e<strong>in</strong>facher,<br />

2. der Empfänger die Kooperation von MIX1 hat, was besonders wahrsche<strong>in</strong>lich ist, wenn er ihn<br />

auswählen kann, <strong>und</strong> das dem MIX-Netz zugr<strong>und</strong>eliegende Kommunikationsnetz gesendeten<br />

Nachrichten öffentliche oder explizite Absenderadressen zuordnet (<strong>und</strong> den Netzbenutzern mitteilt<br />

– wie im geplanten ISDN vorgesehen), die e<strong>in</strong>en Personenbezug aufweisen oder deren,<br />

meist an der Topologie des Kommunikationsnetzes orientiertes Bildungsschema entweder<br />

allgeme<strong>in</strong> bekannt ist bzw. auch anderenfalls meist erschlossen werden kann oder dem Sender<br />

vom Betreiber oder e<strong>in</strong>em Hersteller des Kommunikationsnetzes der zu dieser Adresse gehörige<br />

„Ort“ mitgeteilt wird, oder<br />

3. zusätzlich zu 1. der Empfänger die Kooperation von MIX1 hat, was – wie schon erwähnt –<br />

besonders wahrsche<strong>in</strong>lich ist, wenn er ihn auswählen kann.<br />

Dies Problem kann nun natürlich auch bezüglich der 1. Bedrohung durch virtuelle Verb<strong>in</strong>dungs-<br />

Verschlüsselung [Pfi1_85 Seite 12, 14], bezüglich der 2. Bedrohung durch geeignete Protokollgestaltung<br />

im dem MIX-Netz zugr<strong>und</strong>eliegenden Kommunikationsnetz <strong>und</strong> bezüglich aller Bedrohungen<br />

mit den <strong>in</strong> §5.4.4 beschriebenen Verfahren zum Schutz des Senders gelöst werden. Durch Letzteres<br />

wird sogar mehr als nur die Kommunikationsbeziehung geschützt. Je nach Struktur <strong>und</strong> Leistungsfähigkeit<br />

des zugr<strong>und</strong>eliegenden Kommunikationsnetzes können diese Verfahren die Nutzleistung<br />

des Kommunikationsnetzes <strong>in</strong> unakzeptabler Weise reduzieren, so daß dann – sofern die<br />

Anwendung gegenseitige Anonymität fordert – nur die bereits beschriebene Komb<strong>in</strong>ation von e<strong>in</strong>em<br />

Umcodierungsschema für Sender- <strong>und</strong> e<strong>in</strong>em für Empfängeranonymität möglich ist [Pfi1_85 Seite<br />

14f]. (Die Idee ist vermutlich auch <strong>in</strong> [Chau_81 Seite 85] enthalten, die dortige Formulierung <strong>in</strong> ihrer<br />

Allgeme<strong>in</strong>heit jedoch falsch.) Diese gegenseitige Anonymität muß natürlich auch bei der ersten<br />

Nachricht vorhanden se<strong>in</strong>, was durch den schon früher beschriebenen Indirektionsschritt über e<strong>in</strong>e<br />

(hier tatsächlich nötige) zusätzliche Instanz X (bzw. zum<strong>in</strong>dest Funktionalität, die natürlich auch von<br />

e<strong>in</strong>er vorhandenen Instanz erbracht werden kann), hier e<strong>in</strong> Adreßverzeichnis mit anonymen<br />

Rückadressen, erreicht wird. Da jede anonyme Rückadresse nur e<strong>in</strong>mal verwendet werden kann,<br />

ist die Verwendung gedruckter Adreßverzeichnisse sehr umständlich, die Verwendung elektronischer,<br />

die jede Adresse nur e<strong>in</strong>mal ausgeben, jedoch ke<strong>in</strong> Problem.<br />

sches Konzelationssystem wäre natürlich auch möglich, aber aufwendiger) ist, mit dem MIX0 den<br />

Nachrichten<strong>in</strong>halt verschlüsseln soll, damit MIX1 ihn nicht lesen kann, <strong>und</strong> R1 der Teil der anonymen<br />

Rückadresse ist, der von MIX0 dem von ihm generierten <strong>und</strong> mit k0 verschlüsselten Nachrichten<strong>in</strong>halt<br />

mitgegeben wird. R1 wird vom Empfänger ausgehend von e<strong>in</strong>em zufällig gewählten e<strong>in</strong>deutigen<br />

Namen e der Rückadresse nach dem folgenden rekursiven Schema gebildet, bei dem Rj jeweils<br />

den Rückadreßteil bezeichnet, den MIXj erhalten wird, <strong>und</strong> kj jeweils den Schlüssel e<strong>in</strong>es symmetrischen<br />

Konzelationssystems (e<strong>in</strong> asymmetrisches Konzelationssystem wäre auch möglich, aber aufwendiger),<br />

mit dem MIXj den den Nachrichten<strong>in</strong>halt enthaltenden Nachrichtenteil verschlüsseln soll:<br />

Rm+1 = e<br />

Rj = cj (kj ,Aj+1 ,Rj+1 ) für j=m,...,1<br />

Diese Rückadreßteile Rj <strong>und</strong> der (ggf. bereits mehrmals verschlüsselte) vom Sender generierte Nachrichten<strong>in</strong>halt<br />

I, Nachrichten<strong>in</strong>haltsteil Ij genannt, bilden zusammen die Nachrichten Nj , die jeweils<br />

von MIXj-1 gebildet <strong>und</strong> an MIXj gesendet werden – nach dem folgenden rekursiven Schema also<br />

zuerst vom Sender MIX0 <strong>und</strong> dann der Reihe nach von den durchlaufenen MIXen MIX1 ,...,MIXm :<br />

N1 = R1 ,I1 ; I1 = k0 (I)<br />

Nj = Rj ,Ij ; Ij = kj-1 (Ij-1 ) für j=2,...,m+1<br />

Der Empfänger MIXm+1 erhält also e,Nm+1 = e,km (...k1 (k0 (I))...) <strong>und</strong> kann, da er dem e<strong>in</strong>deutigen<br />

Namen e der Rückadresse alle geheimen Schlüssel kj (im Falle der Verwendung e<strong>in</strong>es asymmetrischen<br />

Konzelationssystems: alle Dechiffrierschlüssel) <strong>in</strong> richtiger Reihenfolge zuordnen kann, ohne<br />

Probleme entschlüsseln <strong>und</strong> so den Nachrichten<strong>in</strong>halt I gew<strong>in</strong>nen.<br />

Die Mitverschlüsselung zufälliger Bitketten ist auch bei Verwendung von determ<strong>in</strong>istischen<br />

Konzelationssystemen nicht nötig, da die mit öffentlich bekannten Chiffrierschlüsseln<br />

der MIXe verschlüsselten Nachrichtenteile Rj mit dem nicht ausgegebenen<br />

kj genügend dem Angreifer nicht bekannte Information enthalten <strong>und</strong> bezüglich des<br />

Umcodierens mit dem Angreifer unbekannten Schlüsseln diesem sowieso ke<strong>in</strong> Testen<br />

möglich ist.<br />

5.4.6.5 Längentreue Umcodierung<br />

Bei diesem <strong>in</strong>direkten Umcodierungsschema für Empfängeranonymität ist nur das Umcodieren des<br />

Rückadreßteils (zum<strong>in</strong>dest bei allen außer dem letzten MIX) vollständig durch den jeweils öffentlich<br />

bekannten Chiffrierschlüssel bestimmt. Um nicht über Nachrichtenhäufigkeiten Entsprechungen zwischen<br />

E<strong>in</strong>- <strong>und</strong> Ausgabe dieser MIXe entstehen zu lassen, bearbeitet jeder MIX (solange er se<strong>in</strong><br />

Schlüsselpaar beibehält) nur unterschiedliche Rückadreßteile. Hieraus folgt:<br />

Nachdem nun die e<strong>in</strong>fachstmöglichen Umcodierungsschemata für Sender- oder Empfängeranonymität<br />

hergeleitet <strong>und</strong> ihre E<strong>in</strong>satzmöglichkeiten beschrieben wurden, soll noch auf e<strong>in</strong>e weitere geme<strong>in</strong>same<br />

Eigenschaft h<strong>in</strong>gewiesen werden: In beiden Umcodierungsschemata ändert sich beim Umcodieren die<br />

Länge von Nachrichten – sie werden kürzer. Dies ist, wenn alle Nachrichten die gleichen MIXe <strong>in</strong><br />

gleicher Reihenfolge durchlaufen, was – wie <strong>in</strong> §5.4.6.1 gezeigt – zum Erreichen des maximal<br />

möglichen Anonymitätszieles nötig ist, ke<strong>in</strong> Problem, vgl. Bild 5-26 oben. Nun können – wie <strong>in</strong><br />

[Pfit_89 §3.2.2.4] gezeigt ist – vor allem Leistungs-, aber auch Kostengesichtspunkte verh<strong>in</strong>dern,<br />

daß alle Nachrichten <strong>in</strong> allen MIXen umcodiert werden. In solchen MIX-Netzen können dann die<br />

abnehmenden Nachrichtenlängen e<strong>in</strong>em Angreifer durchaus wertvolle Information liefern. In Bild 5-<br />

26 unten ist leicht zu erkennen, daß die Nachrichten <strong>in</strong>nerhalb der MIXe nicht über Kreuz gehen, was<br />

im oberen Teil des Bildes nicht zu erkennen ist.<br />

Jede anonyme Rückadresse kann nur e<strong>in</strong>mal verwendet werden.<br />

E<strong>in</strong>e Wiederholung des Nachrichten<strong>in</strong>haltsteils Ij ist unkritisch, sofern zum Umcodieren jeweils e<strong>in</strong><br />

unterschiedlicher Schlüssel verwendet wird. Dies ist, da jede anonyme Rückadresse nur e<strong>in</strong>mal<br />

verwendet werden kann, immer dann der Fall, wenn beim Bilden anonymer Rückadressen jeweils<br />

neue Schlüssel kj verwendet werden. Beachtet e<strong>in</strong> Empfänger beim Bilden von anonymen Rückadressen<br />

diese Regel nicht, schadet er sich nur selbst. Verwendet e<strong>in</strong> MIXj e<strong>in</strong>en alten Schlüssel kj zur Bildung e<strong>in</strong>er Rückadresse, kann er dadurch dem Generierer von kj auch nicht mehr schaden als<br />

durch Verraten des Nachrichtenzusammenhangs, der durch das ursprüngliche Umcodieren mit kj verborgen werden sollte. Bild 5-29 zeigt das Schema graphisch.<br />

5.4.6.4 Gegenseitige Anonymität<br />

Wird dieses Umcodierungsschema für Empfängeranonymität alle<strong>in</strong> verwendet, so verbirgt es (wie<br />

das Umcodierungsschema für Senderanonymität auch) zwar die Kommunikationsbeziehung vor

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!