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

Jeder Onion Router beschreibt in seiner Exit Policy zu welcher externen Adresse und welchen Ports sich der Router verbindet. Dabei unterschiedet man zwischen den folgenden Arten. Zum einen die Open Exit Nodes, die überall hin verbinden. Zum anderen die Middleman Nodes, die nur zu anderen TOR-Knoten verbinden. Desweiteren gibt es private Exit Nodes, die nur zu lokalen Rechnern oder dem lokalen Netzwerk verbinden. Die vierte Variante sind Restricted Exit Nodes, die am Häufigsten vorkommen. Sie ermöglichen die Verbidnung nach außen, verhindern aber den Zugang zu gewissen, missbrauchsanfälligen Adressen und Diensten wie zum Beispiel SMTP. Diese Variante eignet sich sehr gut für den Administrator, weil er wählen kann welche Ports freigeschaltet sind und welche nicht. Fraglich ist jetzt, in welchem Verhältnis die verschiedenen Möglichkeiten angewandt werden sollten. Viele Middleman Nodes erstellen ein großes, robustes Netzwerk, aber wenn man nur wenig Exit Nodes hat, erleichtert man Angreifern auch die Überwachung des Datenverkehrs. Eine Mischung aus Open und Restricted Nodes erlaubt die größte Flexibilität für den Administrator.

Angriffe und Angriffsabwehr

Denial of Service

Da TOR ein öffentlicher Service ist, wird er natürlich auch gern für Angriffe genutzt. Vor allem Denial of Service-Attacken, also Attacken die zur Dienstverweigerung führen, finden hier Anwendung. So könnte ein Angreifer einen TLS Handshake antäuschen, was die CPU durch die verschiedenen Verschlüsselungsoperationen viel Zeit kostet. Dahingegen werden Angriffe, bei denen eine Vielzahl von UDP-Paketen gesendet werden, gut abgewehrt, da TOR nur korrekt geformte TCP-Streams transportiert und nicht beliebige IP-Pakete. Werden Hosts oder Links eines Streams erfolgreich angegriffen, geht der Dienst verloren. Man spricht dabei dann aber von sporadisch auftretenden Netzwerkfehlern.

Passive Angriffe

• Observing user traffic patterns: Durch das Beobachten der Verkehrsmuster eines Nutzers, wird zwar nicht die Herkunft oder die Daten erfahren, aber man kann Profile erstellen.
• Option distinguishability: Den Nutzern die Möglichkeit zu geben ihr Level an Sicherheit oder andere Einstellungen zu treffen, könnte bei gewissen Konfigurationen dazu führen, dass ein kleinerer Nutzerkreis entsteht und damit trotz höherer Sicherheitseinstellungen die Anonymität leidet.
• End-to-end timing correlation: Falls ein Angreifer den Datenverkehr beim Sender und Empfänger abhorcht, wird er durch die zeitliche Nähe der Pakete mit hoher Wahrscheinlichkeit herausfinden, dass die beiden Nutzer miteinander kommuniziert haben.

Aktive Angriffe

• Compromise keys: Sollte der Angreifer den Session Key herausfinden, kann er Kontrollzellen und verschlüsselte Relayzellen aller Verbindungstunnel dieser Verbindung sehen. Mit dem Session Key für den Verbindungstunnel, kann er dann eine Schicht entschlüsseln. Um diesen Verbindungstunnelschlüssel zu bekommen gibt es nun zwei Möglichkeiten:

1. Wenn der Verbindungstunnel bereits besteht muss der Angreifer den bereits ausgehandelten Session Key des Tunnels herausfinden. Da man aber vom Onion Key nicht auf diesen schließen kann, ist das sehr schwierig.
2. Wenn eine Anfrage für einen neuen Verbindungstunnel ankommt, benötigt der Angreifer den Onion Key um die create-Zelle zu entschlüsseln.

Man erkennt also, dass dies sehr aufwändig ist und darum auch als halbwegs sicher gilt.

• Replay attacks: Attacken, bei denen eine Wiederholung einer Seite des Handshakes ausgeführt wird, führt dazu, dass ein neuer Session Key vermittelt wird und somit die vorangehende Sitzung nicht entschlüsselt werden kann.

Directory Angriffe

• Subvert a majority of directory servers: Wenn ein Angreifer mehr als die Hälfte der directory server kontrolliert, kann er so viele von ihm kontrollierte Onion Router in das finale Verzeichnis einbinden wie er will. Darum sollten Betreiber von directory Servern besonders unabhängig und resistent gegen Attacken sein.

Angriffe auf Rendezvous Points

• Make many introduction requests: Da der Nutzer einstellen kann welchem Umfang die Anfragen an seinem Eingang haben dürfen, wird es dem Angreifer bei korrekten Einstellungen seitens des Nutzers kaum zu einem erfolgreichen überlaufen des Eingangspunktes kommen.

Fakten, Zahlen und Offene Fragen

Wie auf der Homepage von TOR zu lesen ist, sollte man immer daran denken, dass "... der Code in Entwicklung ist — daher ist es keine gute Idee, auf Tor zu vertrauen, wenn du wirklich starke Anonymität benötigst". Dies ist natürlich mit dem Design an sich zu begründen, da low-latency Systeme die weiter oben beschriebenen Probleme haben. Trotzdem weist TOR eine stets steigende Zahl von Knoten und Nutzern auf. TOR wird dabei für verschiedene Programme wie FTP, SSH, IRC oder E-Mailzustellungen genutzt. Allerdings steigt mit höherer Nutzerzahl auch die Gefahr, dass man einen langsamen Verbidungstunnel erwischt, weil einer der beteiligten Knoten über eine begrenzte bzw. ausgelastete Bandbreite verfügt.

So ergeben sich für das Design und die Nutzer einige Fragen.

1. Wie oft sollte der Verbindungstunnel seine Route aktualisieren?
   Wechselt man die Route zu oft, verliert man an Performance. Wechselt man zu selten, steigt das Sicherheitsrisiko.
2. Wie lang sollte der Pfad sein?
   Mindestens 3 Knoten sind nötig, damit man auch wirklich anonym unterwegs ist. Aber erhöhen noch mehr Knoten auch die Anonymität?
3. Sollte man versuchen end-to-end Attacken abzuwehren?
   Dies ist ein sehr schmaler Grat zwischen mehr Sicherheit und weniger Performance, der pauschal nicht zu beantworten ist.
4. Ist es sinnvoll wenn jeder Nutzer seinen eigenen Onion Router laufen lässt?
   Falls jeder Nutzer seinen eigenen Onion Router laufen lässt, könnte man nicht mehr unterscheiden, ob die Daten die an diesem Punkt durchgesetzt werden von ihm oder jemand anderem sind. Andererseits könnten Nutzer mit geringer Bandbreite langsame Verbindungstunnel erzeugen.

Zukunft und Ausblick

Einige Punkte könnten in Zukunft noch diskutiert werden. Diese betreffen vorwiegend das Design.

1. Scalability
   Da das Design recht einfach und flexibel gehalten werden soll, kommt es zu Problemen bei wachsender Nutzerzahl. Vielleicht muss man das Design dadurch grundlegend ändern.
2. Bandwidth classes
   Nutzer sollten möglicherweise ihre Bandbreite angeben, um den Flaschenhalseffekt bei manchen Verbindungen zu vermeiden.
3. Incentives
   Nutzer könnten durch höhere Anonymität oder andere Sachen dazu angeregt werden einen eigenen Knoten laufen zu lassen. Möglichweise skaliert dadurch das ganze System und wird dadurch noch reizvoller für neue Nutzer.