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