The Second-Generation Onion Router

Einleitung

"TOR - The 2nd generation Onion Router" ist das Nachfolgeprojekt von den Entwicklern des Onion Routings und setzt somit auch das Zwiebelprinzip um. Dieses bezeichnet ein Verschlüsselungsschema bei dem die Daten über eine ständig wechselnde Route von Knoten (Nodes) geleitet werden. Bei jedem Knoten finden dann Ver- oder Entschlüsselungsoperationen statt, je nachdem ob die Daten ein- oder ausgehen. Diese stufenweise Verschlüsselung führt zum Begriff des Zwiebelprinzips.

Im Vergleich zum Vorgänger, dem Onion Routing, gibt es eine Reihe von Verbesserungen. So konnten Knoten früher den Verkehr aufnehmen und später wieder einspielen - jetzt wird der Verbindungstunnel inkrementell aufgebaut und bei jedem Sprung zum nächsten Knoten ein eigener Session Key ausgehandelt. Sobald diese Schlüssel gelöscht sind, kann der Verkehr nicht mehr entschlüsselt werden. Früher musste für jede Anwendung ein eigener Proxy geschrieben werden - jetzt werden mit dem SOCKS Proxy Interface alle TCP-basierten Programme ohne weitere Modifikation unterstützt. Auch können jetzt mehrere Streams über einen Verbindungstunnel laufen, wodurch man wesentliche Verbesserungen der Performance erreicht.

Das generelle Problem dem sich TOR begegnen will, ist die Überwachung des Internetverkehrs durch die Datenanalyse. Durch diese kann man erkennen, wer mit wem über ein öffentliches Netzwerk kommuniziert hat, was nicht nur in China, sondern überall auf der Welt zu Problemen führen könnte. Der Datenverkehr besteht aus zwei Teilen, der Nutzlast, in der die eigentlichen Daten enthalten sind, und den Kopfteil, in dem sich verschiedene Informationen zum Routing befinden. Auch wenn man die Nutzlast verschlüsselt, enthält der Kopf verwertbare Informationen darüber, wer mit wem kommuniziert hat.

Konzept von TOR

Bezug zu anderen Projekten

Moderne Arbeiten die sich mit anonymen Netzwerken beschäftigen, verwenden zumeist Chaum's MixNet-Design, in welchem man die Korrespondenz von Sender und Empfänger versteckt, in dem man die Nachrichten durch mehrere Schichten von Verschlüsselungen umhüllt und durch einen zufälligen Pfad durch Netz schickt. Im wesentlichen haben sich dabei zwei Richtungen entwickelt. Zum einen high-latency Designs, die eine maximale Anonymität durch hohe und variable Latenzzeiten bieten und größeren Angriffen standhalten, und zum anderen low-latency Designs, zu denen auch TOR gehört, die versuchen den Datenverkeher zu anonymisieren, aber trotzdem noch für interaktive Anwendungen wie IRC oder SSH verwendbar sein sollen. Darum sind sie aber auch leichter anzugreifen, da durch die Fülle an Datenpaketen, die in möglichst schneller Zeit versendet werden sollen, das Abhorchen der Kommunikation wesentlich einfacher ist.

Design-Ziele

TODO

Threat-Modell

TODO

TOR-Design

Onion Router, Onion Proxies und Schlüssel

Tor kann ausschließlich TCP-Streams verarbeiten. Das Netzwerk besteht aus Knoten, den Onion Routern (OR). Darüberhinaus gibt es noch Onion Proxies, welche eine reine Client-Lösung sind, d.h. einen OP installiert sich jeder, der TOR nur benutzen will, jedoch kein dauerhafter Knoten des Netzwerks werden will und auch nicht den Datenverkehr anderer Nutzer weiterleiten will. Onion Router hingegen nehmen auch Datenverkehr von anderen Knoten an und leiten ihn durch das Netzwerk weiter.

Jeder Onion Router besitzt einen Identity Key und einen Onion Key. Mit dem Identity Key werden TLS-Zertifikate und OR-Descriptoren (siehe [Directory Server]) signiert. Der Onion Key wird zur Entschlüsselung von Anfragen anderer Benutzer verwendet und wir auch zum Aushandeln von Sessionkeys für neue Verbindungen benötigt. Es existiert auf link-eben noch ein link-key ( vom TLS-Protokoll ), der hier aber nicht weiter betrachtet wird.

Zellen

Datenpackete werden im TOR-Netzwerk Zellen genannt, haben eine feste Länge/Größe von 512 Bytes und werden wie folgt unterschieden:

Aufbau einer Zelle

Es gibt Controll- und Relay Cells.

Verbindungstunnels und Streams

TODO

Quality of Service

TODO

Rendezvous Points und Hidden Services

TODO

Angriffe und Angriffsabwehr

Design-Vorkehrungen

TODO (Exit-Policies, DOS-Abwehr...)