Mixmaster Remailer

Bei Mixmaster handelt es sich um ein anonymisierendes Peer2Peer-Netzwerk hoher Latenz, d.h. die Nachrichten werden nicht in Echtzeit versendet. Der Verzicht auf die Echtzeitfähigkeit bringt einen hohen Grad an Anonymität.

General

Note: To make it easier for native German speakers to understand this document, some translations have been added to the English part.

Mixmaster, Mixminion and Tor are tools to achieve anonymity or pseudonymity, but exactly what does that mean? Anonymity means that you can do something without enabling other peoples to get hold of your identity. The roles in the scenario are fixed. It is always Alice that wants to communicate with Bob. Usually Alice is human and Bob is either a computer (e.g. webserver) or human as well. Eve is trying to eavesdrop (belauschen) on them. To be more precise, Eve wants to find out that Alice and Bob are communicating with each other.

In addition to anonmity, pseudonymity also requires that you can assume a fictitious name and be recognized by that name without anybody knowing your real identity. This can be a very important aspect when it comes anonymous communication. Both partners may want to remain anonymous while making sure they are not talking to an impostor (Betrüger/Hochstapler).

Fortunately, pseudonymity can easily be achieved once you have made sure you are anonymous. Just digitally sign everything and everyone will know it really comes from you, without knowing who you really are. As a result, we will only talk about achieving anonymity, knowing that it will also give us pseudonymity.

In the introduction I said that Alice can communicate without Eve knowing who Alice is communicating with. But how much is Eve willing to invest in order to find that out? This is an important question that determines how much Alice has to spend to remain anonymous. Imagine Eve is simply Alice's nosy neighbour. In that case it is rather simple for Alice to ensure Eve does not know she is talking to Bob. However, if Eve is a secret service willing to spend millions of Euros/Dollars on spying, things get a lot more difficult.

So whenever it is stated that you remain anonymous, keep in mind what assumptions have been made about Eve!

Onion Routing

The purpose of low latency anonymization is to make it possible to anonymously use services that require low latencies in order to be usable. Such services include Web browsing, DNS lookups or instant messaging. However, the low latency of the connection allows certain attacks that could be prevented with higher latency systems. In this context, high latency means that the data needs several hours to reach its destination while low latency systems need a fraction of a second or a few seconds.

Anonymous Proxies

The trivial solution is to send Alice's requests through an anonymizing proxy. The proxy would remove all information that might link the data to the sender and forward the message to Bob. A website where such a service is offered is www.anonymizer.com. Using a proxy ensures that Bob does not know Alice's identity. The concept is easy to understand and it obviously works for the mentionned purpose.

Can Alice be sure that the proxy operator does not spy on her? Unfortunately, she cannot. But the approach of the central proxy is based on the assumption that the proxy operator can be trusted. If you cannot trust the proxy operator you will need more sophisticated concepts to keep your privacy.

Since Alice cannot trust in the honesty of the proxy operator, how is she supposed to remain anonymous, what can she rely on? One thing Alice can rely on is that, most likely, independent proxy operators will not cooperate with each other to reveal her identity. In addition to that, it is almost certain that among all proxy operators there is at least one that is honest and does not spy on her.

How can Alice take advantage of that? Assume she has a choice of three proxies X1, X2 and X3. Why not use proxy X1 to connect to proxy X2, and use that connection to connect to proxy X3? If done right, it would mean that only proxy X1 knows Alice and only proxy X3 knows Bob. In addition to that, the operator of proxy X2 would be needed to be able to link both connections to each other since X1 and X3 do not know each other.

Jurisdictional Arbitrage

This approach would also solve another problem that has not yet been addressed. The proxy operator may not want to spy on Alice, but a national court or intelligence service may have forced him to do so and to not tell Alice about it. If all three proxies are located in different countries it becomes much harder for a certain intelligence service to do that.

While one may think that this threat is rather theoretical, the operators of JAP have been forced to log certain requests by German law enforcers. One factor that made this rather easy is that at this time, all JAP proxies were located in Germany. Even though a court eventually ruled that no data needs to be given out, this case demonstrates the importance of spreading a proxy network over many countries.

Tor

"Tor" is short for The Onion Router. It works as a SOCKS proxy for other applications allows them to anomyously communicate with low latency. It is not a peer to peer system since it relies on client server architecture. Yet it is decentral, so the loss of one server will not make the network break down.

Terminology

The basic building block of the Tor network are the ORs, the onion routers. The chain of ORs that connects Alice and Bob are called a circuit. Alice runs a special client software, the OP (onion proxy), that provides the SOCKS proxy for her applications. The directory servers are used to keep track of the ORs. That is necessary, because anyone can operate an OR and join the network. Obviously, the Tor network contains more than just three ORs and one directory server.

Challenges

While the above picture looks very simple, there are a number of problems that need to be addressed:

- Can Alice trust the directory server?

- How do you build a circuit without compromising your anonymity?

- Alice needs to make sure only the last server knows will see the message for Bob (that message may be encrypted, but that is irrelevant).

- ORs should only know their successor (Nachfolger) and predecessor (Vorgänger).

- What happens if Eve operates some of the ORs?

Directory Servers

One thing that every OP knows in advance are the public keys an IP addresses of the directory servers. When the OP wants to connect to a number of ORs it asks one directory server for the current list. The server will then tell the OP the IP addresses and the public keys(!) of all ORs. However, the OP will only trust this list if it has been digitally signed by other directory servers. That way no single operator can forge the list of ORs. Currently the Tor network only has three directory servers. One operated by the people from noreply.org and two others located at the MIT.

Building a Circuit

The two things that are crucial for building a circuit are Diffie-Hellman key exchange (DHKE, deutsch) and the public key of the OR that the OP received from the directory server. The purpose of the DHKE is to allow "two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher." (Wikipedia)

The only problem is that DHKE is vulnerable (angreifbar) to man-in-the-middle attacks. You establish a shared secret key with somebody, but is that somebody really the OR that you wanted to connect to? This is where the public key comes into play. Since only the real OR knows the corresponding secret key, it can prove its identity.

So what do we have now? We have an encrypted connection to onion router X1, and we have verified that this really is X1 and not an impostor (Betrüger). This connection to X1 can now be used to connect to X2. We simply tell X1 to connect to X2, making sure that X2 never knows our IP address. We could continue until we have a circuit of hundreds of ORs. But as we will see later that would not significantly increase the level of anonymity. Unless configured otherwise, Tor uses three ORs for a connection.

Routing

Since there are significantly more users of Tor than ORs, every OR is part of multiple circuits. Because the OR needs to know where it should send a unit of data (called cell in Tor lingo), every cell must contain some kind of routing information that tells the OR what to do without revealing the structure of the circuit! This has been solved by so called circIDs, that are assigned to all cells. Onion router X1 for example associates the circIDs 78 and 42 with each other. Whenever it receives a cell with circID 78 it will change the circID to 42 and forward the cell to X2. X2 will then switch the circID to 17 and send the cell to X3. X3 knows that when it receives a cell with circID 17 it must pass the data on to Bob.

That way the cell never contains the entire routing information, let alone final destination. Additionally, once the connection is closed the ORs forget about the circIDs for that connection. That makes it impossible to backtrace (zurückverfolgen) the connection once it is closed.

Using the Circuit

When Alice wants to send a cell over her circuit, she first encrypts it with the secret key that she shares with the last OR in the circuit, Xn. She takes the result and encrypts it for Xn-1, continuing until she encrypts the cell for the first OR in her circuit. The resulting cell looks like this:

The onion-like structure of the message is what gave onion routing its name. As the cell passes through the circuit, each OR removes one layer of encryption. Only the last OR gets to see the final message, all the previous one just saw some encrypted message. But why not just encrypt it for X3? That way X1 and X2 would not have to perform the computionally expensive decryption. The reason is that by constantly mangling the packet it gets harder to trace because they always look different when they leave an OR.

Bob's reply reaches Alice in a similar way. Every OR encrypts the cell with the key it shares with Alice, producing a cell that looks like this:

The reason for the encryption at each hop is the same as above. Alice can remove all the encryption layers from the message since she knows all the keys.

Geschichte anonymisierender Remailer hoher Latenz

Allgemein gesagt haben die Remailer den Zweck den Nachrichtenverkehr entweder zu pseudonymisieren und/oder zu anonymisieren. Ein Remailer nicht verschlüsselte oder unverschlüsselte Nachtrichten an und leitet sie weiter.

Die Evolution brachte im Laufe der Zeit folgende Typen bzw. Generationen von Remailern zustande:

Typ 0: Nym Remailer

Altername Namen sind Nym Server oder Pseudonym Server. Diese Server ermöglichen bidirektionale Kommunikation zwischen den Kommunikationspartnern. Im Extremfall kennt keiner der Kommunikationspartner die Identitä des anderen (bei neueren Generationen der Nym Remailer). Wenn ein Nym Remailer (der älteren Generation) eine Nachricht erhält, entfernt er die Headerinformationen und ersetzt die Originalangaben zur Identität des Absendern durch sein Pseudonym. Anschliessend leitet er die Nachricht an den Empfänger weiter. Dieser hat die Möglichkeit an das Pseudonym zu antworten, d.h. die Antwortnachricht geht beim Nym Server ein. Dieser und nur dieser kennt die Zuordnung des Pseudonyms zu der realen Adresse/Identität, ersetzt das Pseudonym durch die reale Adresse und stellt die Anwort dem ursprünglichen Absender zu. Die Technick der Zuordnung von Pseudonym (und der Pseudonymadresse) zu der Realadresse (und der entsprechenden Identität) entscheidet über die Sicherheit d.h. den Grad der Anonymität. Weil frühe Nym Server und damit ihre Betreiber die wahre Identität der Absender kennen, spricht man hier von Pseudonymisierung statt von Anonymisierung. Somit basiert das System eher auf Vertrauen als auch durch technologische Verfahren herbeigeführter Sicherheit. Bei den aktuellen Nym Servern kennt nicht mal der Betreiber die Identität der Benutzer. Sie nutzen die Technologie der Typ1- und Typ 2-Remailer. Erster öffentlicher Pseudonym-Remailer wurde ab 1993 von Johan Helsingius unter anon.penet.fi betrieben. Er musste wenige Jahre später aufgrund von Klagebeschwerden und Gerichtsbeschlüssen abgeschaltet werden.

Typ 1: Cypherpunk Remailer

1990 entwarf eine Gruppe von Internetpionieren, die sich selber Cypherpunks nannten, das Modell eines anonymisierenden Netzwerks, das auf den Ideen und Vorschlägen von David Chaum fussten. Beim Nachrichtenversand werden ausgewählte Cypherpunk-Remailer zu einer Weiterleitungskette unter Benutzung von PGP-Verschlüsselung. Die Kommunikation zwischen den Cypherpunk Remailern basiert auf dem normalen E-Mail-Protokoll (SMTP/POP3/MIME-Format). Schwächen der Cypherpunk Remailer:

• Remailer sendet die Nachrichten nach Erhalt sofort weiter - durch Zeit- und Größemanalyse ist die Zuordnung von Empfänger zu Absender leicht möglich
• Replay-Attacken (chosen-ciphertext attack) sind möglich. Bei den Replay-Attacken wird ein Nachtrichtenpacket, desen Weg nachvollzogen werden soll vor dem ersten Passieren des Remailers kopiert. Nach dem ersten Passieren des Remailers wird der ausgehende Datenverkehr mitgeschnitten. Anschliessend wird die Kopie des Nachrichtenpackets an den Remailer geschickt und der ausgehende Datenverkehr wieder mitgeschnitten. Durch die Schnittmengen der beiden ausgehenden Datenmengen kann man dir Zuordnung des ausgehenden Packets zum eingehnen treffen.

Diese und viele weitere Schwächen wurden von Lance Cottrell erkannt und publiziert. Man kann sich spontan mögliche Lösungen der obigen Probleme finden, die aber wieder neue Probleme aufwerfen:

• Um die durch zeitliche Analyse leicht mögliche Zuordnung eines aus einem Remailer ausgehenden Packets zu seinem eingehenden Pendant zu verhindern, könnte man eine Verzögerung beim Weiterleiten einbauen. Diese ist allerdings keine große Hilfe bei wenig Datenverkehr im Netzwerk.
• Man könnte die eingehenden Packete zunächst in einem Puffer anhäufen, ihre Reihenfolge zufällig umsortieren und anschliessend die Packete aus dem Puffer weitersenden. Diese Strategie ist zwar nicht mehr durch einfache Zeitanalyse zu untergraben, ist aber den sogenannten Flooding-Attacken unterworfen. Dabei wird vom Angreifer der Eingangspuffer des Remailes mit eigenen Packeten überhäuft, so dass nach dem Aufzeichnen des ausgehenden Datenverkehrs das fremde Packet wie ein schwarzes Schaf auf einem weissen Feld ausfällt.
• Der Remailer könnte den Replay-Attacken damit begegnen, dass er sich die ID's der Packete merkt und ein zweites Packet mit dergleichen ID ablehnt.

Hier wurden einige Ideen aufgezeigt, wie die Schwächen der Cypherpunk-Remailer geschlossen werden können, es bleibt trotzdem das Problem, dass durch das Entfernen von Verschlüsselungsschichten die Packete beim Traversieren durch das Netzwerk immer kleiner werden und somit ihre aktuelle Position innerhalb der Weiterleitungskette abgeschätz werden kann.

Typ 2: Mixmaster Remailer

Bei Mixmaster Remailern handelt es sich um eine Weiterentwicklung von Cypherpunk Remailern mit dem Ziel, die oben erwähnten Schwächen zu beseitigen. Das Protokoll ist seit 1995 im Internet gebräuchlich. Die wesentlichen Ideen und Verbesserungsvorschläge stammen von Lance Cottrell (der gleichzeitig auch der Gründer und Präsident von Anonymizer Inc. ist). Die Netzwerktopologie entspricht der des Cypherpunk Remailer Netzweks - ein Netz aus gleichgestellten Servern, denen Clients gegenüberstehen. Es gibt keinen zentralen Verzeichnisserver, wodurch eine Informationsasymmetrie über die im Netz vorhandenen Remailer entsteht. Das nicht gleichverteilte Wissen über aktuelle Server kann zur Unterwanderung der Anonymität ausgenutzt werden und stellt eine der Schwächen des Systems dar. Es existiert Client-Software für verschiedene Betriebssysteme und viele Mixmaster-Server können auch Cypherpunk-Nachrichten verarbeiten, indem sie in das Mixmaster-Format 'verpackt' werden.

Typ 3: Mixminion

Mixminion ist eine Weiterentwicklung der Mixmaster Remailer, die die Möglichkeit von anonymen Antworten auf anonyme Nachrichten durch Verwendung von sogenannten Single-Use-Reply-Blocks eröffnet. Weiterhin wird die Sicherheit der Anonymität noch weiter verbessert, und es wird der Informationsasymmetrie bezüglich aktueller Remailer-Server im Netzwerk durch redundante Directory Server begegnet.

Mixmaster Remailer

Mixmaster Remailer ist ein Typ 2 Remailer (und das entsprechende Protokoll), dass inspiriert durch die Ideen und Verbesserungsvorschläge von Lance Cottrell aus dem Cypherpunk Remailer hervorgegangen ist. Die zugrunde liegenden Ideen für anonymisierende Netzwerke aus Remailern stammt von David Chaum. Ein Mixmaster-Netzwerk besteht aus einer Menge gleichgestellter Server (im Folgenden als Remailer bezeichnet) und Clients, die Nachrichten über das Netzwerk versenden und empfangen. Das Netzwerk besitzt keinen zentralen Verzeichnisserver mit der Information über alle aktuell im Netz verfügbaren Remailer, allerdings haben viele Betreiber von solchen Remailern Webseiten mit einer Liste von den ihnen bekannten Servern, deren Adressen und aktuellen Schlüsseln. Das Mixmaster Protokoll ist im Internet seit 1995 verbreitet und es existieren für verschiedene Betriebssysteme entsprechende Software. Viele Mixmaster Remailer können auch Cypherpunk Nachrichten empfangen und weitersenden bzw. zustellen. Beim Weitersenden werden solche Nachrichten in das Mixmaster-Format verpackt, um vom höheren Grad der Anonymität profitieren zu können. Vor dem endgültigen Zustellen werden sie wieder entpackt und wie gewöhnliche Cypherpunk Nachrichten behandelt.

Bei Mixmaster haben alle Packete die gleiche Größe. Bereits die Client-Software zerteilt die Nachrichten in kleine Packete von ca. 20KByte. Wenn die Nachricht kleiner ist, wird sie auf diese Größe aufgefüllt.

Die Public-Key-Verschlüsselung ist fester Bestandteil des Protokolls, so dass der Remailer nur seinen Vorgänger und Nachfolger kennt. Dabei wird jedes Packet vor dem Versenden mit öffentlichen Schlüsseln der Remailer verschlüsselt, die es auf dem Weg passiert. Dadurch legen sich um das Packet Verschlüsselungsschichten ähnlich den Schalen einer Zwiebel. Kommt ein Packet bei einem Remailer an, kann dieser mit seinem privaten Schlüssel nur die oberste Verschlüsselungsschale entfernen. Dabei werden Informationen freigelegt, wohin das Packet als nächstes weitergeleitet bzw. an welche Zieladresse es zugestellt werden soll.

Der Sender legt sich für eine Kette von Remailern fest, wobei verschiedene Packete einer Nachricht über unterschiedliche Ketten versendet werden. Dabei muss jeweils der letzte Remailer gleich sein. Er ist der einzige, der die Zuordnung der verschiedenen Packete zu einer Nachricht treffen kann. Hier wird die Nachricht wieder zusammengesetzt und an den Empfänger zugestellt.

Remailer haben einen Nachrichtenpool einstellbarer Größe, in dem eingehende Packete gesammelt und vor dem Weiterleiten zufällig umsortiert werden. Weiterhin werden Dummy Packete erzeugt bei:

• zu wenig Datenverkehr
• Eingang eines neuen Packets
• beim Weitersenden von Nachrichten

Dummy Packete passieren einige wenige Remailer und werden später von anderen Mixmaster Servern zerstört.

Es ist auch möglich Kopien einer Nachricht über verschiedene Remailer Ketten zu versenden. Der letzte Remailer zerstört nach erfolgreicher Zustellung einer Kopie das Duplikat. Das Duplikat wird anhand einer Nachrichten-ID erkannt.

Remailer merken sich die ID's verarbeiteter Packete in einem Cache. Dadurch wird Replay Attacken begegnet (siehe auch Schwächen von Mixmaster). Ursprünglich existierte der Ansatz, die Packete mit Zeitstempeln zu versehen, um Replay Attacken verhindern zu können. Allerdings entstand damit das Problem, dass bei zu kurz in der Zukunft liegenden Zeitstempeln der Timeout-Zeitpunkt überschritten wird, noch bevor das Packet an seinem Zielort ankommt. Bei zu lange in der Zukunft liegenden Zeitstempeln werden im Netzwerk Packete, die kurz vor dem Ablauf ihres Timeouts stehen selten. Nun kann ein Angreifer folgenden Angriff fahren: er hält das Packet, deren Weg durch das Netzwerk er nachvollziehen möchte, eine Zeit lang fest und schickt es anschliessend weiter auf die Reise. Wenn später im Netzwerk ein Packet auftaucht, deren Zeitstempel kurz vor dem Timeout ist, ist die Wahrscheinlichkeit gross, dass es sich um das zu verfolgende Packet handelt.

Ein Packet kann auf seinem Weg durch das Netzwerk maximal 20 Remailer passieren.

Packetaufbau

Ein Mixmaster-Packet besteht aus einem Header, der widerum in Header Sections eingeteilt ist, und einem Body. Jede Header Section ist 512 Byte lang. Allgemein gilt für zwei beliebige Packete, dass alle ihre Felder die gleiche Größe haben. Dadurch werden die Packete anhand dieses Aspekts nicht unterscheidbar. Alle Header Sections (ausser der ersten) sowie der Body sind symmetrisch mit dem sogenannten Session Key verschlüsselt.

Ein Remailer erhält ein Packet, entschlüsselt die erste Header Section mit seinem privaten Schlüssel und entschlüsselt den encrypted header part. Die Packet-ID wird zu Duplikaterkennung herangezogen (siehe auch Replay Attacken). Der 3-DES-Key wird zur Entschlüsselung der restlichen Header Sections und des Body verwendet.

Der packet type identifier kann folgende Werte annehmen:

• 0 - Es handelt sich um einen Zwischen-Remailer, der das Packet annehmen und an den nächsten Remailer weiterleiten soll
• 1 - Es handelt sich um den letzten Remailer in der Kette. Das aktuelle Packet ist bereits die ganze Nachricht.
• 2 - Es handelt sich um den letzten Remailer in der Kette. Das aktuelle Packet ist nur ein Teil der Nachricht.

message digest ist eine MD5-Checksumme des kompletten vorangegangenen Teils des Headers. Checksumme des nochfolgenden Teils ist nicht möglich, da der Header beim Passieren eines jeden Remailers nach dem Entfernen der äußeren Verschlüsselungsschale mit zufälligen Daten aufgefüllt wird, um seine Größe kostant zu halten und damit keine Rückschlüsse auf die aktuelle Position des Packets innerhalb der Remailerkette zu verraten.

packet information ist vom Inhalt des packet type identifier abhängig:

• Handelt es sich um einen Zwischenremailer, steht hier die Adresse des nächsten Remailers.
• Handelt es sich um den letzten Remailer in der Kette, und die Nachricht besteht nur aus diesem Packet, enthält dieses Feld die Message-ID
• Handelt es sich um den letzten Remailer in der Kette, und die Nachricht besteht aus noch weiteren Packeten, sind hier die Packetnummer, Anzahl der Packete und die Message-ID vermerkt.

Vor dem Weitersenden (durch einen Zwischenremailer) wird die erste Header Section entfernt, alle anderen hochgeschoben und am Ende des Headers Datenmüll angehängt. Dadurch bleibt die Größe des Packets immer gleich und für einen Remailer ist seine Position innerhalb der Kette nicht erkennbar.

Vor dem Weiterleiten (durch einen Zwischenremailer) wird das Packet als Base-64 encodiert.

Es gibt drei Arten von Mixmasternachrichten:

• E-Mails
• Usenet Nachrichten
• Dummy Nachrichten

Aufbau des Packetnutzinhalts (Body):

Das Feld destination field kann folgende Werte enthalten:

• null - es handelt sich um eine Dummy Nachricht.
• post - es handelt sich um eine Usenet Nachricht.
• post:[newsgroup] - es handelt sich um eine Usenet-Nachricht.
• [email-adress] - es handelt sich um eine E-Mail
• leer - es handelt sich um eine E-Mail, wobei der Nutzinhalt bereits einen "To:"-Header enthält, in dem die Empfängeradresse steht (siehe Internet Message Format - RFC2822).

Das Feld user data section:

• kann komprimiert sein (sollte nur genutzt werden, wenn der letzte Remailer es unterstützt)
• kann Inhalt nach FRC2822 (Internet Message Format) sein (E-Mail oder Usenet-Nachricht)
• kann beides gleichzeitig sein

Nachrichtenpool und Dummy Nachrichten

Der Remailer sammelt eingehende Packete in einem Nachrichtenpool. Ein Pooling Schema (auch dynamic pooling schema' genannt) wird zur Verhinderung der Zuordnung von eingehenden zu ausgehenden Packeten benutzt. In regelmäßigen Abständen (t) sendet der Remailer zufällige Packete aus dem Pool an andere Remailer oder an einen Endempfänger.

Alle t Sekunden werden folgende Aktionen ausgeführt:

1. n := Anzahl der Packete im Pool
2. count := min(n-min, n*rate) (im Extremfall 0)
3. zufällige Auswahl count-vieler Nachrichten aus dem Pool und versendet sie

In der Standardkonfiguration ist t=15 min., min=45 Packete und rate=65%. Jedes Mal, wenn ein neues Packet in den Pool eingereiht wird oder ein Teil des Pools durch das Weiterversenden von Packeten geleert wird, erzeugt ein Remailer eine zufällige Zahl an Dummy-Packeten im Pool. Dieses Vorgehen schützt das System vor Flooding Attacken, bei denen der Angreifer den Remailer mit eigenen Nachrichten (deren entpackte Version er natürlich kennt) überhäuft, um ein zu beobachtendes Packet im Ausgangsdatenverkehr identifizieren zu können. Dummy Packete sind multi-hop, d.h. sie passieren mehrere zufällig ausgewählte Remailer (meist vier).

Schlüssel und Remailer-Fähigkeiten

Das Mixmaster Netzwerk besitzt kein zentrales Verzeichnis aller sich im Netzwerk befindenden Remailer. Um einen Remailer als Teil einer Remailerkette verwenden zu können, benötigt man zusätzlich zu der Adresse auch den aktuell gültigen öffentlichen Schlüssel sowie Informationen über die Fähigkeiten, Zuverlässigkeit und Sicherheitsbestimmungen des entsprechenden Remailers. Folgende Remailer-Fähigkeiten sind allgemein verbreitet:

• C - Remailer kann mit komprimierten Inhalten umgehen
• M - Remailer ist nur ein Zwischenremailer, d.h. er stellt nicht zu, sondern leitet nur weiter
• Nm - Remailer unterstützt Usenet-Postings über Mail-2-News-Gateway
• Np - Remailer unterstützt direktes Usenet-Posting

Es existieren mehrere Möglichkeiten, Informationen über einen bestimmten Remailer in Erfahrung zu bringen. Die manuelle Lösung besteht darin, an den Remailer eine E-Mail mit einem bestimmten Betreff zu schicken. Der Inhalt des Betreffs bestimmt die Art der Informationen, die man in einer automatischen Antwortmail erhält:

• remailer-help - Informationen über die Benutzung des Remailers
• remailer-key - aktueller öffentlicher Schlüssel des Remailers
• remailer-stats - Informationen über die Zahl der Nachrichten, die der Remailer pro Tag bearbeitet
• remailer-conf - lokale Konfiguration des Remailers, z.B. die verwendete Softwareversion, unterstützte Protokolle, verbotene Header (Nachrichten-Header, die durch die Remailer herausgefiltert werden, um die Möglichkeit der Vortäuschung falscher Identität vorzubeugen) sowie gesperrte Newsgroups und Domänen
• remailer-adminkey - OpenPGP-Schlüssel des Remailer-Administrators bzw. -betreibers

Eine wesentliche bequemere Lösung benutzt die Informationen eines Tools namens Echolot. Viele Remailerbetreiber betreiben auf ihren Servern das Programm Echolot Echolot, das ein Pinger für anonyme Remailer ist. Ein Betreiber von Echolot pflegt eine Liste der ihm bekannten Remailer, die von Echolot in regelmäßigen Zeitabständen zu statistischen Zwecken (Performance, Zuverlässigkeit, Up-Time) angepingt werden. Weiterhin werden die aktuellen Schlüssel und diverse Konfigurationsinformationen (siehe oben) abgefragt. Diese Informationen können entweder über ein Webinterface einsehen oder in Dateiform (pubring.mix - Liste öffentlicher Schlüssel; type2.list - Liste mit Remailer-Fähigkeiten) heruntergeladen werden, um die Datenbasis des lokalen Remailer-Clients zu aktualisieren.

Anworten über Nym-Server

Das Mixmaster Protokoll sieht in seiner Spezifikation keine Möglichkeiten vor auf die anonymen Nachrichten zu antworten. Unter der Verwendung von modernen Nym-Servern kann jedoch eine Kommunikation auf der Basis von Nachrichten und entsprechenden Antworten aufgebaut werden. Um die Möglichkeit anonymer Antworten nutzen zu können, muss der Sender bei einem Nym-Server einen Nym-Account haben. Das Erstellen eines Nym-Accounts geschieht durch das Senden von speziell strukturierten anonymen E-Mails (z.B. über das Mixmaster Remailer Netzwerk). Der Nym-Account besteht im Wesentlichen aus einer Pseudonym E-Mailadresse und einer Menge von Reply-Blöcken, die jeweils einen durch das Zwiebelschalenprinzip verschlüsselten Weg durch das Mixmaster Remailer Netzwerk zurück zu dem Sender beschreiben. Wenn der Empfänger einer Mixmaster Nachricht auf diese antwortet (dabei erstellt er eine ganz normale Mixmaster Nachricht, die an die Pseudonymadresse des Senders adressiert ist und anonymisierend über mehrere Mixmaster Remailer traversiert), geht die Anwort an die Pseudonym E-Mailadresse des Senders d.h. an den Nym-Server zurück. Der Nym-Server empfängt die Nachricht und leitet sie unter Verwendung eines unter dem entsprechenden Nym-Account hinterlegten Reply-Blocks (dieser enthält zwiebelschalenartig verschlüsselten Weg durch das Mixmaster Remailer Netzwerk zu dem Ersteller des Reply-Blocks bzw. dem Inhaber des Nym-Accounts). Immer denselben Reply-Block und damit denselben Weg (d.h. Kette von zu passierenden Remailern) zu verwenden, wäre nicht sehr sicher. So kann man unter dem Nym-Account mehrere Reply-Blöcke hinterlegen und Wahrscheinlichkeiten für jeweilige Verwendung angeben. Ebenfalls kann man den Nym-Server Kopien einer und deselben Nachricht über unterschiedliche Wege (d.h. unter Verwendung unterschiedlicher Reply-Blöcke) mit einer Zeitverzögerung versenden lassen, um die Zuverlässigkeit der Zustellung zu erhöhen. Weiterhin ist es wie bei normalen Mixmaster Nachrichten möglich, als Zustellziel in einem Reply-Block statt einer E-Mail-Adresse eine Newsgroup anzugeben, an die der (verschlüsselte) Inhalt gepostet werden soll.

Das Bild zeigt zwei Konfigurationen von Nym-Accounts. Die erste Konfiguration enthält zwei Reply-Blöcke - der erste hat eine E-Mailadresse als Ziel und der zweite eine Newsgroup. Die Kopie der Nachricht wird an die Newsgroup mit einer Verzögerung von einer Stunde versendet. Die zweite Konfiguration enthält drei Reply-Blöcke - mit einer Wahrscheinlichkeit von 75 Prozent wird die Antwortnachricht sofort und unter Verwendung des ersten Reply-Blocks weitergeleitet. Die Kopie, die eine Stunde später versendet wird, benutzt mit gleichverteilter Wahrscheinlichkeit den zweiten oder dritten Reply-Block.

Missbrauch und Vorbeugung

Der Nutzinhalt einer Mixmasternachricht kann im Internet Message Format (RFC 2822) verfasst sein. Dieses Format erlaubt die Definition der Nachrichten-Header. Auf diese Weise kann der Absender einer Mixmaster Nachricht einen eigenen Wert zum Beispiel für den From-Header angeben und damit dem Empfänger eine falsche Identität vortäuschen. Um dieser Art von Missbrauch vorzubeuben, filtern zustellende Remailer (letzte in der Kette) diverse Header bzw. versehen diese mit einem eigenen Wert. Weiterhin werden oft weitere Header hinzugefügt, die dem Empfänger als Ursprung der E-Mail das anonymisierende Remailernetzwerk kenntlich machen. Im folgenden Bild sieht man, dass der Remailer den From-Header mit seiner eigenen Adresse ersetzt hat sowie einen Comments-Header hinzugefügt hat.

Für den Fall, dass ein Empfänger von Massenmails bombardiert wird, fügen einige Remailer einen E-Mail-Header hinzu, der auf die Möglichkeit, die Zustellung von E-Mails an den besagten Empfänger durch den Remailer abzustellen, hinweist. Oft wird dabei auf eine Webseite mit weiteren Informationen verwiesen. Letztendlich genügt eine E-Mail an den Administrator des Remailers, um die Zustellung von Massenmails zu unterbinden. Damit dieses Vorgehen nicht missbraucht werden kann, um jemanden am Empfang von Mixmasternachrichten zu hindern, wird oft eine Bestätigungsmail versendet.

Mixminion

Überblick

Mixminion stellt eine Erweiterung vom Mixmaster dar, gewährt dabei Abwärtskompatibilität. Sie werden auch als Typ3-Remailer bezeichnet. Mixnetze können gemischt aus Mixmaster- sowie Mixminionservern bestehen. Beim Typwechsel muss das Paket gegebenenfalls geremixed werden.

Unterschiede zu Mixmaster

• benutzt Directory-Server
• benutzt TLS anstelle von SMTP
• besitzt Key Rotation
• bis zu 32 anstelle von 20 Hops
• Replymessages mittels Singleusereplyblocks
• Ununterscheidbarkeit zwischen Forward- und Replymessages

Directory Server

Die Directory Server geben Auskunft über die Struktur des Netzwerkes. Sie kommunizieren über eine dedizierte Verbindung (auch: Heartbeat) über welche sie sich gegenseitig über die Stuktur des Netzwerkes aktualisieren.
Möchte ein Benutzer eine anonyme E-Mail versenden, so hat kann er von einem sich Directory Server die Information über die aktuelle Netzwerkstruktur beschaffen. Diese Beschreibnung wird von weiteren Directory Servern signiert um die Authenzität zu sichern.
Andernfalls wäre ein einfacher Angriff möglich, indem ein Angreifer nur Mix-Server listet, welcher unter seiner eigenen Kontrolle laufen. Das Ergebnis wäre die Möglichkeit, augenblicklich sämtliche Hüllen des Headers und der Nachricht dekodieren und erlangt Zugriff auf die Nachricht (falls nicht anderweitig kodiert), als auch Absender und Empfänger.
Es fällt in den Aufgabenbereich der Mixminionserver sich bei bei einem Directory Server zu authentifizieren.

Key Rotation

Während bei Mixmaster die Public Keys der einzelnen Mixserver statisch sind hat ein solcher öffentlicher Schlüssel bei Mixminion eine Gültigkeitsspanne. Die jeweils aktuellen Schlüssel werden durch die Directory Server publiziert. Läuft ein Schlüssel ab, so nimmt ein Remailer nach Ablauf einer zusätzlichen Spanne keine Pakete die mit diesem Schlüssel kodiert sind an bzw. verwirft sie. Dies führt dazu, dass die Headder-ID des Paketes aus den Caches der einzelnen Remailer gelöscht werden kann, da eine Replayattacke nun nicht mehr möglich ist.
Diese gewonnene Sicherheit geht mit Einbußen im Komfort daher und so folgt, dass Replyblöcke im nach gewisser Zeit ihre Gültigkeit verlieren und ein verspätetes Antworten auf eine anonyme Nachricht somit verhindert.

Reply Messages & Single-Use-Reply-Blocks

Single-Use-Reply-Blocks werden vom Versender ausgestellt. Sie sind zwiebelschalenförmig kodierte Header und beschreiben den Weg von einem Eintrittspunkt in das Mixnet zu eben jenem Ersteller. Aufgrund der Key-Rotation ist ihre Gültigkeit zeitlich begrenzt. Dieser Block kann einer Nachricht angehängt und beim Empfänger dazu verwendet werden zu antworten, er kann aus maximal 16 Hops bestehen, sich also nur über die ein "Leg" erstrecken.
Mixminion bietet drei verschiedene Typen von Nachrichten:

• Forward-Messages
• Direct-Reply
• Anonymized Reply

Forward-Messages
Hierbei handelt es sich um simple Pakete, bei welchem dem Absender die Kontaktadresse des Gegenübers bekannt ist. Sie bieten keine Option zu antworten. Es können beide Header, H1 und H2, zur Wegbeschreibung durch das Mixnet verwendet werden.

Direct-Reply
Erhält jemand eine anonyme Nachricht, welcher ein SURB beigefügt ist, kann er diesen verwenden und in das erste "Leg" seiner Antwort einfügen. Ihm ist hierbei nicht bewusst wem er Antwortet, noch wie der Weg durch das Mixnet aussieht oder wieviele Hops diese Nachricht beschreibt. Sein Kontaktmensch hat ihm diesen Block ausgestellt und nur er weiss, wie der Weg zu ihm aussieht.

Anonymized-Reply
Hier wird ähnlich der Direct-Reply verfahren, mit dem Unterschied, dass der SURB in das zweite "Leg" der Nachricht fällt. Das erste "Leg" kann der Antwortende nun selbst bestimmen. Somit wird erst dem von ihm gewünschtem Weg durch das Mixnet gefolgt, ist dieser abgearbeitet wird mit dem SURB weitergearbeitet.
Das Verfahren bietet den Vorteil, dass man sich zusätzliche Sicherheit verschaffen kann, wenn man zum Beispiel dem SURB nicht traut.