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 das 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 (Goals)

Anwendbarkeit

Ein sehr wichtiges Ziel des Designs ist es, dass TOR im alltäglichen Gebrauch verwendbar ist. Dafür darf es nicht zu viel Bandbreite des Nutzers beanspruchen, damit dieser noch über eine ausreichende Verbindung ins Netz verfügt. Des weiteren sollte die Installation recht einfach sein. Durch nötige Kernel-Patches oder verschiedene Proxies würde dies unnötig erschwert werden. Außerdem sollten Nutzer nicht dafür haftbar gemacht werden können, wenn über ihre Verbindungen Aktivitäten von Angreifern ausgehen.

Benutzbarkeit

Da schwer benutzbare Systeme nur wenig Nutzer haben, anonyme Netze aber viele Nutzer brauchen um auch anonym zu sein, ist es sehr wichtig, dass TOR einfach zu benutzen ist. Darum sollte man keine anderen Programme wegen TOR modifizieren müssen, keine zu großen Latenzzeiten erzeugen, für alle Plattformen verfügbar sein und so wenig wie möglich an Konfigurationseinstellungen bieten.

Flexibilität

Damit auch andere Projekte auf der Basis von TOR arbeiten können, oder Teilprobleme von TOR unabhängig bearbeiten werden können, sollte das Design einfach zu erweitern und gut spezifiziert sein.

Einfaches Design

Wenn das Design und die Sicherheitsparameter gut zu verstehen sind, wird die Komplexität und Implementation von Erweiterungen nicht zu aufwändig.

Keine Ziele (Non-Goals)

Für manche Probleme gibt es keine oder nur unzureichende Lösungen. Daher verzichtet man lieber auf die Verwendung dieser, auch wenn sie eigentlich gewisse Vorteile besitzen. So ist das Design zum Beispiel nicht Peer-to-Peer (durch die Directory Server), wobei es dazu unterschiedliche Angaben gibt. Auch bieten low-latency Systeme wissentlich keine Sicherheit gegen end-to-end-Attacken, da diese einfach zu schwer abzuwehren sind.

Threat-Modell

Für ein anonymes Netzwerk haben Bedrohungen meistens die Form einer passiven globalen Analyse des Netzwerkverkehrs. Gegen Angriffe solcher Stärke hat TOR jedoch kaum Chancen und nimmt daher an, dass Angriffe er in der Art erfolgen, dass Teile des Netzwerkverkehrs überwacht, dieser erzeugt, verändert, gelöscht oder verzögert werden kann, oder dass Onion Router übernommen und nach belieben gesteuert werden können. Nun kann der Angreifer entweder passiv agieren und den Verkehr an beiden Enden der Verbindung abhören und sie durch Timing und Volumen der Pakete miteinander verbinden. Wenn er aktiv agiert, kann der Angreifer versuchen die Schlüssel zu cracken oder Timing Signaturen einfügen um Unterschiede zwischen den Paketen noch deutlicher sichtbar zu machen. TOR hält diesen Angriffen nur in gewissem Maße stand.

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

Exit Policies

TODO