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.

456<br />

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

455<br />

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

sollte. Erhebt niemand E<strong>in</strong>spruch, dann s<strong>in</strong>d alle Informationse<strong>in</strong>heiten von protokolltreuen<br />

Teilnehmerstationen noch vorhanden: Zu jeder E<strong>in</strong>gabe gibt es die entsprechende Ausgabe,<br />

sonst hätte die protokolltreue Teilnehmerstation E<strong>in</strong>spruch erhoben. Protokolltreue Teilnehmerstationen<br />

schicken ke<strong>in</strong>e Kopien von Nachrichten, die sie selbst oder andere schon mal<br />

geschickt haben - wenn dies Angreiferstationen tun, verh<strong>in</strong>dert dies nicht, daß e<strong>in</strong>e der Informationse<strong>in</strong>heiten<br />

durchkommt. Da aber Angreiferstationen sowieso nichts zur Unbeobachtbarkeit<br />

der Kommunikationsbeziehung beitragen, ist es nicht schädlich, wenn ihre Informationse<strong>in</strong>heiten-Wiederholungen<br />

von MIXen legitimerweise ignoriert werden – selbst wenn ihre orig<strong>in</strong>alen<br />

Informationse<strong>in</strong>heiten illegitimerweise unterdrückt oder ersetzt werden <strong>und</strong> sie nicht<br />

protestieren, ist dies nicht schlimm.<br />

5-18 Brechen der direkten RSA-Implementierung von MIXen<br />

RSA ist multiplikativ <strong>und</strong> dies überträgt sich zum<strong>in</strong>dest näherungsweise auch auf die direkte RSA-<br />

Implementierung von MIXen. Deshalb kann e<strong>in</strong> Angreifer Vielfache e<strong>in</strong>er beobachteten E<strong>in</strong>gabe-<br />

Nachricht <strong>in</strong> den MIX e<strong>in</strong>geben <strong>und</strong> als Vielfache der entsprechenden Ausgabe-Nachricht<br />

erkennen.<br />

5-19 Wozu MIX-Kanäle?<br />

a) Um die Verzögerungszeit <strong>und</strong> den Aufwand des Umcodierens <strong>in</strong> den MIXen zu senken:<br />

Während des Kanals kann e<strong>in</strong> symmetrisches Konzelationssystem verwendet werden, so daß<br />

nur für den Kanalaufbau e<strong>in</strong> asymmetrisches Konzelationssystem verwendet werden muß.<br />

Symmetrische Konzelationssysteme s<strong>in</strong>d bekanntlich wesentlich weniger aufwendig bzw.<br />

wesentlich schneller als asymmetrische.<br />

b) Kanäle, die zusammen gemixt werden <strong>und</strong> sich bzgl. den Kommunikationsbeziehungen<br />

gegenseitig schützen sollen, müssen zusammen beg<strong>in</strong>nen <strong>und</strong> enden. Bereits ersteres alle<strong>in</strong><br />

erfordert spürbare Wartezeiten. Beides zusammen würde unerträgliche Wartezeiten erzw<strong>in</strong>gen.<br />

Das beschriebene Protokoll, bei dem jeder bzgl. se<strong>in</strong>er eigenen Nachrichten fortlaufend jeden<br />

MIX überprüft, verh<strong>in</strong>dert den Erfolg verändernder Angriffe, kann aber zu aufwendig se<strong>in</strong>:<br />

Wenn jeder jede Ausgabe jedes MIXes erhalten soll, um unbeobachtbar prüfen zu können,<br />

dann erfordert die naive Implementierung (Verteilung) mehr Aufwand als normale Verteilung<br />

zum Schutz des Empfängers, die pro Nachricht ja nur e<strong>in</strong>mal – <strong>und</strong> nicht wie hier nach jedem<br />

MIX – erfolgen muß.<br />

E<strong>in</strong>e Alternative, die verändernde Angriffe im allgeme<strong>in</strong>en Fall jedoch lediglich erkennt, ist<br />

stichprobenartige Überprüfung.<br />

E<strong>in</strong>e andere Alternative wäre, daß jede Nachricht für jeden MIX (oder aus Effizienzgründen<br />

nur für den letzten) e<strong>in</strong>e anonyme Rückadresse enthält, die mit e<strong>in</strong>er digital signierten<br />

Quittung über die Auslieferung der Nachricht an den Sender zurückgeschickt wird. Dann kann<br />

er überprüfen, ob se<strong>in</strong>e Nachricht den Empfänger ohne Verzögerung erreicht hat, <strong>und</strong> falls<br />

ne<strong>in</strong> ggf. sogar, wo sie unterschlagen wurde.<br />

Senden Teilnehmer bedeutungslose Nachrichten, so können sie diese an sich selbst senden<br />

<strong>und</strong> dabei überprüfen, daß ihre bedeutungslosen Nachrichten sie auch so schnell erreichen,<br />

wie dies zu erwarten war. So können Teilnehmer fast ohne Zusatzaufwand überprüfen, daß<br />

MIXe Nachrichten der Teilnehmer nicht durch ihre eigenen ersetzen. Aber auch dies verh<strong>in</strong>dert<br />

den Erfolg von verändernden Angriffen nicht, sondern erkennt sie nur.<br />

5-19a Freie MIX-Reihenfolge bei fester Anzahl benutzter MIXe?<br />

Der von Ronny entdeckte Angriff geht so: Der Angreifer weiß für jede e<strong>in</strong>zelne Nachricht vor dem<br />

e<strong>in</strong>zigen vertrauenswürdigen MIX, wie viele se<strong>in</strong>er MIXe diese Nachricht wie durchlaufen hat.<br />

Ebenso weiß er für jede e<strong>in</strong>zelne Nachricht nach dem vertrauenswürdigen MIX, wie viele se<strong>in</strong>er<br />

MIXe diese Nachricht noch durchläuft. Also gehört genau die Nachricht vor dem vertrauenswürdigen<br />

MIX zu der Nachricht nach dem vertrauenswürdigen MIX, wo die Summe der<br />

durchlaufenen MIXe paßt. Scheibenkleister. Also entweder freie Routenwahl <strong>und</strong> zwangsweise<br />

zufällige Routenlängen – oder doch Kaskaden.<br />

5-21 Koord<strong>in</strong>ations-Protokoll bei MIXen: Wozu <strong>und</strong> wo?<br />

E<strong>in</strong> Koord<strong>in</strong>ations-Protokoll zwischen MIXen ist immer dann notwendig, wenn sich MIXe<br />

gegenseitig ersetzen können, wie dies bei MIXe mit Reserve-MIXen <strong>und</strong> Auslassen von MIXen<br />

der Fall ist. Die Koord<strong>in</strong>ation zwischen diesen MIXen muß jeweils sicherstellen, daß ke<strong>in</strong>e<br />

Umcodierung mehrfach erfolgt – sonst wären E<strong>in</strong>- <strong>und</strong> Ausgangsnachrichten dieser MIXe über<br />

ihre Häufigkeiten verkettbar.<br />

5-22 Grenzziehung der Verantwortungsbereiche – Funktionsumfang der Netzabschlüsse<br />

Funktionen, denen sowohl der Teilnehmer für se<strong>in</strong>e persönlichen <strong>Sicherheit</strong>s<strong>in</strong>teressen (vor allem<br />

Vertraulichkeit <strong>und</strong> Integrität) als auch der Netzbetreiber für se<strong>in</strong>e anbietermäßigen <strong>Sicherheit</strong>s<strong>in</strong>teressen<br />

(vor allem Verfügbarkeit der Kommunikation) vertrauen müssen, bedürfen e<strong>in</strong>er Implementierung,<br />

deren Korrektheit des Entwurfes, der Produktion, des Betriebes <strong>und</strong> der Wartung<br />

dann mehrere Parteien vertrauen müssen. Gibt es ke<strong>in</strong>en beiden vertrauenswürdigen Betreiber,<br />

werden ausforschungssichere Geräte benötigt – es gelten alle kritischen Bemerkungen aus §2.1.<br />

Ende-zu-Ende-Verschlüsselung <strong>und</strong> implizite Adressierung (übrigens genauso wie digitale<br />

Signaturen) betreffen jeweils nur die direkt an dieser Kommunikation Beteiligten. Diese Funktionen<br />

kann also jeder Teilnehmer so gut oder schlecht realisieren, wie es ihm behagt.<br />

5-20 Wie sichern, daß MIXe Nachrichten von genügend vielen unterschiedlichen<br />

Sendern erhalten?<br />

a) Da der erste MIX wissen darf, welche Informationse<strong>in</strong>heiten von welchem Sender kommt,<br />

funktioniert bei ihm die kanonische Lösung: Sender lassen sich registrieren, veröffentlichen<br />

Testschlüssel <strong>und</strong> signieren die Informationse<strong>in</strong>heiten, die sie an den ersten MIX senden.<br />

Dann kann der erste MIX – sowie jeder, der sich dafür <strong>in</strong>teressiert – prüfen, von wie vielen<br />

verschiedenen Sendern Informationse<strong>in</strong>heiten im Schub s<strong>in</strong>d.<br />

b) H<strong>in</strong>tere, d.h. nicht erste, MIXe dürfen nicht wissen, wer ihre E<strong>in</strong>gabe- oder Ausgabe-Informationse<strong>in</strong>heiten<br />

gesendet hat – sonst bewirken die vorderen MIXe den h<strong>in</strong>teren gegenüber<br />

ke<strong>in</strong>en Schutz, was sie aber sollen! Deshalb darf die Lösung von a) hier auf gar ke<strong>in</strong>en Fall<br />

angewendet werden. (Hier ersche<strong>in</strong>t Ihnen die Aufgabe nun möglicherweise unlösbar – aber<br />

nicht zu früh aufgeben, es geht. Vielleicht probieren Sie es noch mal, bevor Sie weiterlesen.)<br />

Die Lösungsidee besteht dar<strong>in</strong>: Zwar soll im h<strong>in</strong>teren Teil der MIX-Kaskade niemand mehr<br />

testen können, von wem e<strong>in</strong>e Informationse<strong>in</strong>heit stammt. Aber wenn wir mit a) sicherstellen,<br />

daß <strong>in</strong> den ersten MIX „Informationse<strong>in</strong>heiten von genügend vielen Sendern“ h<strong>in</strong>e<strong>in</strong>g<strong>in</strong>gen<br />

<strong>und</strong> sich alle MIXe korrekt verhalten, dann braucht dies auch niemand! H<strong>in</strong>ten s<strong>in</strong>d dann noch<br />

Informationse<strong>in</strong>heiten von genauso vielen protokolltreuen Teilnehmern vorhanden wie vorne!<br />

(Der Zusatz protokolltreu ist wichtig, wie wir gleich sehen werden.)<br />

Um sicherzustellen, daß sich alle MIXe korrekt verhalten, vere<strong>in</strong>baren wir folgendes Protokoll:<br />

Alle E<strong>in</strong>- <strong>und</strong> Ausgaben der MIXe s<strong>in</strong>d öffentlich <strong>und</strong> von den MIXen signiert. Jeder,<br />

der e<strong>in</strong>e Informationse<strong>in</strong>heit zur Schubfolge beigesteuert hat, überprüft direkt nach jedem<br />

Schub jedes e<strong>in</strong>zelnen MIXes, ob se<strong>in</strong>e Informationse<strong>in</strong>heit richtig gemixt wurde. Wenn ne<strong>in</strong>,<br />

erhebt er E<strong>in</strong>spruch, bevor der nächste MIX se<strong>in</strong>e Ausgabe bekanntgibt. Wie er ihn beweisbar<br />

erheben kann, steht <strong>in</strong> §5.4.7 <strong>in</strong> der Fußnote – <strong>und</strong> implizit damit auch, wann E<strong>in</strong>sprüche als<br />

unberechtigt verworfen <strong>und</strong> derjenige, der den Betrieb nur aufgehalten hat, bestraft werden

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!