Mixmaster- & Remailer-Angriffe

Vorwort

Der folgende Text ist meine Übersetzung des englischen Originals Mixmaster & Remailer Attacks von Lance Cottrell .

Ich möchte Lance Cottrell an dieser Stelle für sein Einverständnis zu dieser Übersetzung und der Verwendung der Originalabbildungen danken. Das Ziel der Übersetzung ist es, technische Details der Sicherheit von Remailern denjenigen deutschsprachigen Remailer-Anwendern zukommen zu lassen, die mit langen technischen Abhandlungen in englischer Sprache Schwierigkeiten haben.

Der Text ist sachlich, nüchtern und knapp gehalten, bietet aber eine Vielzahl aufschlußreicher Informationen. Sollte die Darstellung unklar sein, so verweise ich erneut auf das Original . Bei Kritik an der Übersetzung bitte ich um Nachricht .

Olaf Brandes , <brandes@cs.tu-berlin.de>

Ein aktueller Nachtrag zum Vorwort. Zuerst dachte ich ja, ich hätte mir die Arbeit auch sparen können, nachdem Digital Equipment über ihren Altavista-Dienst neuerdings auch Übersetzungen anbieten.

Indes, wer gern lacht, kann sich die maschinelle Übersetzung ja gern mal anschauen. Leider ist es mir hier nicht möglich, einen Link bereitzustellen, da babelfish dies nicht unterstützt. Hier ein Auszug:

Da anonyme remailers entworfen werden, um Verkehrsauswertung zu verhindern, soll die beste Weise, ihre Schwächen zu verstehen verschiedene Angriffe studieren, die ein Konkurrent gegen sie verwenden konnte. Ich nehme einen sehr leistungsfähigen Konkurrenten, beide an, um ein falschstes Falldrehbuch darzustellen und weil es möglich ist, diesen Angriffen mit remailers des zweiten Erzeugung zu widerstehen.


Cypherpunk-Remailer

Gängige Remailer-Nachrichten bestehen aus ineinander verschachtelten, verschlüsselten Nachrichten. Dabei ist jede Nachricht für einen bestimmten Remailer gedacht und verschlüsselt. Die Nachricht enthält dabei die Anweisungen für den Remailer (wie z.B. das nächste Ziel der Nachricht) und die weiterzuleitende Nachricht selbst. Jeder Remailer entfernt eine Ebene der Verschlüsselung mit den dazugehörigen Anweisungen, führt alle Anweisungen aus und verschickt die Nachricht an den angegebenen Empfänger.

Abbildung 1

Die obige Abbildung stellt die Struktur einer Nachricht dar, die durch 3 Remailer (A,B,C) zu Bob gesendet werden wird. Jeder Rahmen steht für eine Verschlüsselungsebene, wobei der Name des Empfängers, für den die Nachricht verschlüsselt ist, links oben außerhalb des Rahmens steht. Das Diagramm zeigt sofort einen wichtigen Aspekt auf: Die Größe der Nachricht verringert sich bei jeder Weiterleitung.

Cypherpunk-Remailer können folgende Aufgaben übernehmen:

  • Versenden einer Nachricht an eine andere eMail-Adresse oder Newsgroup.
  • Verarbeitung von verschlüsselten Nachrichten, wobei die Anweisungen im verschlüsselten Teil versteckt sind.
  • Entfernen aller (oder wenigstens einiger) Mail-Header.
  • Hinzufügen neuer Header (wie z.B. Subject-Zeilen).
  • Entfernen von Informationen am Ende der Nachricht.
  • Verschlüsseln eines Teils der Nachricht mit einem in der Nachricht angegebenen Schlüssel.
Einige Remailer bieten auch folgende Funktionen:
  • Verzögern der Weiterleitung um eine feste oder zufällige Zeit.
  • Umsortieren der ausgehenden Nachrichten in Bezug auf die Reihenfolge ihres Eintreffens (hierzu wird zu jeder Zeit eine Mindestanzahl von verzögerten Nachrichten im Remailer gehalten).

Angriffe auf Cypherpunk-Remailer

Anonyme Remailer sind dazu da, die Analyse des Nachrichtenverkehrs zu verhindern. Um ihre Schwachstellen zu begreifen, ist es deshalb am besten, sich die verschiedenen Angriffe zu vergegenwärtigen, zu denen ein Gegner in der Lage wäre. Um einerseits den schlimmsten Fall einschätzen zu können und andererseits die Entwicklung der Remailer der zweiten Generation zu motivieren, werde ich hier von einem sehr mächtigen Gegner ausgehen.

Der fiktive Gegner

Ich nehme an, daß der Angreifer in der Lage ist, die Inhalte aller Nachrichten, die alle beteiligten Remailer erreichen und verlassen, zusammen mit dem Zeitpunkt ihrer Ankunft bzw. ihres Absendens aufzuzeichnen. Alle Nachrichten werden beobachtet, wenn sie den Rechner des Absenders verlassen und den des Empfängers erreichen. Der Angreifer kann außerdem eine unbegrenzte Anzahl von Nachrichten durch die Remailer senden und insbesondere solche, die er zuvor abgefangen hat, erneut versenden. Er kann auch verhindern, daß Nachrichten ihren Empfänger erreichen (Denial of Service). Der Angreifer hat einige, aber nicht alle, der beteiligten Remailer kompromittiert und kennt daher den Absender, den Empfänger und den Inhalt aller Nachrichten, die durch die kompromittierten Remailer weitergeleitet werden.

Einfache Angriffe

Es ist sofort offensichtlich, daß unter diesen Umständen unverschlüsselte Nachrichten leicht verfolgt werden können, so daß ich im folgenden nur verschlüsselte Nachrichten betrachten werde. Auch ist die Verwendung eines einzigen Remailers unsicher. Ist der Remailer kompromittiert, kennt der Operator sowohl die Ausgangs- als auch die Zieladresse der Nachricht.

Reordering (Umordnen)

Ketten von Remailern und die Verwendung von Verschlüsselung sind besser, aber immer noch verletzbar. Die Nachrichten können durch solche Remailer hindurch verfolgt werden, weil eingehende Nachrichten sofort nach ihrer Verarbeitung weitergeleitet werden. Sobald eine Nachricht eingeht, wird also eine andere verschickt. Der Angreifer weiß ohne weiteres, daß es sich bei den beiden um die selbe Nachricht handelt, unabhängig von allen anderen getroffenen Vorkehrungen. Er kann dies sogar im Nachhinein anhand von Logfiles ermitteln, falls diese aufbewahrt werden.

Dies ist der größte Schwachpunkt der normalen Cypherpunk-Remailer. Eine erste Abhilfe war, die Weiterleitung eingehender Nachrichten um eine zufällige Zeitspanne zu verzögern. Sofern diese Zeitspanne länger wäre als diejenige zwischen der Ankunft einzelner Nachrichten, wäre es ebenso unmöglich, mit absoluter Sicherheit zu wissen, welche eingegangene Nachricht mit welcher gesendeten korrespondiert. Dieser Ansatz ist in mehrerlei Hinsicht unzureichend. Das genaue Ausmaß an Schutz, das eine Verzögerung (Latency) bietet, ist unbekannt, weil es von der Menge des Datenverkehrs durch den Remailer zum jeweiligen Zeitpunkt abhängt. Gibt es viele eingehende Nachrichten während der durchschnittlichen Verzögerungszeit, so ist die Identität der Nachricht hinreichend verschleiert. Gibt es hingegen wenig Nachrichtenverkehr (z.B. wegen normaler Schwankungen, Netzwerkausfällen oder Denial-of-Service-Angriffen), ist kaum oder kein Schutz gewährleistet. Um einen minimalen Schutz zu gewährleisten, muß die Verzögerungszeit bereits sehr viel größer sein als es bei viel Datenaufkommen nötig wäre, wenn man nur normale Schwankungen des Nachrichtenverkehrs in Betracht zieht.

Obwohl das Neuordnen dieses Problem löst, schafft es gleichzeitig die Grundlage für einen anderen Angriff. Das Neuordnen ist nur möglich, wenn jederzeit eine bestimmte Anzahl von Nachrichten im Remailer gesammelt wird. Diese Nachrichten heißen Message Pool. Das effizienteste Neuordnungsverfahren besteht darin, stets N Nachrichten im Pool zu halten und beim Eintreffen einer neuen Nachricht genau eine der N+1 Nachrichten (inclusive der gerade eingetroffenen) zufällig auszuwählen und zu versenden. Unglücklicherweise ist dieses Verfahren für einen Spam-Angriff anfällig. Hierbei sendet ein Angreifer deutlich mehr als N Nachrichten an den Remailer. Diese Nachrichten verdrängen alle echten Nachrichten aus dem Pool und hinterlassen dort nur solche, die der Angreifer als seine eigenen identifizieren kann. Sendet der Angreifer nach dem Eintreffen einer zu verfolgenden Nachricht erneut viele Nachrichten, wird diese sofort aus dem Pool geholt und weitergeleitet. Da der Angreifer seine eigenen Nachrichten erkennen kann, ist die interessante Nachricht leicht zu identifizieren.

Die Verbindung von Verzögerung (Latency) und Neuordnung (Reordering) verschlechtert die Situation des Angreifers bis zu einem gewissen Grad. Hierbei wird nicht in dem Moment eine zufällige Nachricht aus dem Pool versendet, in dem eine andere eintrifft, sondern es werden periodisch alle bis auf N Nachrichten aus dem Pool verschickt. Sofern während der durchschnittlichen Verzögerung mehrere echte Nachrichten eingegangen sind, so werden auch mehrere echte unter den ausgehenden Nachrichten sein. Kombiniert der Angreifer aber den Spam- mit dem Denial-of-Service-Angriff, wird Deine Nachricht wieder die einzige Nachricht sein, die nicht vom Angreifer stammt. Wenn der Angreifer dafür sorgen kann, daß Deine Nachricht die einzige ist, die alle beteiligten Remailer durchläuft, ist dieses Verfahren also nichts wert. Ideale Remailer vorrausgesetzt, wäre Deine Nachricht nur eine von vielen, die gleichzeitig durch irgendeinen Remailer geleitet wird. Ist Deine Nachricht aber die einzige, die durch das Netzwerk von Remailern gelangt, ist alles für die Katz.

Größe & Unterscheidbarkeit

Nehmen wir nun an, Deine Nachricht würde durch eine Kette von Remailern geleitet, die bei jeder Weiterleitung verzögern und die Nachrichten neu ordnen. Deine Nachricht kann dann immer noch anhand ihrer Größe verfolgt werden. Denn normalerweise verringert sich die Größe einer Nachricht um einen kleinen (und ungefähr bekannten) Betrag bei jeder Weiterleitung. Auch wenn Deine Nachricht mit den anderen durch den Remailer vermischt wird, so bleiben doch alle Nachrichten unterscheidbar. Es ist zwar auch möglich, jeden Remailer eine Auffüllung (Padding) am Ende der Nachricht entfernen zu lassen, aber auch hierdurch kann nur eine Verkleinerung der Nachricht erreicht werden, und auch nur bis hin zu der Menge an Nutzdaten, die transportiert werden. Außerdem besteht die Gefahr, daß besonders große Nachrichten auffallen, die aber nötig wären, um bei jeder Weiterleitung einen bedeutenden Größenunterschied zu erreichen, um möglichst gut zu verwirren. Obwohl also das Entfernen eines Padding die Analyse des Nachrichtenverkehrs stark erschwert, sickert einige Information nach wie vor durch. Alle Nachrichten, die einen Remailer größer verlassen, als Deine Nachricht ihn erreicht hat, sind garantiert nicht Deine. Außerdem fallen alle Nachrichten auf, die ihre Größe um mehr als den üblichen Betrag ändern, wenn diese Funktion selten benutzt wird. Die Lösung ist offensichtlich: Jede Nachricht sollte exakt die selbe Größe haben.

Replay-Angriff

Leider können neugeordnete ununterscheidbare Nachrichten immer noch verfolgt werden. Der entsprechende Angriff kann sowohl benutzt werden, um eine Nachricht zu ihrem Ziel zu verfolgen, als auch, um vom Ziel einer Nachricht aus den Absender zu ermitteln. Beide Techniken bedienen sich einer Art des Spam-Angriffs. Um eine Nachricht durch eine Kette von Remailern zu ihrem Ziel zu verfolgen, fängt der Angreifer die Nachricht ab und sendet dann viele Kopien davon an den ersten Remailer. In der Folge wird dieser Remailer ebenso viele identische Nachrichten an den nächsten Remailer weiterleiten. Dieser Stoß an Remailer-Nachrichten zeigt die Route zum Empfänger auf. Werden die Nachrichten durch Neuordnung zu stark verteilt, kann die Nachricht immer noch zwischen zwei Remailern erneut abgefangen werden, um wiederum viele Kopien von ihr weiterzusenden.

Um diesen Angriff abzuwehren, dürfen Remailer keine Nachricht mehr als einmal weiterleiten. Dies kann z.B. durch das Einfügen einer zufälligen ID-Nummer, die der Remailer speichert, für jedes Weiterleiten geschehen. Hieraus ergeben sich zwar große Anforderungen an die Speicherkapazität des Remailers, diese können aber eingeschränkt werden, wenn alte IDs gelöscht werden oder der Schlüssel des Remailers regelmäßig geändert wird (dann können auch alle gespeicherten IDs gelöscht werden). Eine bessere Lösung ist, ein anonymes eCash-Porto auf jeder Ebene zu fordern. Wird die Nachricht erneut geschickt, so wurde das Porto bereits aufgebraucht, und der Remailer würde die Weiterleitung ablehnen. Das hat auch den Vorteil, daß Spams teuer werden und die Operatoren motiviert werden, gute Dienste anzubieten. (Anm. d. Übers.: Eine preiswertere Lösung ist, nur PGP-signierte Nachrichten zu akzeptieren, die ein gewisses Alter noch nicht erreicht haben. Anhand der Signatur kann erkannt werden, ob diese Nachricht bereits verschickt wurde.)

Mixmaster

Derzeit gibt es nur einen Remailer des Typs 2, nämlich Mixmaster. Der Entwurf des Systems wurde stark durch Chaums Arbeit über digitales Mischen beeinflußt (daher der Name). Unten findet sich ein Diagramm, das die Struktur eines Mixmaster-Paketes skizziert. Allerdings gibt es im richtigen Paket nicht nur 4 Header wie dargestellt, sondern 20. Nachrichten werden als ein oder mehrere Pakete verschickt (Nachrichten, die aus mehreren Paketen bestehen, werden Multi-Part-Nachrichten genannt). Im Diagramm werden Verschlüsselungsebenen durch eine Anmerkung links vom Objekt dargestellt. Der letzte Schlüssel in der Liste wäre der erste, der angewendet wird. Die dargestellte Reihenfolge ist dieselbe, mit der die Schlüssel benutzt werden, um die Nachricht zu entschlüsseln.

Abbildung 2

Wenn der Remailer A die Nachricht erhält, entschlüsselt er das mit RSA verschlüsselte Paket ganz oben und schaut, ob er die angegebene ID bereits kennt. Wenn ja, wird die Nachricht verworfen. Wenn nein, wird der erste Header vor seiner Entschlüsselung an das Ende der Liste der Header gehängt und alle anderen eine Position nach oben geschoben. Alle Header und der Rumpf (der Abschnitt am Ende mit den Nutzdaten) werden dann mit dem 3DES-Schlüssel, der im Header gefunden wurde, entschlüsselt. Hierbei kommt der mit RSA verschlüsselte Header für den nächsten Remailer (nun ganz oben) zum Vorschein, während der gerade verarbeitete Header (nunmehr ganz unten) unwiederbringlich verschlüsselt wird. Mixmaster verwendet hierbei Three Key Triple DES (3DES) für die Verschlüsselung der Daten und 1024-Bit RSA für die Public-Key-Verschlüsselung der 3DES-Schlüssel.

Der Header für den letzten Remailer in der Kette beinhaltet eine Kennung, daß dies die letzte Weiterleitung ist und ob es sich um eine Multi-Part-Nachricht handelt. Trifft letzteres nicht zu, so wird der Rumpf entschlüsselt und die Nachricht wird im Klartext im Reordering-Pool des Remailers plaziert. Handelt es sich um einen Teil einer mehrteiligen Nachricht, so wird die ID der Nachricht benutzt, um die anderen Teile zuzuordnen, wenn sie eintreffen. Sind alle Teile eingetroffen, wird die Nachricht zusammengesetzt und im Pool plaziert. Treffen nicht alle Teile innerhalb einer bestimmten Zeit ein, werden die vorhandenen Teile verworfen. Lediglich der letzte Remailer in der Kette verfügt über die Information, daß eine Gruppe von Paketen alle Teil einer einzigen Nachricht sind. Alle vorigen Remailer können keine Zuordnung oder Unterscheidung zwischen den Paketen vornehmen.

Alle Mixmaster-Pakete haben exakt die gleiche Länge und alle Bits werden bei jeder Weiterleitung mit einem 3DES-Schlüssel verschlüsselt, so daß ein Beobachter keinerlei Information über die Identität der Nachricht erlangen kann. Auch ein kompromittierter Remailer kann lediglich das vorige und nächste Glied in der Remailer-Kette ermitteln. Nicht bekannt hingegen ist die Anzahl der Weiterleitungen, die dieser vorangingen oder folgen werden (außer beim letzten Remailer natürlich).

Mixmaster-Pakete sind ziemlich groß. Jeder der 20 Header ist 512 Bytes, der Rumpf 10kB lang.

Ausblick

Mixmaster-Remailer, die zu erkennen geben, daß sie Socket-Verbindungen akzeptieren, werden direkt Nachrichten austauschen. Diese Verbindungen werden auf oberster Ebene zusätzlich mit einem 3DES-Schlüssel geschützt sein, der aus einem Diffie-Hellman-Schlüsselaustausch abgeleitet werden wird. Aufforderungen an Remailer-Operatoren, abgefangene Nachrichten zu entschlüsseln, wird so vorgebeugt.

Nichts ist perfekt

Sogar wenn Du ein perfektes Remailer-Netzwerk benutzt, kann Deine Nachricht immer noch verfolgt werden. Schließlich durchwandert nur eine bestimmte Anzahl von Nachrichten das Remailer-Netzwerk an einem bestimmten Tag. Wenn das Versenden einer Nachricht bei Alice üblicherweise mit dem Empfangen einer Nachricht bei Bob in Beziehung steht, dann ist es wahrscheinlich, daß sie ihm Nachrichten schickt. Dies wurde detailliert in mehreren Nachrichten von Hal und Louis Cypher diskutiert. Eine Strategie gegen solche Regelmäßigkeiten ist, nutzlose Nachrichten in die Remailer-Wüste zu schicken, damit keine solchen Zusammenhänge ermittelt werden können. Diese Nachrichten müssen an zufälligen Zeitpunkten verschickt werden, damit die richtigen Nachrichten nicht auffallen.
zur ckzurück © 1996-2024 Lutz Donnerhacke @ IKS GmbH Jena Wednesday | 11.Dec.2024