Abschlussarbeit. Evaluierung von ausgewählten Anonymisierungsverfahren für das Internet

Größe: px
Ab Seite anzeigen:

Download "Abschlussarbeit. Evaluierung von ausgewählten Anonymisierungsverfahren für das Internet"

Transkript

1 Abschlussarbeit zur Erlangung des Grades Bachelor of Science in Computer Science Evaluierung von ausgewählten Anonymisierungsverfahren für das Internet Erstprüfer: Prof. Dr. Martin Leischner Zweitprüfer: Dr. Thomas Östreich (BSI) Jens Michels ( ) Eingereicht am:

2 Eidesstattliche Erklärung Hiermit versichere ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegt bzw. nicht veröffentlicht. Jens Michels

3 Inhaltsverzeichnis 1 Einleitung und Motivation zum Thema 1 2 Der Begriff der Anonymität Voraussetzungen für Anonymität Rechtliche Grundlagen Warum überhaupt Anonymität? Anonymität durch fehlende Identität Grad der Anonymität Die negative Seite der Anonymität Missbrauch von Anonymisierungsverfahren Sind Anonymisierungsnetzwerke vertrauenswürdig? Mache ich mich durch die Benutzung von Anonymitätsdiensten verdächtig? Zugriffsprobleme auf bestimmte Inhalte des Internets Begriffe Cookies Referer Proxy Rewebber Mixkaskaden SOCKS Die verschiedenen Anonymisierer Anforderungsanalyse Auswahl der zu evaluierenden Produkte Java Anon Proxy Informationen zum Java Anon Proxy Relevante Entwurfskriterien Begründung der Auswahl Technische Realisierung Gefahrenmodell und Sicherheitslücken n-1 Angriff Replay-Angriff

4 7 TOR Informationen zu TOR Relevante Entwurfskriterien Begründung der Auswahl Technische Realisierung Gefahrenmodell und Sicherheitslücken Überwachung der Knoten Reduzierung der Nodes I2P - Internet Invisible Project Informationen zu I2P Relevante Entwurfskriterien Begründung der Auswahl Technische Realisierung Gefahrenmodell und Sicherheitslücken CPU Load Attacke Sybil Attacke Archicrypt Stealth VPN Informationen zu Archicrypt Stealth VPN Relevante Entwurfskriterien Begründung der Auswahl Technische Realisierung Gefahrenmodell und Sicherheitslücken OpenSSL-Bug Preshared Keys (PSK) Evaluierung der Programme Allgemeine Fragen Plattformunabhängigkeit Installationsaufwand Verwaltung / Konfiguration Zielgruppe Fragen zur technischen Seite des Verfahrens / Produktes Internet-Protokolle Ist die Einwahl ins Anonymisierungsnetz verschlüsselt? Anonymisierungs-Umfang Partizipiert sich der eigene Router an der Weiterleitung fremder Pakete? Anonymisierungsprodukte in Bezug auf die Vorratsdatenspeicherung

5 Ändert sich die zugewiesen IP-Adresse im Laufe der Verwendung? Messung von Latenzzeit und Bandbreite der Anonymisierungsdienste Verkehrsdaten-Protokollierung Preis- / Leistungsverhältnis Zusammenfassung und Ausblick Anhang PHP-Skript für IP-Adressen Auskunft Untersuchung mit Wireshark Installation des JAP-Clients Intstallation des TOR-Vidalia-Bundle Intstallation der Archicrypt Software Intstallation der I2P Software Messergebnisse Inhalt der CD

6 1 Einleitung und Motivation zum Thema In der heutigen Informationsgesellschaft gilt es, mit einer immer höher werdenden Informationsflut fertig zu werden. Dieser Trend zeichnet sich mit zunehmendem Internetverkehr immer stärker ab. Dabei fallen zum einen Informationen an, deren Verbreitung unbedenklich ist. Ebenso fallen aber auch Informationen an, die nicht unbedingt publik werden sollen. Es kann z. B. protokolliert werden, welche Webseiten man wann besucht hat. Diese Gefahr ist dem Großteil der Internet-Nutzer selbst nach mehrjähriger Internetnutzung nicht bekannt oder wird von ihnen unterschätzt. Im Auge vieler Nutzer spielt die Sicherheit eine untergeordnete Rolle. Der durchschnittliche Internet-Nutzer ist sich z. B. nicht darüber bewusst, dass man ihn jederzeit an seiner IP-Adresse eindeutig identifizieren kann, sogar über einen Zeitraum von mehreren Monaten. Der Aspekt des gläsernen Menschen kommt hier voll zum Tragen. Um solch vertrauliche Informationen geheim zu halten, muss man sie verdecken bzw. verändern. Eine bestimmte Art der Informationsverdeckung im Internet ist die Verdeckung personenbezogener Daten. Es geht hier um die Anonymisierung. Zu diesem Zweck werden verschiedene Anonymisierungsverfahren verwendet. Zu Beginn meiner Bachelorarbeit wird in Kapitel 2 die Frage nach der Anonymität beantwortet. Warum kann Anonymität einen Vorteil bieten? Da dies ein sehr aktuelles Thema mit sich ständig ändernder Rechtslage ist, darf auch eine kurze Betrachtung der aktuellen Gesetzeslage zu dieser Thematik nicht fehlen. Die geplante Vorratsdatenspeicherung und TK-Überwachung der Bundesregierung liefert natürlich nur gewünschte Ergebnisse, wenn es möglich ist, die Daten eindeutig einer Person zuzuordnen. Ebenso wird in Kapitel 3 die negative Seite von Anonymisierungsverfahren aufgezeigt. Unter diesen Aspekt passt etwa der Missbrauch dieser Anonymisierungsdienste. Somit ist ein guter Einstieg in das Thema gewährleistet. In Kapitel 4 geht es um die Definition von Begriffen, die für das Verständnis relevant sind. In Kapitel 5 werden die aktuellen Anonymisierungsverfahren genannt. Im Kontext einer Anforderungsanalyse werden hier für die Evaluation geeigneten Programme ausgewählt. Während in den Kapiteln 6 bis einschließlich 9 die Grundlagen der Anonymisierungsdienste erläutert werden, stellt Kapitel 10 den Kern der Arbeit dar. Hier werden 4 ausgewählte Verfahren evaluiert. Das zugrunde liegende Netz, auf dem die Anonymisierungsdienste ihren Dienst verrichten, ist hier das Internet. Die Be- 1

7 wertung betrifft die technische Realisierung sowie die Kompatibilität auf zukünftige Anforderungen und Rahmenbedingungen. Es ist durchaus sinnvoll, sich genau mit den heute existierenden Verfahren auseinanderzusetzen, da sie die Basis für zukünftige Technologien bilden. Kapitel 11 schließt die Bachelorarbeit mit einem Ausblick in die Zukunft und einer Zusammenfassung ab. Ziel dieser Ausarbeitung ist ein grundsolider Einblick in das Thema der Anonymisierung. 2 Der Begriff der Anonymität Im Rahmen dieser Abschlussarbeit spielt der Begriff der Anonymität eine zentrale Rolle. Deshalb muss er ausführlich und verständlich erläutert werden. Pfitzmann und Hansen definieren Anonymität folgendermaßen: Anonymity is the state of being not identifiable within a set of subjects, the anonymity set (vgl. [Pfi07a]). Zu deutsch heißt das: Anonymität ist der Zustand, innerhalb einer Reihe von Subjekten nicht identifizierbar zu sein. Set stellt hierbei alle möglichen Subjekte dar. Eine weiterführende Definition sagt aus, dass eine Instanz anonym ist, wenn folgende 3 Punkte erfüllt sind: 1. den anderen Instanzen nicht bekannt ist (Nichtbekanntsein) 2. gegenüber den anderen beteiligten Instanzen nicht in Erscheinung tritt (Nichtgenanntsein) 3. innerhalb des anonymen Vorgangs ohne erkennbaren Namen agiert (Namenlosigkeit) (vgl.[kel07]) Kurz gefasst kann gesagt werden, dass die Identifikation eine zentrale Rolle spielt. Kann ich eine Instanz nicht identifizieren, bleibt sie anonym. Unter Anonymität ist der Schutz und die Geheimhaltung der Identität zu verstehen. Der Begriff der Anonymität muss streng vom Begriff der Pseudonymität differenziert werden. Ein Pseudonym ist laut [Pfi07a] ein Bezeichner eines Subjektes, in diesem Fall des Senders oder des Empfängers. Das Pseudonym lässt keinen Rückschluss auf die Identität zu. Im Internet finden sich oft Pseudonyme, beispielsweise in Form von Nicknames. 2.1 Voraussetzungen für Anonymität Die Verkettbarkeit bzw. Unverkettbarkeit gibt Auskunft darüber, inwieweit man Rückschlüsse auf die Identität einer Instanz ziehen kann. Gilt eine Instanz als unverkettbar, ist es einer dritten Person nicht möglich, die an der Kommunikation 2

8 beteiligten Instanzen auszumachen. Die Verkettbarkeit definiert sich analog zur Unverkettbarkeit, stellt also das Gegenteil dar. In diesem Kontext ist die Empfängeranonymität und die Senderanonymität zu erwähnen. Unter Senderanonymität versteht man, dass es einer außenstehenden Person nicht möglich ist, die Identität des Senders auszumachen, jedoch kann die Identität des Empfängers durchaus bekannt sein. Auch die gesendete Nachricht kann bei diesem Szenario bekannt sein. Abbildung 1: Senderanonymität (Unilaterale Anonymität)[Kel07] Das Gegenstück zu der Senderanonymität bildet die Empfängeranonymität. Hier ist die Identität des Empfängers unbekannt, aber der Sender und eventuell auch die übertragene Nachricht sind bekannt. Abbildung 2: Empfängeranonymität (Unilaterale Anonymität)[Kel07] Bei der Unverkettbarkeit ist es nicht möglich, Sender oder Empfänger zu bestimmen. Abbildung 3: Unverkettbarkeit (Bilaterale Anonymität)[Kel07] Unter Inhaltsanonymität (unobservaility) versteht man, dass es einer an der Kommunikation nicht beteiligten Instanz unmöglich ist, den Inhalt der Kommunikation zu kennen.[pfi07a] 3

9 2.2 Rechtliche Grundlagen Wie schon in der Einleitung erläutert wurde, fallen beim Internetverkehr private bzw. personenbezogene Daten an. Der Umgang mit diesen sensiblen Daten ist in einer Reihe von Gesetzen geregelt, wovon einige hier erläutert werden. Zudem wird auf die aktuelle Gesetzeslage bzgl. der Vorratsdatenspeicherung eingegangen. Generell ist es einem Provider gestattet, laut 96 Abs. 2 TKG Verbindungsdaten zu Abrechnungszwecken längerfristig zu speichern. Genau diese Daten könnten für eine nachträgliche Identifizierung genutzt werden. Auf Antrag der Staatsanwaltschaft kann laut 100a und 100b StPO eine Telekommunikationsüberwachung ohne Wissen des Überwachten stattfinden. Dies unterliegt aber den in 100a Abs. 1 genannten Voraussetzungen (schwerer Verdachtsfall, keine andere Bestimmung des Aufenthaltsortes möglich und wenn die Tat auch im Einzelfall schwer wiegt) und darf gemäß 100b Abs.1 maximal 3 Monate andauern. Bei der Vorratsdatenspeicherung werden laut [Eur07] die Verbindungsdaten, aber nicht die Inhalte für einen Zeitraum von 6 Monaten bis maximal 2 Jahre gespeichert. Es ist also leicht möglich, nachträglich zu bestimmen, wer, wann und wo mit welcher IP-Adresse online war. Die Vorratsdatenspeicherung darf laut Artikel 1 Abs. 1 [Eur07] nur zur Aufklärung von Straftaten genutzt werden. Die Vorratsdatenspeicherung für Telefonate startete am 1. Januar Für das Internet muss jeder Internet Service Provider (ISP) die Speicherung spätestens bis zum 15. März 2009 einleiten (vgl. [Eur07]). Es steht den Providern aber frei, schon jetzt mit der Vorratsdatenspeicherung zu beginnen. Gegner der Vorratsdatenspeicherung sehen hier einen klaren Verstoß gegen das Fernmeldegeheimnis. Das Fernmeldegeheimnis ist in 88 TKG geregelt. In Absatz 1 wird deklariert, dass die Tatsache, ob jemand an einer Telekommunikation teilnahm, vom Dienstanbieter geheim zu halten ist. Laut [Kre07b] wird es ab dem Jahre 2009 wegen der Einführung der Vorratsdatenspeicherung wohl einen drastischen Abbau der deutschen TOR-Server geben und somit eine Schwächung des Anonymisierungsdienstes. Zudem muss der von Anonymisierungsdiensten erzeugte Datenverkehr ebenfalls im Rahmen der Vorratsdatenspeicherung erfasst werden (vgl. [Wei07]). Eine wichtige Streitfrage ist, ob Anonymisierungsdienste zu den Telemediendiensten oder zu den Telekommunikationsdiensten eingestuft werden sollen. Je nach Einstufung unterliegen die Anonymisierungsdienste verschiedenen Gesetzen. Bis jetzt konnte keine Einigung unter Juristen bezüglich dieser Fragestellung gefunden werden. Das Telekommunikationsgesetz (TKG) wurde im Rahmen der neuen EU-Richtlinie 2006/24/EG um die 113a und 113b erweitert. In 113a ist geregelt, welche Telekommunikationsdaten zu erfassen sind. Der Zugriff auf die erfassten Daten erfolgt gemäß 113b. 4

10 2.3 Warum überhaupt Anonymität? Wer sich auf der legalen Seite des Gesetzes befindet, der hat auch nichts zu verbergen. So lapidar lässt sich der Sachverhalt nicht darstellen. Es werden nun Gründe aufgezeigt, weshalb es sich lohnt, anonym zu bleiben, obwohl man keine illegalen Aktivitäten beabsichtigt. Jeder Mensch hat ein Recht auf Privatsphäre. Dabei darf es keine Rolle spielen, ob man sich nun im realen Leben oder im Internet befindet. Man muss selbst entscheiden dürfen, wann man seine Identität preisgibt und wann nicht. Absatz 1 des 4 BDSG sagt aus, dass die Erhebung, Verarbeitung und Nutzung personenbezogener Daten nur zulässig ist, soweit dieses Gesetz oder eine andere Rechtsvorschrift dies erlaubt oder anordnet oder der Betroffene damit einverstanden ist. Demnach kann der Wunsch nach Anonymität kein Verbrechen sein. Jeder Bürger soll Privatsphäre und Meinungsfreiheit auch im Internet umsetzen können. Es ist also von höchster Relevanz, wofür die Anonymität genutzt wird. Der meistgenannte Aspekt gegen eindeutige Identifizierung ist aber wahrscheinlich die Herstellung eines Nutzerprofiles, das dadurch problemlos ermöglicht wird. 2.4 Anonymität durch fehlende Identität Anonymität kann durch das Fehlen von Identitätsmerkmalen erreicht werden. Identität lässt sich laut [Mar99] wiederum durch 7 feststehende Begriffe deklarieren: Der gesetzliche Name Adressen Alphanumerische Symbole Pseudonyme Verhaltensmuster Soziale Kategorisierung Zertifikate und Bestätigungen Anhand des Namens kann man schon viele Informationen über eine Person gewinnen. Man kann z. B. Vermutungen über das Geschlecht oder die Staatsangehörigkeit anstellen. Über Adressen in aller Form kann sich ein Zugang zur Zielperson verschafft werden. Dementsprechend ist eine Adresse jeglicher Art in Bezug auf Anonymisierung hinderlich. Auch mithilfe von alphanumerischen Symbolen 5

11 ist eine eindeutige Identifizierung möglich. Heute hat jeder Mensch ihm zugeteilte Nummern, wie die Sozialversicherungsnummer oder im Falle eines Studenten die Matrikelnummer. Pseudonyme sind ein oft verwendetes Mittel, um gegen Identifizierung vorzugehen. Ein Pseudonym ist so etwas wie ein Deckname. Anhand des Verhaltensmusters ist es möglich, bestimmte Voraussagen zu treffen. Anhand dieser Voraussage kann man Kontakt zur gewünschten Person aufbauen. Soziale Kategorisierung kann ebenfalls bei der Identifizierung behilflich sein. Darunter hat man zu verstehen, dass eine Person anhand ihrer Zugehörigkeit zu einem Verein oder einer Gemeinschaft eingeschätzt wird und somit entfremdet. Das letzte Mittel zur Identifikationsbestimmung sind Zertifikate. Sie sollen die Echtheit der Angaben unterstützen. Nachteil von Zertifikaten ist aber, dass es sich um eine Fälschung handeln kann. 2.5 Grad der Anonymität Um die Intensität der Anonymität besser klassifizieren zu können, entwickelte man in [RR98] eine Unterteilung in verschiedene Grade. Die verschiedenen Stufen sind alle benannt und werden hier kurz anhand Grafik 4 und einer Beschreibung erläutert. Abbildung 4: Grade der Anonymität[RR98] absolute privacy (absolute Anonymität): Dies sagt aus, dass es einem Angreifer unmöglich ist, überhaupt festzustellen, ob Kommunikation stattfindet. Das ist die höchste Anonymitätsstufe. beyond suspicion (außer Verdacht): Hier kann nachgewiesen werden, dass eine Nachricht gesendet wurde. Man kann anhand der Nachricht aber nicht den ursprünglichen Sender ausmachen, d.h. jeder potentielle Sender im System kann in Frage kommen. probable innocence (wahrscheinlich unschuldig): Die außenstehende Person verdächtigt einen ganz bestimmten Sender, kommuniziert zu haben. Die Wahrscheinlichkeit dafür, dass die dritte Person sich irrt und es ein anderer Sender war, ist aber genauso hoch oder sogar höher, als dass es dieser bestimmte Sender war. 6

12 possible innocence (vielleicht unschuldig): Gibt es aus Sicht des Angreifers bzw. einer dritten Person den Anhaltspunkt dafür, dass es mit einer gewissen Wahrscheinlichkeit ein anderer Sender als der vermutete sein kann, gilt dieser als vielleicht unschuldig. exposed (entdeckt): Eine Instanz im Netz, welche als sendende oder empfangende Instanz ausgemacht worden ist. Die Identität dieser Instanz kann aber nicht aufgrund von Zertifikaten nachgewiesen werden. provably exposed (beweisbar entdeckt): Die kommunikationsbetreibende Instanz wurde identifiziert. Mithilfe von Zertifikaten kann die Identität nachgeprüft und bewiesen werden. Es besteht kein Zweifel an der Echtheit der Informationen bzgl. der Identität. Die Unterteilung in verschiedene Wirkstufen kann z.b. dabei hilfreich sein, selbst benutzte Anonymisierungsverfahren zu analysieren und zu bewerten. Einen hohen Grad an Identität erreicht man, wenn man sich in einer großen Gruppe aufhält, in der gleiche Attribute auf viele Gruppenmitglieder zutreffen. Dadurch wird die Identifizierung erschwert. Die Rede ist hier von der Anonymitätsmenge. 3 Die negative Seite der Anonymität 3.1 Missbrauch von Anonymisierungsverfahren Ursprünglich entwickelte man Anonymisierungsverfahren, um die Privatsphäre von Internet-Nutzern zu schützen. Man wollte verhindern, dass man aus gewissen Informationen auf Vorlieben und Gewohnheiten des Surfers schließen kann. Es gibt z. B. Internetseiten, die anhand persönlicher Informationen eine auf den Surfer maßgeschneiderte Werbung schalten können. Mit dem Fortschreiten der Anonymisierungsbewegung haben sich immer mehr Möglichkeiten für Missbrauchsfälle aufgetan. Will man jemanden für gesetzwidriges Verhalten bestrafen, muss man seine Identität kennen. Der Gedanke, ein Anonymisierungsverfahren für illegale Zwecke zu nutzen, liegt also nicht fern. Um beispielsweise in einer Tauschbörse urheberrechtlich geschütztes Material zu laden, bietet sich die Benutzung von Anonymisierungsprogrammen an. Der Bit-Torrent Client Azureus bietet standardmäßig die Möglichkeit, das TOR-Netzwerk oder das I2P Anonymisierungssystem anzusteuern (siehe Abbildung 5). Ein Nachteil ist die durch die Anonymisierung entstehende Verlangsamung des Ladevorgangs. Trotz solcher Möglichkeiten sei der Missbrauch von Anonymisierungsdiensten gering. Die TOR-Entwickler geben im Internet 1 zwar zu, dass es ein gewisses Missbrauchspotenzial im Netz- 1 7

13 werk gibt, es sei aber, bezogen auf die Gesamtheit der Nutzer, kaum wahrnehmbar. Ebenso wird verlautet 2, dass es bis jetzt nur wenige Beschwerden wegen Missbrauchs gab. Ähnliches sagt ein Artikel 3 vom Unabhängigen Landeszentrum für Datenschutz Schleswig-Holstein aus. Hier wurde der Java Anon Proxy in Bezug auf Missbrauch geprüft. Abbildung 5: Anonymisierung in Tauschbörsen Aufgrund der gesetzlichen Lage gegen Tauschbörsennutzer zeichnet sich ein Trend zur anonymen und verschlüsselten Tauschbörsennutzung ab. Das ist ein Beispiel von vielen möglichen. Es ist durchaus vorstellbar, dass man Anonymisierungsverfahren auch für anstößiges Material oder Rassismus verwendet. Laut [Dem03] werden Anonymisierungsdienste aber nur in den wenigsten Fällen für illegale Handlungen missbraucht. 3.2 Sind Anonymisierungsnetzwerke vertrauenswürdig? Diese Frage ist durchaus berechtigt, da Hersteller oder Betreiber von Anonymisierungsnetzwerken zumindest versuchen könnten, sensible Informationen aus dem Netzwerk zu gewinnen. Dass dies möglich ist, zeigen die Artikel[Rue07, Bac07] https://www.datenschutzzentrum.de/material/themen/presse/interkrim.htm 8

14 Natürlich gilt es so oder so, seine Daten weitestgehend nur verschlüsselt ins Netzwerk einzugeben. Letztendlich muss aber jeder Nutzer selbst darüber entscheiden, inwiefern er Anonymisierungsnetzwerken Vertrauen schenkt. Eng mit dieser Fragestellung verbunden ist die Frage nach unerwünschten Nebenfunktionen. Falls die Software ein OpenSource Produkt ist, steht es jedem frei, den Quellcode nach eventuellen Hintertüren zu durchsuchen. Da es eine Vielzahl interessierter User gibt, kann man davon ausgehen, dass der Code generell von einigen Leuten untersucht wird. Das ist ein großer Vorteil von OpenSource Produkten. Ein Nachteil besteht allerdings in der Tatsache, dass der Quellcode auch böswillig verändert werden könnte. Ein erfahrener Programmierer könnte im Quellcode eine unerwünschte und nicht dokumentierte Nebenfunktion einbauen und diesen Code dann im Internet zum Download anbieten. Gegen dieses Szenario gibt es einen wirksamen Schutz. Man sollte stets darauf achten, dass man die Software entweder von der Internetpräsenz des Herstellers bezieht oder von einer vom Hersteller verlinkten seriösen Internetseite. Die Wahrscheinlichkeit, dass dort veränderter Code vorliegt, ist sehr gering. Zudem gilt es, das Paket anhand seines Hashwertes auf MD5 oder SHA1 Basis eindeutig zu identifizieren. Nur so kann man sich wirklich sicher sein, einen unveränderten Quellcode zu erhalten. Die TOR-Entwickler haben sich auf ihrer deutschen Projektseite 4 zu diesem Thema geäußert. Zu bedenken ist, dass diese Angaben direkt vom Hersteller kommen. 3.3 Mache ich mich durch die Benutzung von Anonymitätsdiensten verdächtig? Wie aus Kapitel 3.1 hervorgeht, werden Anonymisierungsverfahren nur in den wenigsten Fällen für gesetzwidrige Handlungen genutzt. Trotzdem, oder gerade weil man Informationen zu verbergen versucht, könnte es sein, dass man so die gezielte Aufmerksamkeit einer Überwachungsinstanz auf sich zieht. In diesem Fall wären Personen mit einem besonderen Bewusstsein für Anonymität die Leidtragenden. Es würde genau das Gegenteil des Gewollten erzielt werden, nämlich eine Identifizierung. Diese Frage ist eindeutig spekulativer Natur und kann nicht zufriedenstellend beantwortet werden. 3.4 Zugriffsprobleme auf bestimmte Inhalte des Internets Ein allgemeines Problem von vielen Proxys und Anonymisierungsdiensten besteht darin, dass ein paar wenige Internetseiten und Foren den Zugriff verbieten. Die bekanntesten Beispiele sind Google und Wikipedia. Dabei konnte festgestellt 4 9

15 werden, dass sowohl die deutschen als auch die amerikanischen Seiten den Zugriff in der Regel nicht erlaubten 5 (siehe Grafik 6). Abbildung 6: Wikipedia Verbot für JAP-Benutzer Möglich ist diese Sperrung, da die IP-Adressen der Ausgangsserver vieler Anonymisierungsverfahren öffentlich bekannt sind. Für das TOR-Projekt kann in Internet 6 ein Einblick über die Nodes gewonnen werden. Somit ist eine Aussperrung dieser Adressen möglich. 4 Begriffe Hier werden nun prägnant einige für das Verständnis der Thematik relevante Begriffe erläutert. Ziel ist es, mit Hilfe dieser technischen Begriffe die im nächsten Kapiteln aufgezeigte Funktionsweise jedes Verfahrens verstehen zu können. 4.1 Cookies Ein Cookie (Browser Cookie) ist eine kleine Datei, welche der Webserver beim Besuch einer bestimmten Internetseite auf dem PC des Surfers abspeichert. Die dabei entstehende Datenübertragung wird entweder durch CGI oder Java-Script geleitet. Cookies sollen das Surfen erleichtern, können aber auch für den Client nachteilig verwendet werden. Es gibt neben den persistenten Cookies noch die 5 Das anwählen der Google und Wikipedia Seiten ist erlaubt, aber das Editieren eines Wikipedia-Artikels oder das absenden einer Suchanfrage in Google wird unterbunden 6 10

16 nicht persistenten Cookies. Diese werden nach dem Schließen des Browsers direkt wieder gelöscht und nicht auf der Festplatte abgelegt. Durch die Auswertung von Cookies lassen sich gezielt individuelle Werbemaßnahmen generieren, da ein Nutzer pseudonymisiert wird. 4.2 Referer Der Referer gibt die Ressource an, welche auf die aktuelle Website weist. Dieser Verweis ist in der HTTP Anfrage enthalten, die der Webserver an den Client schickt. Das Referer Feld wird nicht gesendet, falls die Request-URI kein Link ist, sondern einfach eine Eingabe via Tastatur in der Adressleiste des Browsers (vgl. [RFC99]). Auf der Website 7 ist ein Skript implementiert, welches man zur Auswertung der anfallenden Header-Daten aufrufen kann. Der User Agent spielt hierbei eine zentrale Rolle. Dieser übergibt dem Server Informationen über das verwendete Betriebssystem und den verwendeten Browser (vgl. [CBR04]). Der Eintrag bei Referer ist in Grafik 7 die URL Das ist die Seite, von der man per Hyperlink auf die Yourip Seite kommt. Die Weiterleitungs-URL (/expert-raw.html) ist dabei die relative URI. Die anderen angezeigten Daten, wie z. B. die IP-Adresse, sind in diesem Kontext nicht von Belang

17 Abbildung 7: HTTP Header Anzeige mit aktuellem Referer 4.3 Proxy Bei vielen Anonymisierungssystemen wird ein Proxy Server oder sogar eine Reihe hintereinander geschalteter Proxy-Server (Kaskade) benutzt. Ein Proxy ist ein Rechner im Internet, der zwischen dem Client und dem Server agiert. Es gibt eine Menge verschiedener Proxy mit verschiedenen Aufgaben, z. B. Filterung, Bandbreitenkontrolle oder Zugriffssteuerung. Gemäß des Themas dieser Bachelorarbeit wird hier auf den Anonymisierungsproxy eingegangen. Damit man den Proxy nutzen kann, ist es nötig, im Webbrowser die IP-Adresse des Proxys einzugeben und den zu nutzenden Port. Der Proxy ist nun dafür zuständig, eine Ende-zu-Ende Verbindung aufzubauen, aufrechtzuerhalten und bei Wunsch wieder abzubauen. Die besondere Fähigkeit des Anonymisierungsproxys besteht nun darin, die IP- Adresse des Nutzers zurück zu halten und durch die IP-Adresse des Proxy-Servers zu ersetzen (vgl. [CBR04]). 4.4 Rewebber Ein Rewebberdienst dient der automatischen Einwahl auf einem Anonymisierungsproxy. Der Rewebber wird gestartet, indem auf der Homepage des Rewebbers in dem dafür vorgesehenen Feld die Ziel-URL eingegeben wird. Hierbei wird 12

18 allerdings nicht mit einer Verkettung von Servern gearbeitet. Es existiert auch keine Verschlüsselung oder eine zufällige Weiterleitung der Anfragen[FHW98]. 4.5 Mixkaskaden Mixkaskaden sind eine gewisse Anzahl hintereinander angeordneter Proxies (Mixe). Einige Anonymisierungsdienste verwenden solche Kaskaden, um die Identifizierung eines Nutzers erheblich zu erschweren (vgl. ([BM03]). 4.6 SOCKS Bei SOCKS handelt es sich um ein Internet-Proxy-Protokoll, das vollständig applikationsunabhängig auf einem Server läuft. Aufgrund dieser Unabhängigkeit lässt sich nahezu jeder Dienst mit SOCKS starten. Zum Einsatz kommt SOCKS, wenn sich ein Server hinter einer Firewall befindet und sich nach außen verbinden will. Die Kommunikation läuft dann über einen SOCKS-Proxy (vgl. [Kya98]). 5 Die verschiedenen Anonymisierer Für das Internet gibt es heute eine Vielzahl von kostenlosen und kommerziellen Anonymisierungsverfahren. Dabei ist es wichtig, Anonymisierungsdienste von Anonymisierungsprogrammen zu unterscheiden. Die Anonymisierungsdienste sind dynamische Websites, von denen man anonym ins Internet starten kann. Sie sind als Webdienst zu verstehen. Nachteilig zu erwähnen ist, dass die Verbindung vom Internet-Surfer zum Rewebber-Dienst fast immer unverschlüsselt geschieht. Die folgende Tabelle 1 zeigt die wichtigsten Dienste dieser Art auf. NAME Anonymizer Guardster Megaproxy Proxyspinner Anonymouse Behidden.com Proxify BrowseAtWork Xerobank SaferSurf HOMEPAGE https://www.megaproxy.com/ https://www.nutzwerk.de/safersurf/ Tabelle 1: Anonymisierungsdienste im Internet 13

19 Neben den Anonymisierungdiensten gibt es eine größere Anzahl von Anonymisierungsprogrammen, die lokal auf der Festplatte des Computers installiert werden müssen. Diese Programme sind ebenfalls teilweise gratis oder auch kommerziell. Der Hauptunterschied zwischen einem Dienst und einem Programm besteht darin, dass man anhand des installierten Programms Konfigurationsmöglichkeiten hat. Zudem nutzen diese Programme oft mehrere hintereinander geschaltete Proxies, bzw. eine Kaskade. Ein Webdienst, welcher eine Anonymisierung anstrebt, wird über den Browser gesteuert und verlangt keine Installation beim Client. Tabelle 2 gibt einen Großteil der aktuell verfügbaren Programme wieder. NAME I2P Freenet 0.7 Torpark 2.2 Ghostsurf Platinum 5.1 Archicrypt Stealth 4 Archicrypt Stealth VPN Java Anon Proxy Internet Anonym VPN (Steganos) TOR (Vidalia Bundle ) Trackbuster Winsweep 4.63 Relakks CyberGhost VPN HOMEPAGE https://www.relakks.com/ Tabelle 2: Anonymisierungsprogramme für das Internet (Stand ) 5.1 Anforderungsanalyse Die Auswahl der vier zu evaluierenden Verfahren bzw. Produkte soll mehreren Bedingungen unterliegen. Zum einen sollen die zu testenden Verfahren eine unterschiedliche Funktionalität aufweisen, um die verschiedenen Möglichkeiten der Anonymisierung aufzuzeigen. Zum anderen sollen kommerzielle und freie Programme verglichen werden, damit man sieht, ob sich die Investition bei den kommerziellen Programmen auch lohnt. Auf jedes der auszuwählenden Anonymisierungsprogramme müssen die folgenden Eigenschaften zutreffen: Die echte IP-Adresse des Nutzers soll im Internet verborgen werden. Die Surfgeschwindigkeit im Internet darf nicht so gering sein, dass sich eine dauerhafte Nutzung ausschließt. 14

20 Jedes Anonymisierungsprogramm muss mindestens mit dem HTTP-Protokoll arbeiten können. Die Anonymitätsdienste (Rewebber) werden hier wegen mangelnder Flexibilität und Konfigurierbarkeit nicht getestet. 5.2 Auswahl der zu evaluierenden Produkte Nach sorgfältiger Prüfung wurden nun folgende Programme ausgewählt: Java Anon Proxy TOR (Vidalia Bundle ) I2P Archicrypt Stealth VPN In den folgenden Kapiteln 6,7,8 und 9 werden nun die in den Programmen verwendeten Verfahren erläutert. 6 Java Anon Proxy 6.1 Informationen zum Java Anon Proxy Der Java Anon Proxy, kurz JAP, ist ein System, das zur unbeobachtbaren Kommunikation im Internet genutzt werden kann. Somit soll verhindert werden, dass automatisch Daten über das Surfverhalten im Netz aufgelistet werden. Laut Entwickler ist das Verfahren noch nicht so ausgereift, dass man es als Final bezeichnen kann. Die JAP Software, die auf dem Heimrechner installiert werden muss, befindet sich derzeit in der Version und steht zum kostenlosen Download auf der Homepage des Herstellers bereit. Das System wurde unter Zusammenarbeit mehrerer Institutionen entwickelt. Die Universität Regensburg, die Technische Universität Dresden und das unabhängige Landeszentrum für Datenschutz Schleswig-Holstein sind hier zu nennen. Da im Jahre 2006 die Finanzierung der Institute auslief, wurde das Verfahren teilweise kommerzialisiert. Die JonDos GmbH wurde neuer Vertragspartner des kostenfreien AN.ON Projekts. Laut [Wen07] gibt es mittlerweile verschiedene qualitative Grade der Anonymität in diesem System, die auch dementsprechend tarifiert sind. 15

21 6.2 Relevante Entwurfskriterien Im Dokument [K 07] werden wichtige Design-Ziele beschrieben und erläutert. Ein Ziel ist es unter anderem, den richtigen Kontext zwischen Sicherheit und Benutzbarkeit zu finden. Das System ist nur benutzbar, wenn es einfach zu installieren und zu konfigurieren ist. Ebenso darf die Surfgeschwindigkeit nicht drastisch unter den Sicherheitsvorkehrungen leiden. Unter Sicherheitsvorkehrungen versteht man hier die Unbeobachtbarkeit der Kommunikation und die Abwehr von gezielten Angriffen auf den Dienst. Der Aspekt der Unbeobachtbarkeit sagt aus, dass es einem Beobachter zwar möglich ist, eine Kommunikation auszumachen, aber eine Identifizierung der beteiligten Instanzen nicht möglich ist. Das eigentliche Verfahren baut auf dem Mix-Konzept von David Chaum auf (vgl. [Dav81]). Ziel des Mix-Ansatzes ist es, die Nachrichtenübertragung durch den Einsatz von Mixen unbeobachtbar zu gestalten. Da diese Mixe den Kern dieses Dienstes bilden und im besten Fall sehr viele Nutzer gleichzeitig ihre Anfragen über die Mixkaskaden senden, müssen in sehr kurzer Zeit sehr viele Anfragen bearbeitet werden. Deshalb entschied man sich hier für die Programmiersprache C++. Das Projekt basiert auf Open-Source Basis. 6.3 Begründung der Auswahl Dank der hohen Flexibilität in Bezug auf Betriebssysteme gehört JAP heute zu einem der bekanntesten und meist genutzten Anonymisierungsdienste. Eine hohe Anzahl an Nutzern erschwert die Identifikation eines Nutzers. 8 Eine weitere Besonderheit gegenüber vielen anderen Diensten ist, dass der Nutzer aufgrund seiner persönlichen Präferenz selbst eine Mixkaskade wählen kann. Demnach kann der Benutzer den Grad der gewünschten Anonymität festlegen, was sich aber eventuell durch Kosten für die kostenpflichtigen Mixe äußert. Auch die Bezahlung kann hier anonym vorgenommen werden. 6.4 Technische Realisierung Das gesamte System besteht aus drei Haupt-Komponenten. Die erste Komponente ist die JAP Software, welche als Proxy fungiert und Kontakt zum Anonymisierungsnetzwerk aufbaut. Die zweite Komponente sind die Mixe. Es gibt insgesamt n Mixe, (Rechner im Internet) welche Routing-Aufgaben bewältigen. In einer Mixkaskade sind immer 2 bis 3 Mix-Rechner enthalten 9. Als dritte Komponente 8 siehe Anonymitätsmenge auf Seite 7 9 das gilt auch für die Kaskaden Dresden-Dresden und CookieCooker, obwohl diese in der JAP- GUI nur als 1 Mix-Rechner grafisch dargestellt sind. Die Dresden-Dresden Kaskade hat aber den entscheidenden Nachteil das beide Rechner von der selben Instanz betrieben werden. 16

22 befindet sich im System eine Info-Datenbank, welche temporär Daten speichert. Der Aufbau ist in Abbildung 8 skizziert. Weiterhin sei zur Erläuterung der Grafik angemerkt, dass zwischen allen Mixen einer Kaskade eine TCP-Verbindung steht. Genauso verhält es sich zwischen dem JAP-Client und dem ersten Mix in der Kaskade. Abbildung 8: Aufbau des Systems [K 07] Das Mix-Paket weist eine Größe von 998 Bytes auf, wovon 992 Bytes als Payload genutzt werden können, da der Header 6 Byte umfasst (siehe Abb. 9). Abbildung 9: Struktur eines Mix-Paketes [K 07] Für zukünftige Erweiterungen werden hier 11 Bit-Felder reserviert. In den 5 folgenden Feldern sind Flags verzeichnet, die in Tabelle 3 erläutert werden. 17

23 FLAG DF (Dummy-Flag) OF (Open-Flag) RF (Channel-Resume-Flag) SF (Channel-Suspend-Flag) CF (Close-Flag) BEDEUTUNG Leerlaufübertragung öffnen eines neuen Kanals fortsetzende Datenübertragung sagt aus, dass vom letzten Mix keine Daten mehr für diesen Kanal gesendet werden sollen zeigt Ende eines Kanals an Tabelle 3: Flags eines Mix-Paketes Das Channel-Resume-Flag und das Channel-Suspend-Flag werden dabei immer vom ersten in der Reihe sitzenden Mix gesetzt und vom letzten Mix ausgewertet. Die Kanal-ID im Header dient dazu, ein Mix-Paket zum korrekten Mix-Kanal zuzuweisen. Damit ein eventueller Beobachter nicht direkt eine Zuordnung zwischen dem Mix-Kanal und dem Mix-Paket ableiten kann, verschlüsselt man die ersten 16 Byte eines jeden Paketes mit der AES Verschlüsselung. Die Daten werden dabei im Output Feedback Modus verschlüsselt. 10 Bei gesetztem Open-Flag, also der Öffnung eines Kanals, werden die ersten 128 Byte des Mix-Pakets asymmetrisch mit Plain-RSA kodiert. Die restlichen 864 Byte des Paketes werden wieder symmetrisch mit dem AES Verfahren verschlüsselt. Der Payloadanteil, also die zu übertragenen Nutzdaten pro Paket, hängen von der Länge der Mix-Kaskade ab. Bei gesetztem Open-Flag befindet sich vor dem Payloadheader der symmetrische Schlüssel mit einer Länge von 16 Byte. Dadurch, dass die ersten 16 Byte vom entschlüsselten Payload-Teil in einem Paket den Schlüssel für die nächste symmetrische Verschlüsselung bilden, nimmt die Payload pro Vorgang um 16 Byte ab. Der Payloadheader hat eine Größe von 3 Byte, wovon 2 Byte als Network-Byte- Order Angaben über die Größe der Payload ausgeben. Das letzte der drei Bytes ist für die Typbestimmung der Payload zuständig. Ausgehend von der Art des Typs wird ein passender Proxy für die weitere Kommunikation gewählt. Jetzt wird der Kommunikationsvorgang betrachtet. Die Clientsoftware, welche hier als Proxy fungiert, baut zuerst den Kontakt zu Mix 1 auf. Um die Auswertung des Routingvorgangs zu erschweren, werden mehrere Maßnahmen getroffen. Ein Mix sammelt eine gewisse Anzahl von Requests, bevor er diese dann neu kodiert und in anderer Reihenfolge wieder ausgibt. Diese Schritte werden vorgenommen, damit man das Datenpaket, nachdem es Mix 1 verlässt, nicht mehr erkennen kann. Aus gleichem Grund wird auch eine Änderung der Reihenfolge vorgenommen. Damit wird die zeitliche Zuordnung verhindert. Zudem werden alle Pakete auf die gleiche Größe generiert. Zu kleine Pakete werden mit Dummy-Daten aufgefüllt. 10 unter OFB ist Stromchiffrierung zu verstehen 18

24 Dazu muss man wissen, dass sich jeder Mix auf dem Weg die für ihn bestimmten Informationen ausliest. Damit die Länge aber immer gleich bleibt, fügen Mixe Füll-Bits ein [Dem03]. Laut [Fed07] kann dieses Verfahren als sicher bezeichnet werden, wenn mindestens einer dieser Mixe vertrauenswürdig ist, d.h. nicht kompromittiert ist. Würden beispielsweise alle Mixe von einem einzigen Anbieter betrieben werden, könnte dieser den gesamten Kommunikationsvorgang beobachten und auswerten. Die Anonymität wäre dann nicht mehr gegeben. Aus diesem Grund werden Mixe von unterschiedlichen Anbietern genommen, um diese Kontrolle zu unterbinden (Single Point of Failure). Jeder Mix in der Kette verfügt über unterschiedliche Informationen: POSITION INFORMATIONSGEHALT erster Mix weiß von welcher IP-Adresse ein Request kommt, und dass er an Mix 2 weiter senden muss (kommuniziert mit dem Client und einem weiteren Mix) zweiter Mix weiß wohin, weitergeleitet werden soll, z. B. an Mix 3 (kommuniziert mit 2 Mixen) letzter Mix weiß nur wohin, die Anfrage zu senden ist, aber nicht, woher die ursprüngliche Anfrage kam (kommuniziert mit einem Mix und dem Internet) Tabelle 4: Unterschiedliche Informationsbasis für verschiedene Mixe Der Internet-Service-Provider des JAP Nutzers kann sehen, dass der Surfer mit dem ersten Mix Kontakt aufbaut. Da diese Pakete allerdings verschlüsselt sind, kann nicht ausgewertet werden, was Inhalt der Kommunikation ist. Nur die Kommunikation an sich kann festgestellt werden[bm03]. Weniger Mixe in der Reihe erhöhen die Geschwindigkeit im Netz, senken aber dafür die Sicherheit in Bezug auf die Anonymität. Umso weniger Instanzen benötigt werden, umso leichter könnte eine Zusammenarbeit zwischen den Mixbetreibern ermöglicht werden. Auch hätte ein potentieller Angreifer weniger Instanzen zu beobachten, um eventuelle Korrealtionen festzustellen. Aus dem White-Paper [Fed07] zu JAP können genauere Informationen zur Verschlüsselung unter den Mixen entnommen werden. Das Konzept der Mixe besagt, dass ein Sender die Nachricht so verschlüsselt, dass sie nur beim Empfänger ankommt, wenn sie alle in der Reihe befindlichen Mixe in der korrekten Reihenfolge durchläuft. Sender verschlüsselt Nachricht zuerst für den letzten Mix (Mix n ) Dieses Paket wird danach nochmals für den vorletzten Mix verschlüsselt (Mix n 1 ) 19

25 Paket wird wiederum verschlüsselt, diesmal für den vorvorletzten Mix (Mix n 2 ) Verschlüsselung fährt solange fort, bis erster Mix (Mix 1 ) erreicht ist Wenn der Sender nun das so verschlüsselte Paket an Mix 1 schickt, kann nur er es entschlüsseln und an Mix 2 weiterleiten. Mix 2 entschlüsselt wiederum seinen Teil und schickt das Paket weiter an Mix n. Dieser Algorithmus geht solange, bis die Reihe durchlaufen ist (siehe Abbildung 10). Für dieses Vorgehen ist hybride Verschlüsselung notwendig. Der geheime Schlüssel ist hierbei nur dem jeweiligen Mix bekannt. Somit wird mit dem öffentlichen Schlüssel und dem jeweiligen geheimen Schlüssel für jeden Mix die entsprechende Verschlüsselung generiert. Asymmetrische Verschlüsselung ist in der Regel sehr rechenintensiv. Um Zeit zu sparen, wird hier lediglich der genutzte Schlüssel mit dem asymmetrischen RSA- Verfahren mit 1024-Bit Schlüssellänge verschlüsselt. Die Nachricht, bzw. das zu routende Paket wird symmetrisch mit AES verschlüsselt, da dies Rechenaufwand spart. Durch die Verschlüsselung wird erreicht, dass die Nachricht nur von den echten Mixen und nur in richtiger Reihenfolge entschlüsselt werden kann. Zudem wird pro Ver/Entschlüsselungsvorgang das Erscheinungsbild einer Nachricht verändert. So ist es einem Beobachter nicht möglich, eine Nachricht anhand ihres Aussehens zu erkennen[20007]. Abbildung 10: Visualisierung des Konzeptes [Fed07] Erklärung zur Abbildung: Der Ausdruck c 1 (c 2 (N,z 2 ),z 1 ) bedeutet lediglich, dass die Nachricht erst für den zweiten Mix verschlüsselt wurde und anschließend für den ersten. Das Entschlüsseln muss dementsprechend in entgegengesetzter Reihenfolge stattfinden. Nachdem dieser Ausdruck Mix 1 passiert hat, bleibt nur noch der Ausdruck c 2 (N,z 2 ) übrig. Dieser Ausdruck oder auch Schlüssel kann und wird ausschließlich von Mix 2 entschlüsselt. N ist hierbei bezeichnend für die Nachricht, c stellt den Chiffrierschlüssel dar und z ist die zufällige Bitkette. Diese Kette ist nötig, weil ein Beobachter sonst den öffentlichen Schlüssel auf die Mix-Pakete anwenden könnte. Annahme bei diesem Beispiel: Im System 20

26 befinden sich nur 2 Mixe. Die Unbeobachtbarkeit wird noch durch die schon erwähnte Vertauschung der Reihenfolge und Auffüllung mit Dummy-Daten der Pakete verstärkt. Ein weiteres davon abgeleitetes Sicherheitskonzept ist der Dummy- Verkehr. Dummy-Verkehr ist Verkehr, der gesendet wird, falls es keine echten Nachrichten zu senden gibt. Würde man diesen Verkehr nicht generieren, könnte ein Beobachter Rückschlüsse über das Kommunikationsverhalten ziehen. Es würde dann z. B. auffallen, wenn ein User des Anonymisierungsdienstes aufhört zu senden und vom Ausgangsmix das letzte Paket erhält. Nachdem eine Nachricht alle Mixe durchlaufen hat, baut letztendlich ein Proxy im Netzwerk (Mix 3 ) den Kontakt zur gewünschten Ressource auf. In der folgenden Abbildung 11 wird noch darauf eingegangen, dass Wiederholungen ignoriert werden müssen. Das geschieht mit einem Vergleich des in der Datenbank gespeicherten Fingerabdrucks der Nachricht [BM03]. Dies ist ein Schutz gegen Replay-Angriffe und wird im Kapitel 6.5 beschrieben. Abbildung 11: Funktionen des Mix-Systems [Pfi07b] Durch den Mix-Ansatz werden die folgenden Schutzziele erreicht: 21

27 Unbeobachtbarkeit: Dies wird durch das Ansammeln, Umsortieren, Verbzw. Entschlüsseln und die Erzeugung von Dummy-Verkehr realisiert. Ein potentieller Angreifer ist zwar in der Lage, den Sendevorgang als solchen wahrzunehmen, aber eine Korrelation zwischen 2 Nutzern kann nicht hergestellt werden. Senderanonymität: Selbst wenn der Empfänger alle Knoten im Mix-Netz beobachtet, ist es ihm nicht möglich, den Sender der Nachricht zu ermitteln. Empfängeranonymität: Um eine Antwort zu erhalten, gibt es für den Sender zwei mögliche Ansätze: Zum einen kann der Sender in dem zu versendenden Paket eine anonyme Rückadresse in Form eines Pseudonyms unterbringen. Die zweite Möglichkeit besteht darin, dass der Empfänger sich die Wegelenkungsinformation aus der Info-Datenbank holt. Vertraulichkeit der Nachrichten: Lediglich der Sender und der Empfänger einer Nachricht darf diese lesen können. Keine Zwischenstationen oder weitere Instanzen dürfen den Klartext der Nachricht einsehen können [Dem03]. Um eine möglichst hohe Zuverlässigkeit zu gewähren, wird für die Kommunikation zwischen den einzelnen Instanzen des Systems das TCP-Protokoll verwendet. 6.5 Gefahrenmodell und Sicherheitslücken Bei jedem Anonymisierungsdienst gibt es dokumentierte Lücken, bzw. mögliche Angriffszenarien, um die Anonymität oder die Funktion des Dienstes aufzuheben. Da es den Rahmen dieser Arbeit überschreiten würde, jedes Angriffszenario von jedem der hier zu evaluierenden Verfahren darzustellen, wird eine Vorauswahl getroffen. Ausgewählt werden besonders interessante Angriffszenarien, um anhand dieser Angriffe explizit mögliche Schwachstellen aufzuzeigen. Auch theoretische Ansätze werden berücksichtigt n-1 Angriff Hierbei handelt es sich um ein theoretisches Modell, da zur praktischen Umsetzung dieses Angriffes zu viele User im Anonymisierungsnetzwerk sind. Die Variable n stellt hierbei die Anzahl aller Teilnehmer des Netzes dar. Sind n User im Netz, werden auch n Nachrichten zu einem Zeitpunkt versendet. Kennt der Angreifer von diesen n Nachrichten alle bis auf eine, so kann er auch Rückschlüsse über die letzte verbleibende Nachricht bilden [Fed07]. 22

28 6.5.2 Replay-Angriff Bei Replay-Angriffen hört ein Beobachter die Kommunikation ab und zeichnet einen Teil davon auf. Zu einem späteren Zeitpunkt wird diese Nachricht wieder in das System eingespielt, denn der Angreifer vertraut darauf, dass das System die Nachricht auf gleiche Weise verarbeitet wie die vorige aufgenommene Nachricht. Daraus lassen sich dann Rückschlüsse ziehen. Der Java Anon Proxy hat für solche Fälle die Info-Datenbank, wo Fingerabdrücke jeder gesendeten Nachricht für ein gewisses Zeitintervall gespeichert werden. Kommt in diesem Intervall eine Nachricht, die den gleichen Hash-Wert wie eine kurz davor gesendete Nachricht aufweist, wird sie verworfen [Kel07, Fed07]. 7 TOR 7.1 Informationen zu TOR The Onion Router, kurz TOR ist ein Anonymisierungsdienst, der auf der Basis des Onion-Routing besteht. Es wird allerdings eine weiterentwickelte Version des Onion-Routing benutzt. Im Jahre 2002 startete Roger Dingledine und Matej Pfajfar von der Universität Cambridge die Entwicklung von TOR. Bis heute wurden sie dabei von verschiedenen Organisationen wie dem United States Naval Research Laboratory und dem Defense Advanced Research Projects Agency (DAR- PA) finanziell unterstützt. Aktuell wird das TOR-Projekt von der Eletronic Frontier Foundation geführt. Ziel ist es, einem Beobachter eine Verkehrsanalyse der Kommunikation zu erschweren. Zu diesem Zweck werden die Daten über zufällig erwählte Knoten 11 gesendet. Die Pakete sind dabei mehrfach verschlüsselt, so dass immer nur eine ganz bestimmte Instanz zur Entschlüsselung befähigt ist. Um in das Anonymisierungsnetzwerk zu gelangen, muss auf dem Heim-Rechner die Client-Software installiert werden. 7.2 Relevante Entwurfskriterien Im Design-Paper[DMS08] zu TOR sind Ziele genannt. In Bezug auf die Anwendbarkeit war es den Entwicklern wichtig, dafür zu sorgen, dass das Netzwerk keine hohe Bandbreite benötigt, da alles von privaten Spenden finanziert werden muss. Ein weiterer wichtiger Design-Punkt ist die Benutzerfreundlichkeit. Ein System, das sich nur kompliziert bedienen lässt, wird niemals über viele User verfügen. Eine große Nutzerzahl ist für die Funktion des TOR-Dienstes aber relevant. Wenn 11 bei TOR werden Knoten als Node bezeichnet 23

29 mehr User online sind, verfügt das Netzwerk über eine größere Anonymitätsmenge, d.h. die Zuordnung, wer welche Nachrichten empfing oder versendete, wird erschwert. Zudem soll das Protokoll gut dokumentiert sein, um als Fundament für zukünftige Entwicklungsarbeiten dienen zu können. 7.3 Begründung der Auswahl TOR hat gegenüber anderen Anonymisierungsdiensten den Vorteil, dass es sehr vielfältig und flexibel einsetzbar ist. Währenddessen man JAP zum anonymisieren von HTTP und FTP nutzen kann, ist TOR zusätzlich noch in der Lage, P2P Verbindungen und Instant Messaging zu anonymisieren. Laut [The08b] besteht die Möglichkeit, mittels TOR einen anonymen Webserver zu betreiben. Ein weiterer Grund für die Auswahl von TOR ist die freie bzw. kostenlose Nutzung dieses Systems. 7.4 Technische Realisierung Das Anonymisierungssystem besteht aus mehreren Hauptkomponenten. Zuerst ist der Client-PC zu erwähnen, der sich mittels der TOR-Software anonym im Internet bewegen will. Dann gibt es den Eintrittsknoten (Entry Node). Außerdem gibt es noch ein Middle-Node und ein Exit-Node, der den eigentlichen Zielrechner kontaktiert. Weiterhin gibt es einen Directory Server, der die Aufgabe hat, Informationen über alle Nodes und Hidden Services bereitzustellen. Ein weiterer Node ist der Rendezvous-Punkt, der letztendlich als Vermittlungsstation zwischen Client und seinem Ziel arbeitet. Zuletzt gibt es einen Hidden-Server. Dies ist z. B. ein Webserver, welcher über das TOR-Netzwerk erreichbar ist und daher anonym fungiert (vgl. [DMS08]). Da TOR wie schon oben erwähnt auf dem Onion-Routing basiert, soll dieses Verfahren hier vorgestellt werden. Zwischen den einzelnen Routern im Netz bestehen dauerhaft verschlüsselte TCP-Verbindungen, welche der Verteilung von Organisationsinformationen dienen. Will sich nun ein TOR-User anonym ins Netz einwählen, beginnt der Anonymisierungsprozess. Ein Paket wird mit den öffentlichen Schlüsseln der auf dem Weg vorhandenen Instanzen verschlüsselt. Von diesem Schichten-Verfahren ist der Name Onion-Routing also Zwiebel (Schichten)- Routing abgeleitet. Jede Schicht hat zudem noch eine TTL, nach deren Ablauf das Paket verworfen wird. In jeder dieser Schichten ist die Adresse des nächsten Nodes (Routers) auf dem Weg und eine Zufallszahl zur Generierung eines symmetrischen Schlüssels enthalten [Dem03]. Abbildung 12 skizziert die Kommunikation über das TOR-Netzwerk. 24

30 Abbildung 12: Topologie des Onion-Routing [Dem03] Die bei der Kommunikation anfallenden Pakete, hier Zellen genannt, haben eine feste Größe von 512 Byte. Es gibt 2 unterschiedliche Arten von Zellen: Control Cell: Synchronisation bzw. Informationsverteilung, welche von Nodes ausgewertet wird Relay Cell: Daten und Kommando-Versendung / Ende-zu-Ende Stream Um Routinginformationen verwalten zu können, hat jede Zelle einen 3 Byte großen Header. Grafik 13 zeigt die Controll Cell. Abbildung 13: Control Cell [DM08] Der Circuit Identifier (CircID) bestimmt, welcher Kanal genutzt werden soll. Das Command Byte (CMD) nimmt einen der in Tabelle 5 aufgezeigten Methoden entgegen. 25

31 NUMMER BEZEICHNUNG AUFGABE 0 PADDING Dummy-Daten (wird aktuell nicht genutzt) 1 CREATE einen Kanal schalten 2 CREATED Bestätigung der Kanal-Schaltung 3 RELAY Ende-zu-Ende Kommunikation 4 DESTROY Kanal-Benutzung einstellen 5 CREATE_FAST einen Kanal schalten (ohne Public-Key) 6 CREATED_FAST Bestätigung der Kanal-Schaltung (ohne Public-Key) Tabelle 5: mögliche Optionen von CMD [DM08] Das CREATE_FAST Kommando wird anstatt des CREATE Kommandos verwendet, falls der erste Hop-Router (Node) des zu benutzenden Circuits schon initialisiert worden ist. In diesem Fall hat der Onion-Proxy schon die Identität des jeweiligen Onion-Routers und somit auch einen Secret Key unter Benutzung von TLS ausgehandelt. Der daraus resultierende Vorteil ist die Zeitersparnis. Die Relay-Zellen haben einen zusätzlichen Header, den Relay-Header. Dieser sitzt direkt vor den Nutzdaten. Wo die Control-Cell das CMD-Feld hat, gibt es bei der Relay-Cell ein Relay Feld, das verschiedene Relay-Commands enthält. Zur Auswahl des korrekten Streams dient das Feld StreamID. Mehrere Streams können über einen Circuit gemultiplext werden. Das Digest-Feld enthält eine Ende-zu- Ende Checksum für die Integritätsüberwachung. Das Len-Feld gibt die Länge der Nutzdaten an. Dann folgt nur noch das 498 Byte große Payload Feld wie in Grafik 14 zu sehen ist [DM08]. Die Relay-Cell ist mit 128 Bit AES im Counter-Mode verschlüsselt. Abbildung 14: Relay Cell [DM08] Zur besseren Verständlichkeit werden in Tabelle 6 die Relay-Commands erläutert. 26

32 NUMMER BEZEICHNUNG AUFGABE 1 RELAY_BEGIN öffnen eines Streams 2 RELAY_DATA Datenfluss (bidirektional) 3 RELAY_END sauberes Schließen eines Streams 4 RELAY_CONNECTED dem Onion-Proxy mitteilen, dass Kommunikation startet 5 RELAY_SENDME für Congestion-Controll 6 RELAY_EXTEND Verbindungskette erweitern 7 RELAY_EXTENDED Bestätigung des EXTEND 8 RELAY_TRUNCATE einen Teil der Kanalschaltungen abbauen 9 RELAY_TRUNCATED Bestätigung zu TRUNCATE 10 RELAY_DROP vorgesehen für Dummy-Verkehr 11 RELAY_RESOLVE Reverse Lookup (DNS) 12 RELAY_RESOLVED Antwort zu Reverse Lookup 13 RELAY_BEGIN_DIR Antwort zu RELAY_BEGIN Tabelle 6: Optionen des Relay-CMD [DM08, DMS08] Nachdem nun der Aufbau der zu übertragenden Zellen geläufig ist, wird der eigentliche Kommunikationsvorgang betrachtet. Der anonyme Verbindungsaufbau wird durch den Client PC 12 initiiert. Dabei werden aus dem TOR-Directory drei zufällige Nodes ausgewählt. Diese drei ausgewählten Router werden als Verbindungskette mit folgenden Eigenschaften fungieren: NODE-NUMMER BEZEICHNUNG AUFGABE 1 Entry-Node Verbindung in Netzwerk schalten 2 Middle-Node Vermittlung 3 Exit-Node Kontakt mit Ziel-Rechner aufbauen Tabelle 7: Aufgaben der Nodes Der Onion-Proxy bildet zusätzlich zu dieser Verbindungskette noch weitere auf Vorrat, da jede Verbindungskette nur für einen bestimmten Zeitintervall existiert. Die Kette wird gleichzeitig von mehreren Nutzern für unterschiedliche Verbindungen genutzt, um eine genaue Zuordnung zu erschweren. Jeder Onion- Router arbeitet mit zwei verschiedenen Schlüsseln: Identitätsschlüssel (langlebig): um das TLS Zertifikat zu signieren 12 ab jetzt nur noch Onion-Proxy genannt 27

33 Onion-Schlüssel (kurzlebig): Er wird benutzt, um Nachrichten an den Onion- Router zu entschlüsseln und um den Sitzungsschlüssel auszuhandeln Der Aufbau zum Entry-Node und die spätere Kommunikation zwischen den einzelnen Nodes erfolgt mittels TLS/SSLv3 Verschlüsselung. Nachdem der Onion- Proxy mit der Entry-Node eine verschlüsselte TLS-Verbindung eingeleitet hat, schickt er eine Verbindungsanfrage in Form einer Create Cell an die Entry-Node, welche zugleich die notwendigen Informationen für das Diffie-Hellmann- Schlüsselaustausch Verfahren g x in ihrer Payload beinhaltet. Die gesamten Verbindungen im Anonymisierungsnetzwerk werden zuerst mittels TSL/SSLv3 verschlüsselt, um dann den Schlüsselaustausch für das Diffie Hellmann Verfahren darüber stattfinden lassen zu können. Jeder Node im Netz, also jeder TOR-Router, besitzt einen kurzlebigen Onion- Schlüssel. Will nun Instanz j an Instanz i eine Anfrage schicken, so ist diese mit dem Onion-Schlüssel von Instanz i verschlüsselt. Dies ist natürlich nur der Fall, solange noch keine gemeinsamen Sitzungsschlüssel ausgetauscht und generiert wurden. Im Erfolgsfall sendet nun die Entry-Node das Acknowledge für den Verbindungsaufbau ins TOR-Netzwerk zurück (Created Cell). Zudem werden auch die notwendigen Informationen für das Diffie Hellmann Verfahren, g y an den Onion- Proxy übergeben, damit dieser einen AES-128 Sitzungsschlüssel K = g xy generieren kann. Zum jetzigen Zeitpunkt ist die Verbindung zwischen Onion-Proxy und dem Entry-Node verschlüsselt. Als nächstes muss eine verschlüsselte Verbindung zwischen dem Entry-Node und dem Middle-Node aufgebaut werden. Dazu sendet der Onion-Proxy eine mit dem Onion-Schlüssel von der Middle-Node verschlüsselte Aufforderung in Form einer Relay-Extend-Cell an den Entry-Node. Wie auch im vorherigen Schritt werden auch hierbei Informationen für das Diffie Hellmann Verfahren transportiert. Nun baut der Entry-Node, wie gehabt, eine TLS/SSLv3 Verbindung zum Middle-Node auf, um ihn darüber über den Verbindungswunsch zu informieren. Auch die Diffie Hellmann Schlüssel Informationen g x 2 werden auf diesem Weg in der Payload einer Create Cell weitergeleitet. Nun sendet der Middle-Node an den Entry-Node das Acknowledge für den erfolgreichen Verbindungsaufbau zwischen ihnen. Dies erfolgt in Form einer Created-Cell. Zusätzlich werden noch die Diffie Hellmann Schlüsselaustausch Informationen g y 2 der Middle-Node an die Entry-Node weitergeleitet. Die Entry-Node verpackt diese Informationen daraufhin in einer Relay-Extended Cell und schickt diese an den Onion-Proxy weiter. Nun ist eine Kette vom Onion-Proxy zur Middle-Node aufgebaut. Abschließend wird dieser gesamte Vorgang auch noch für den dritten Knoten, den Exit-Node, wiederholt. Der Ausgangsknoten wird anhand seines angebotenen Dienstes ausgewählt. Will man nun anonym auf einen FTP-Server zugreifen, wird dementsprechend ein Ausgangsknoten ausgewählt, welcher den Port 28

34 21 implementiert (vgl. [GSRZ08]). Abbildung 15 stellt den Sachverhalt grafisch dar. Abbildung 15: Verbindung zum Zielrechner mit TOR Das entscheidende Merkmal zur Anonymisierung besteht in folgender Tatsache: Der Middle-Node kann nur den Entry-Node und natürlich später auch den Exit-Node identifizieren. Dem Middle-Node ist der eigentliche Client durch diese Technik gar nicht bekannt. Jedem Node ist nur der direkte Vorgänger und Nachfolger bekannt, so dass keine Instanz im Netz alles weiß. Bei der ersten Generation des Onion-Routing konnte pro Verbindungsstrecke nur ein TCP-Stream weitergeleitet werden. Sollten also mehrere TCP-Streams transportiert werden, war es notwendig, mehrere Ketten aufzubauen. Dieser Vorgang kostet Zeit. Mit steigender Anzahl von zu errichtenden Ketten akkumuliert sich dies. TOR verwendet Onion-Routing der zweiten Generation. Hier ist es möglich über eine Verbindungskette mehrere TCP-Streams zu leiten. Der Onion-Proxy erstellt stellvertretend für den TOR-User ständig neue Verbindungsketten. Dies wird für den Fall gemacht, wenn eine alte Kette wegen den Timervorgaben keine offenen Streams mehr transportieren darf. 29

35 7.5 Gefahrenmodell und Sicherheitslücken Genau wie JAP hat auch TOR einige Schwachpunkte, welche man zur Identifizierung einer Person oder zur Schädigung des Netzes ausnutzen kann Überwachung der Knoten Ist es einer Instanz möglich, einen Großteil der im Tor-Netzwerk verwendeten Knoten zu überwachen, kann die Kommunikation offen gelegt werden und User werden identifiziert. Je mehr Knoten der Angreifer unter Kontrolle hat, umso höher ist die Wahrscheinlichkeit, dass er den Anonymisierungsprozess untauglich machen kann. Eine mögliche Variante ist es, eine höhere Zahl an eigenen TOR- Nodes zu betreiben, um diese dann abzuhören (vgl. [Rue07]). Die Gefahr besteht darin, dass man nicht immer weiß, wer mit welchen Absichten einen TOR-Node betreibt. So gibt es laut einer Untersuchung der Teamfurry-Community [Bac07] eine größere Zahl von TOR-Nodes, die lediglich Plaintext Nachrichten weiterleitet Reduzierung der Nodes Anstatt zu versuchen, möglichst viele Nodes zu kontrollieren, wird hier darauf gesetzt, die Anzahl der Nodes im Netzwerk zu minimieren. Dies geschieht auf unterschiedlichem Weg. Zum einen kann ein Angreifer versuchen, Nodes mit einem Denial of Service Angriff lahm zu legen. Eine andere Möglichkeit besteht darin, andere User davon zu überzeugen, das eine gewisse Node im Netz nicht vertrauenswürdig ist und daher gemieden wird (vgl. [DMS08]). Umso weniger Nodes im Netz sind, umso leichter fällt die Identifizierung eines Users. 8 I2P - Internet Invisible Project 8.1 Informationen zu I2P I2P ist ein Anonymisierungsprojekt der neueren Generation, welches zur anonymen Kommunikation genutzt wird. Das Projekt wird von vielen freiwilligen Entwicklern über die Kontinente verteilt und seit Februar 2003 vorangetrieben. Da es OpenSource ist, kann jeder den Java-Code einsehen und verändern. Die Software befindet sich momentan in der Version Es sind fast alle relevanten Protokolle wie HTTP, POP3, SMTP, IRC und viele weitere mit diesem System nutzbar. Durch kryptographische Verfahren wird eine Ende-zu-Ende Verschlüsselung erreicht. Die Kommunikation erfolgt größtenteils über das UDP-Protokoll. Das TCP-Protokoll wird auch unterstützt. Die Datagramme sind dabei maximal 30

36 32 KiloByte groß. I2P ist freie Software und steht unter mehreren Lizenzen wie z.b. GNU GPL, Public Domain, Cryptix und BSD-Lizenz. 8.2 Relevante Entwurfskriterien I2P ist ein in sich geschlossenes Netz, das aber durch bestimmte In- und Outproxies mit dem WWW kommunizieren kann (vgl. [Sch08f]). Für die Kommunikation in das normale Internet ist dieses System nicht gedacht. Man kann hier selbst den Grad der Anonymität ändern. So besteht die Möglichkeit, die Anzahl der sich am eigenen Tunnelaufbau beteiligenden Peers (Router anderer Nutzer) selbst festzulegen. Umso mehr Hops in diesem Tunnel genutzt werden, umso länger dauert die Kommunikation. Auch die Zuverlässigkeit nimmt mit steigender Anzahl an Hops ab. Vorteile ergeben sich dafür in Bezug auf die Anonymität, da die Pakete einen längeren Weg über mehrere Stationen zurücklegen. Je nach eigener Bandbreite kann hier gewählt werden. 8.3 Begründung der Auswahl Beim Internet Invisible Project I2P werden die im Studium kennen gelernten Transportprotokolle UDP und TCP in einer auf Anonymität abgeänderten Form eingesetzt. I2P stellt ein eigenes anonymes Netzwerk im Internet dar. Dieser Ansatz ist von vielen anderen bekannten Anonymisierungsverfahren verschieden und verdient daher, aufgezeigt zu werden. Sogenannte eepsites, das I2P Pendant zur normalen Website, können nur erreicht werden, wenn man sich mit dem Anonymisierungsnetz verbindet und über einen InProxy darauf zugreift. Auch kann hier, wie bei TOR, ein versteckter Dienst initialisiert werden. Dies ist vergleichbar mit dem Freenet-Project 13, wobei man dort nur auf Seiten innerhalb des Freenet- Netzwerks zugreifen kann und nicht auf herkömmliche Internet Seiten. 8.4 Technische Realisierung Beim I2P Project wird eine Verbindung nicht zu einer anderen IP-Adresse aufgebaut, sondern an ein Pseudonym. Diese Pseudonyme heißen in diesem Zusammenhang Destinations. So kann Teilnehmer A mit Teilnehmer B kommunizieren, ohne dass die jeweiligen IP-Adressen bekannt sind. Startet man in seinem Betriebssystem die I2P Software, fängt diese an, sich ins Netzwerk zu verbinden und damit auch zu anderen Peers. Bei diesem Start werden mehrere unidirektionale Tunnel je nach Kapazität der Bandbreite aufgebaut. Dieser Vorgang wird Bootstrapping genannt. Der eigene Router fragt hierbei die RouterIn f o $hash.dat

37 von einem aktiven Seednode im Netz ab und speichert diese im eigenen NetDB- Verzeichnis auf der lokalen Festplatte ab. Zur Zeit gibt es 4 dieser Seednodes. Eine Seednode ist ein normaler Router, der die NetDb ins normale Internet freigegeben hat. Die RouterInfo gibt hierbei Auskunft über die Identität eines anderen im Netzwerk vorhandenen Routers. Danach legt der Router seine eigene Info anderen Peers im Netz dar, damit er bekannt wird [Sch08c]. Anschließend verbindet sich der eigene Router zu einigen der Router, deren Infos er von den Seednodes bekam 14. Seednodes sind die ersten I2P Router, die beim Start von I2P benötigt werden, um Verbindungen aufzubauen. Es entstehen ausgehende (Outbound) und eingehende (Inbound) Tunnel (vgl. [Sch08d]). Abbildung 16: I2P Tunnel Jeder Tunnel besteht aus n Routern. Bei ausgehenden Tunneln ist der erste Router in der Reihe der eigene Router, dann folgen Router, die von anderen Usern des Netzwerks bereitgestellt werden. Der Router am Ende der Reihe ist der Endpoint-Router. Der Router, der beim eingehenden Tunnel Nachrichten stellvertretend für den eigenen Router annimmt, ist der Gateway-Router. Nach diesem Gateway-Router stehen wieder mehrere Router anderer User in der Reihe, bevor der eigene Router letztendlich die Nachricht empfängt (siehe Grafik 17). Abbildung 17: eingehender I2P Tunnel Die Auswahl der partizipierenden Router wird als Peer Selection bezeichnet. Hierbei werden mithilfe des Peer Profiles Informationen über die Geschwindigkeit, die Belastbarkeit und die Fehleranfälligkeit eines anderen Peers erhoben. Jedes Peer Profil enthält folgende Statistiken: 14 Information durch Korrespondenz mit Entwickler 32

38 Dauer eines Querys an die NetDB Anzahl der fehlgeschlagenen Tunnel-Aufbau Versuche Anzahl der neuen Peers, die über den Peer eingebunden werden können wann besagter Peer das letzte Mal online war wann der letzte Kommunikations-Fehler auftrat Dabei sind die Profile an sich sehr klein gehalten, so dass ein Router mehrere tausend Profile verarbeiten kann, ohne größeren Overhead zu erzeugen. Es gibt einen Algorithmus, der inaktive oder schlecht bewertete Peers von gut funktionierenden trennt, bzw. in verschiedene Klassen unterteilt (fast, High capacity, not failing). Zum Routen von Tunneln werden nur die fast Peers verwendet. Genauso wie sich die Router von anderen Usern an Tunneln beteiligen, partizipiert auch der eigene Router an einer beliebigen Stelle an fremden Tunneln. Auf diesem Wege wird also der Verkehr von anderen I2P-Usern über den eigenen Router geleitet. Nur der Zielrechner bzw. Router ist dazu in der Lage, die Nachricht zu entschlüsseln. Der Schlüsselaustausch wird laut [Sch08a] durch Diffie-Hellman ausgehandelt. Dabei kommt eine 2048-Bit Diffie Hellmann Implementation mit Station-zu-Station Authentifizierung und ElGamal / AES+SessionTag zum Einsatz. Verschlüsselt wird durch 256-Bit AES, signiert wird mit einem 1024-Bit DSA Schlüssel. Durch die Streaming-Lib werden die ankommenden Datenströme zusammengesetzt und an die entsprechenden Ports weitergeben, z. B. Port 80 bei einer HTTP-Verbindung. Dasselbe Prinzip wird auch für ausgehende Daten angewendet. Weiterhin wird ein Schlüsselpaar, bestehend aus Private und Public-Key, zur Wegelenkung genutzt. Der Public-Key, auch Destination genannt, kann im Netzwerk den anderen Usern bekannt gegeben werden. Vergleichbar ist dies mit dem DNS-Namensauflösung im normalen Internet. Zudem wird dieser öffentliche Schlüssel in der Datei hosts.txt auf der Festplatte im I2P Verzeichnis gespeichert. Wie etwas weiter oben schon erklärt, nimmt der Gateway Router stellvertretend für den eigenen Router, die Pakete an, welche er dann über den InBound-Tunnel des Ziel-Routers, also die zwischenvermittelnden Router, an das Ziel weiterleitet. Genau dieser Gateway-Router schreibt einen Eintrag in die NetDB. Die NetDatabase enthält Informationen über die Router, die sich momentan im I2P Netzwerk befinden. Zudem sind dort Informationen zur Wegelenkung enthalten. Die Informationen, welche in der NetDB abgespeichert werden, nennt man LeaseSet. In jedem Lease sind folgende Informationen bestimmt: der Gateway Router eines Tunnels (anhand seines Hash-Wertes) die Tunnel-ID (4 Byte Wert) 33

39 Time-to-live des Tunnel Will sich also ein I2P User mit einem Ziel verbinden, erfährt er über die NetDB, über welche Router dies möglich ist. Die Anfrage an die NetDB kommt dabei aber nie von dem Router, also dem I2P-Nutzer, welcher sich mit einem Ziel verbinden will. Die Anfrage kommt von dessen Gateway-Router. Dann kann sich der Nutzer über seinen Outbound-Tunnel zu dem Inbound-Tunneln des erfragten Gateway- Routers verbinden. Über den Gateway-Router Tunnel gelangen die Pakete dann zum Ziel. Eine Vereinfachung stellt hier das sogenannte Garlic Routing[Sch08b] dar. Hierbei packt der Sender der Nachricht noch seine aktuelle Lease-Information hinzu, so dass dem Empfänger, wenn er antworten will, die Anfrage zur NetDB erspart bleibt (vgl. [Sch08f]). Beim Garlic-Routing wird eine Nachricht folgendermaßen in n Layern verschlüsselt: Die oberste Schicht des Paketes wird mit dem Public-Key des Empfängers verschlüsselt. Als nächstes wird dieses Paket mit dem Public-Key des nächsten Routers auf dem Weg vom Empfänger zum Ziel verschlüsselt, dies ist hier der Hop 1-Router. So wird pro Router auf dem zurücklegenden Weg eine verschlüsselte Schicht aufgetragen (vgl. [Sch08b]). Dieses Vorgehen ist ähnlich zu JAP und TOR. Um einer Verkehrs-Analyse vorzubeugen, werden die einzelnen Pakete jeweils mit Padding-Daten aufgefüllt. Das Garlic Routing wird für folgende Aufgaben genutzt: Aufbau von Tunneln Nachrichtentransport Status-Abfrage Einträge in die NetDB schreiben Die Netz-Datenbank arbeitet mit Flood-Fill-Routern. Es existieren Flood-Fill Router, die zu jeder Destination den Inbound Tunnel Gateway und die Tunnel ID speichern und auf Anfrage an die Router senden. Jede Destination sendet ihre Lease- Set an die Flood-Fill Router. Das Lease-Set setzt sich aus der Destination ID, der Tunnel ID zum Erreichen der Destination und dem Inbound Tunnel Gateway zusammen. Die Lease-Sets ändern sich beim Aufbau neuer Tunnel. Wird also der Weg zu einer Destination benötigt, wird dieser über den Flood-Fill Router erfragt. Die Flood-Fill Router synchronisieren sich untereinander. 15 Die Anonymisierung wird durch folgenden Punkt erreicht: Es ist nicht der eigene Router, der sich mit seiner Destination in der NetDB einträgt und so seine Erreichbarkeit publiziert, sondern es ist lediglich der Gateway-Router des aktuell verwendeten Inbound-Tunnels. Zudem ist dieser Entry (Lease Set) in der NetDB 15 Information durch Korrespondenz mit Entwicklern 34

40 zeitlich begrenzt. Die TTL dieses Eintrages liegt im Minutenbereich. Ebenso haben auch die Tunnel mit ihren Router eine stark begrenzte Time-to-live. Dadurch wechseln auch die Gateway- und Endpoint-Router sowie die dazwischen geschalteten Hop-Router. 8.5 Gefahrenmodell und Sicherheitslücken Da I2P wie auch andere Anonymisierungsverfahren angreifbar in Bezug auf die Identitätsfindung der Teilnehmer sind, gibt es eine größere Zahl von möglichen Angriffen. Es werden hier nur einige davon vorgestellt. Einige Angriffsarten haben zudem lediglich das Ziel, die Nutzung des Anonymisierungsverfahren unmöglich zu machen, indem wichtige Ressourcen angegriffen werden CPU Load Attacke Hierbei führt ein Angreifer auf einem ausgesuchten Peer im Netz rechenintensive kryptographische Operationen aus. Die Absicht besteht laut [Sch08e] darin, so viele kryptographische Operationen auszuführen, dass das Zielsystem überladen bzw. überlastet wird. Dies ist ein typisches Erkennungsmerkmal für ein Denial of Service Angriff. Auf diese Weise kann ein Peer im Netz für eine gewisse Zeit ausgeschaltet werden Sybil Attacke Hier generiert der Angreifer eine beliebig große Anzahl von zusammenwirkenden Nodes, um somit die Kontrolle über das Netz zu erlangen. Um eine solche Attacke auszuschließen, müsste jeder Node im Netz die Identität jedes anderen Nodes auf Korrektheit überprüfen können. Wie viele Nodes ein Angreifer generieren oder kontrollieren muss, damit der Angriff erfolgreich verläuft, hängt von 2 Werten ab: tatsächliche Größe des P2P-Netzes Redundanz im Netz (redundante Routen, redundante Daten) Es ist wichtig, die Sybil-Attacke zu erwähnen, da sie grundlegende Replikationsmechanismen im Netz ausschalten kann (vgl. [Sch08e, DH07]). Das Netzwerk kann durch diese Attacke den Zusammenhalt verlieren. 35

41 9 Archicrypt Stealth VPN 9.1 Informationen zu Archicrypt Stealth VPN Archicrypt Stealth VPN unterscheidet sich von den anderen hier aufgeführten Anonymisierungsdiensten dadurch, dass es ein kommerzielles Produkt ist. Aus diesem Grund ist es auch nur teilweise auf Open-Source Basis entwickelt worden. Genauer gesagt, ist das Frontend und die Funktion, wie das Datenvolumen berechnet wird, hier als Closed-Source verwirklicht. OpenVPN dahingegen ist ein offener Code. Das Programm wurde von der Steganos GmbH in Kooperation mit Softwareentwicklung Patric Remus entwickelt und liegt momentan in der Version vor. Eine Jahreslizenz kostet 79,95 Euro und hat ein monatliches maximales Datenvolumen von 25 Gigabyte. 9.2 Relevante Entwurfskriterien Das behandelte Programm wendet sich größtenteils an den Privatanwender. Lauffähig ist das Tool daher auf den Microsoft Plattformen Windows 2000/XP/Vista. Anders als z. B. JAP, welches nicht bei allen Internetdiensten anwendbar ist, kann Archicrypt Stealth laut [Rem08] bei jeder möglichen Kommunikation mit dem Internet genutzt werden. Lediglich das anonyme Versenden und Empfangen von s ist hier nicht verwirklicht. Das hat allerdings keine technischen Gründe. Dies wurde so implementiert, um möglichen Missbrauch zu unterbinden. 9.3 Begründung der Auswahl Dieses Programm wurde vorrangig aus zwei Gründen zur Evaluierung ausgewählt. Zum ersten soll gezeigt werden, ob ein kommerzielles Produkt mehr überzeugen kann als ein freies Produkt. Gerade wenn es um Surf-Geschwindigkeit geht, weisen kommerzielle Produkte oft sehr gute Ergebnisse auf, da sie über andere Ressourcen als freie Systeme verfügen. Der zweite Grund, weshalb dieses Produkt auserwählt wurde, liegt in der von allen anderen hier aufgeführten Systemen völlig verschiedenen Arbeitsweise. Archicrypt Stealth ist das einzige Produkt, das die OpenVPN Technik nutzt. OpenVPN ist eine gängige Technik des Virtual Private Network, welche für die Verschlüsselung der Informationen und Authentifizierung der Teilnehmer sorgt. 9.4 Technische Realisierung Das Programm arbeitet mit der Verwendung eines Virtual Private Networks. Es wird zwischen dem eigenen Rechner und dem Archicrypt VPN-Server eine OpenVPN- 36

42 Verbindung initialisiert. Der generelle Ablauf wird in Grafik 18 deutlich: Abbildung 18: verschlüsselte Verbindung zum Archicrypt VPN-Server [Rem08] Diese Verbindung muss verschlüsselt sein, da sie auf einem öffentlichen Netz, hier dem Internet, aufsetzt. Zu dem Zeitpunkt, an dem die verschlüsselte VPN- Verbindung, also der Tunnel, fertig aufgebaut ist, ist es dem ISP nicht mehr möglich, die Kommunikation des Archicrypt-Anwenders zu beobachten, da alle Informationen durch die OpenSSL Library verschlüsselt werden (vgl. [Rem08, PW07]). Dazu wird TLS (Transport Layer Security) verwendet, ein Protokoll, das auf SSL aufbaut, da ältere SSL-Versionen gewisse Schwachstellen in Bezug auf Sicherheit aufweisen. Die aktuelle Version SSLv3 ist zwar sicher, aber die Nutzung von SSL birgt Risiken. Wollen zwei Hosts eine verschlüsselte SSL-Verbindung aufbauen, wird, um Kompatibilität zu erreichen, automatisch die niedrigere SSL Version ausgewählt. Falls die niedrige Version nun SSLv1 ist, kann die Kommunikation nicht als sicher eingestuft werden, da SSLv1 nicht den heutigen Sicherheitsstandards entspricht. Unter OpenVPN ist es daher möglich, dieses Fallback auszuschalten, damit keine unsichere Verbindung aufgebaut wird. Diese Prozedur bewirkt nun, dass die zu übertragende Payload mit dem gewählten Verschlüsselungsalgorithmus 16 sicher gesendet werden kann. Außerdem kann die Identität von beiden an der Kommunikation beteiligten Stationen nachgewiesen werden, da dies durch asymmetrische Verfahren 17 bewirkt wird. Durch eine verschlüsselte Verbindung lässt sich auch die Integrität der Daten überprüfen, indem man den HMAC (Hashed Message Authentification Code) auf die Payload der Pakete anwendet. Dabei wird vor dem Sendevorgang die Nutzlast jedes Paketes mit einem SHA oder MD5 Fingerprint gekennzeichnet. Unterscheidet sich jetzt der HMAC beim Empfänger von dem des Senders, wird dieses Paket verworfen. Nachdem solch ein VPN-Tunnel zwischen zwei Instanzen aufgebaut ist, hat man in seinem Betriebssystem ein neues virtuelles Netzwerk-Device. Durch dieses zusätzliche virtuelle Device ist OpenVPN flexibler als andere VPN-Lösungen, welche tief in den Betriebssystemkern eingreifen, da diese Verfahren dann strikt an ein gewisses Betriebssystem gebunden sind. Bei der Wegelenkung der Pakete durch den 16 RC4 oder DES 17 RSA oder DSS 37

43 Tunnel wird ein Trick angewendet. Die im Tunnel versendeten Pakete sind ineinander geschachtelt. In der Payload eines IP-Paketes befindet sich ein weiteres vollständiges IP-Paket mit Header und Payload. Es existiert also ein äußerer IP- Header und ein innerer IP-Header. Das IP-Paket, welches ein weiteres IP-Paket in sich trägt, wird anhand seiner Header-Informationen durch den Tunnel geroutet. Der äußere IP-Header lenkt das Paket zum anderen Ende des Tunnels. Am Endpunkt angekommen, wird das innere IP-Paket vom Empfänger entpackt und an den eigentlichen Bestimmungsort gesendet. 18 Dies geschieht mit Hilfe des inneren IP-Headers, da dieser den Original-Sender und den wirklichen Empfänger des Datagramms enthält.[sim08] Abbildung 19: Tunnel-Prinzip [PW07] Die Wegelenkung der Pakete geschieht über das TCP/IP-Protokoll. Die Flusskontrollmechanismen von TCP sorgen für eine Einhaltung der Paketreihenfolge, gute Bandbreitenausnutzung und Übertragungswiederholung bei Fehlübertragungen. Das UDP-Protokoll wird von der Software nicht anonymisiert, weshalb die Verwendung von UDP bei eingeschalteter Anonymisierung verhindert wird. Da die Aufgabe hier in diesem Fall darin besteht, eine Verbindung zwischen zwei Hosts herzustellen, nämlich dem Archicrypt VPN-Server und dem User-PC, wird hier der Point-to-Point Modus genutzt (vgl. [PW07]). Die Anonymisierung erfolgt also durch folgende Maßnahme: Es wird ein abhörsicherer Tunnel zu einem der Archicrypt VPN-Server aufgebaut. Durch diesen Tunnel werden nun alle Anfragen an den VPN-Server weitergeleitet. Das Relevante hierbei ist, dass der VPN-Server diese Anfragen nicht direkt weiterleitet, sondern sie selbst an die entsprechende Instanz stellt. Dies funktioniert natürlich 18 Abbildung 19 zeigt das Tunnelprinzip auf 38

44 in beide Richtungen. 9.5 Gefahrenmodell und Sicherheitslücken Da das Produkt Archicrypt Stealth VPN auf der Technik von OpenVPN basiert, werden hier einige bekannte Schwachstellen von OpenVPN bzw. VPN aufgezeigt. Allgemein gilt die VPN-Technik aber als sehr sicher OpenSSL-Bug Für die Zertifikatsverwaltung wird bei OpenVPN wie in [PW07, BLTR06] beschrieben, das SSL-Toolkit OpenSSL verwendet. Im Mai 2008 gab das Debian- Projekt einen Sicherheitsmangel [The08a] im verwendeten OpenSSL-Paket bekannt. Der Zufallsgenerator im verwendeten OpenSSL Paket ist berechenbar. Betroffen sind in erster Linie alle Debian basierten Betriebssysteme. Möglich ist aber auch eine Infizierung anderer Betriebssysteme, wenn dort ein in Debian erzeugter Schlüssel importiert wird. Dieser Bug kann mittlerweile allerdings selbständig behoben werden Preshared Keys (PSK) In [PW07, BLTR06] wird auf mögliche Schwachstellen hingewiesen, welche durch die Nutzung des PSK-Verfahrens entstehen können. Hier muss vor der Kommunikation auf möglichst sicherem Weg ein Schlüssel ausgetauscht werden. Nach dem Schlüsselaustausch kann ein Tunnel zwischen den beiden Rechnern aufgebaut werden. Da man aber immer den gleichen Schlüssel verwendet, ist die Forward-Secrecy gefährdet. Wird durch einen Angriff der Schlüssel herausgefunden, ist es dem Angreifer möglich, ab dort immer die Kommunikation zu überwachen. Auch vorher aufgenommene, verschlüsselte Kommunikation lässt sich so entschlüsseln. Ein weiterer Nachteil dieses Vorgehens besteht darin, dass der Key vorher im Plaintext auf beiden Rechnern sein muss. Daher wird von dieser Authentifizierungsmethode abgeraten. 10 Evaluierung der Programme Der Hauptteil dieser Arbeit ist die summative Evaluation der Anonymisierungsprogramme. Die hier zu evaluierenden Produkte erfüllen die in Kapitel 5.1 aufgestellten Muss-Kriterien. Ziel dieser Evaluation ist es, neben der Überprüfung der Software-Funktionalität auch auf eventuelle Probleme beim Benutzen der Software aufmerksam zu machen. Eng mit den Einsatzmöglichkeiten der Software 39

45 wird auch eine Einteilung bzw. Empfehlung der Software für bestimmte Zielgruppen durchgeführt. Als Evaluierungskriterien dienen hier Fragestellungen qualitativer sowie quantitativer Art. Die Fragestellungen splitten sich dabei in folgende Aspekte auf: Allgemeine Fragen Fragen zur technischen Seite des Verfahrens / Produktes Fragen bezüglich der Verkehrsdatenprotokollierung Bewertung des Preis- / Leistungsverhältnis Die Bewertung erfolgt hier nicht, wie oft angewendet, anhand eines Scoring, weil sich eine gerechte Punktevergabe hier als schwierig erweist. Die Bewertung wird in Kommentarform bzw. schriftlich durchgeführt. Alle Anonymisierunsprogramme wurden für diese Arbeit auf einem Testrechner mit folgenden Daten installiert: EINHEIT VERWENDETE HARDWARE/SOFTWARE Prozessor Intel Pentium MHz Arbeitsspeicher 1024 DDR-RAM Betriebssystem Windows-XP Professional SP2 Laufzeitumgebung Java Version 1.6.0_07 Skriptsprache Active Perl Build Allgemeine Fragen Tabelle 8: Testrechner Hier werden nun die Einstiegsfragen bzgl. des Installationsaufwandes, der Konfigurierbarkeit und der Plattformunabhängigkeit behandelt Plattformunabhängigkeit In diesem Punkt wird geprüft, ob sich das Produkt nur auf einem bestimmten Betriebssystem installieren lässt, oder ob es diesbezüglich eine Unabhängigkeit aufweist. Eine Plattformunabhängigkeit steht im Einklang mit hoher Verbreitung. JAP: Der Java Anon Proxy ist für alle gängigen Betriebssysteme verfügbar. Dies wird durch die Verwendung des Java Runtime Environment ab der Version erreicht. Für Windows und Apple Systeme kann man sich auf der Projekthomepage die Setup-Datei herunterladen. Für Unix Systeme wird der Quellcode zum 40

46 Selbst-Kompilieren angeboten. Wertung: Die Plattformunabhängigkeit ist vom Hersteller gut verwirklicht worden. Durch den Einsatz von Java, einer plattformunabhängigen Sprache, ist die Nutzung auf allen Java fähigen Betriebssystemen problemlos möglich. Positiv zu bemerken sind die Betriebssystem spezifischen Anleitungen auf der Homepage des Herstellers. TOR: Die TOR-Software arbeitet mit allen wichtigen Betriebssystemen zusammen. Im Internet gibt es fertige Setup-Dateien sowie offenen Code. Je nach Betriebssystem empfiehlt sich die eine oder andere Art der Installation. Es wird eine große Anzahl von Linux bzw. Unix Systemen mit speziell auf die jeweilige Distribution abgestimmten Code unterstützt. Wertung: Es ist den Entwicklern gut gelungen, den verschiedenen Anforderungen der vielen Plattformen gerecht zu werden. Genau wie beim AN.ON-Projekt gibt es auch hier genügend Betriebssystem spezifische Anweisungen. Archicrypt Stealth VPN: Dieses Softwarepaket unterscheidet sich von den anderen dadurch, das es lediglich für die Microsoft Betriebssysteme Windows 2000/XP und Vista verfügbar ist. Da dieses Programm für den kommerziellen Einsatz vorgesehen ist, wäre höchstens noch über eine Adaption auf das Apple-Betriebssystem nachzudenken. Wertung: Die Wahl der Microsoft-Plattform entspricht dem Standard, wenn es darum geht, ein Programm kommerziell zu betreiben. Daher ist dies als gut zu bewerten. I2P: Das Internet Invisible Project ist auf allen Betriebssystemen, auf denen sich Java installieren lässt, lauffähig. Auf der Herstellerseite gibt es im Downloadbereich einen typischen Windows-Installer und Sourcecode für unixiode Betriebssysteme. Somit kann eine hohe Verbreitung des Produktes sichergestellt werden. Wertung: Ähnlich wie bei JAP wird hier auf die Plattform-Unabhängigkeit von Java gesetzt. Dieser Ansatz hat sich schon bei vielen Anwendungen bewährt und ist daher als sinnvoll zu bewerten Installationsaufwand Dieser Absatz beschäftigt sich mit der Installation der zu evaluierenden Produkte. Die Installation auf dem Windows-XP Testrechner erfolgt jeweils durch ein grafisches Menü, wie es unter Windows üblich ist. Die Installation erfolgt also sehr intuitiv und benötigt nur wenige Bestätigungen durch den Nutzer. JAP: Für Windows Nutzer gibt es zwei mögliche Arten des Setups. Zuerst gibt 41

47 es das ganz normale JAP-Setup, welches nur die Applikation auf dem System installiert, für Nutzer, welche bereits eine Java-Laufzeitumgebung installiert haben. Daneben gibt es noch das Jap-Setup, welches zusätzlich noch die benötigte Java 2 Plattform Standard Edition in der Version beinhaltet. Die Größe dieser Setup-Datei liegt bei 15,1 Megabyte. Die Setup-Datei, welche nur die Applikation beinhaltet, ist 124 Kilobyte groß. Der JAP-Client belegt nach der Installation auf der Festplatte 6,03 Megabyte. Positiv ist, dass der Installationsvorgang des Java Anon Proxys logisch aufgebaut ist und daher auch sehr einfach ist. Abschließend bleibt noch zu erwähnen, dass zusätzlich ein Deinstallationsprogramm installiert wird. Wertung: Für Benutzer, welche noch kein Java auf ihrem System laufen haben, gibt es eine größere japsetup.exe, in welche Java bereits integriert ist. Dies ist äußerst hilfreich und daher positiv zu bewerten. Ebenfalls gut ist die Tatsache, dass nach der Installation kein Neustart nötig war. Negativ anzumerken ist, dass im Setup kein bestimmtes Benutzerkonto anwählbar ist, für welches die Installation geltend gemacht werden kann. Die Deinstallation verläuft dafür reibungslos. Das Programm kann über die Systemsteuerung oder über das eigene Deinstallationsprogramm rückstandslos entfernt werden. Lediglich der Eintrag im Windows- Regeditor bleibt erhalten. TOR: Die TOR-Installation ist mit dem Vidalia-Bundle sehr viel einfacher geworden, als noch vor zwei bis drei Jahren. Die Größe der Setup-Datei ist 8,3 Megabyte. Zusatzsoftware wie Privoxy, Tor-Button und die grafische Vidalia- Oberfläche ist direkt in die Installation integriert. Dies minimiert den Installationsaufwand. Auf Wunsch können aber nur bestimmte Applikationen installiert werden. Der Vidalia-Ordner belegt nach der Installation aller Pakete auf der Festplatte 26,40 Megabyte. Wertung: Positiv ist anzumerken, dass nach der Installation kein Neustart nötig ist. Negativ ist leider zu vermerken, dass während des Setups kein bestimmtes Nutzerkonto wählbar ist. Die Deinstallation der Software erfolgt problemlos, entweder über den eigenen Uninstaller oder die Systemsteuerung. Nur im Regeditor bleibt ein Privoxy Eintrag enthalten. Der Installationsaufwand ist hier deshalb als sehr gering einzustufen. Archicrypt Stealth VPN: Die Installation ist intuitiv gestaltet. Die Installations- Datei ist 13.2 Megabyte groß. Nach dem Akzeptieren der Lizenzbedingungen und der Pfadangabe für die Installation folgt ein Auswahlbildschirm, in dem Installationsattribute gesetzt werden können. Dabei wird unterschieden zwischen Mussund Kann-Kriterien. Zu den Muss-Kriterien gehören das Hauptmodul und der VPN-Client. Zu den Kann-Kriterien gehören lediglich Verknüpfungen. Die Installation benötigt 45,2 Megabyte Speicher auf der Festplatte. 42

48 Wertung: Ebenso wie bei den anderen Produkten kann während der Installation kein bestimmtes Benutzerkonto ausgesucht werden. Positiv fällt ins Gewicht, dass die Deinstallation über die Systemsteuerung genauso rückstandslos verläuft. Nach der Installation kann das Programm ohne Neustart direkt genutzt werden. Auch hier ist der Installationsaufwand als äußerst gering anzusehen. I2P: Die aktuelle Setup-Datei ist 8,90 Megabyte groß. Die Installation verläuft nach dem gleichen Schema wie auch bei den anderen Programmen. Für die Installation werden 10,10 Megabyte auf der Festplatte benötigt. Wertung: Positiv fällt auf, dass es hier möglich ist, ein bestimmtes Benutzerkonto auszuwählen. Probleme gab es bei der Inbetriebnahme. Obwohl vorher für die Nutzung von JAP bereits Java installiert wurde, erscheint die Fehlermeldung: Could not find the main class - Programm will exit. Es konnte aber eine Java Runtime Environment (JRE) 19 gefunden werden, welche sowohl I2P als auch JAP gerecht wird. Die Deinstallation erfolgte danach rückstandslos und fehlerfrei. Unter der Voraussetzung, dass ein korrektes JRE installiert ist, ist der hier zu betreibende Aufwand gering Verwaltung / Konfiguration Mittelpunkt dieser Frage sind die Einstellungsmöglichkeiten im Programm selbst. Dabei geht es um den Umfang und um die grafische Aufbereitung der Konfigurationsmöglichkeiten. Natürlich sollte die Programmverwaltung möglichst intuitiv erscheinen. JAP: Die Konfiguration kann durch ein grafisches Menü oder durch Hilfe der Assistenten-Applikation ebenfalls grafisch erfolgen. Unter Windows hat die Konfigurationsdatei den Pfad C:\Dokumente und Einstellungen\Benutzer\jap.conf. Die Konfigurationen werden also clientseitig abgewickelt. Die verschiedenen Einstellungsmöglichkeiten sind themengerecht unterteilt. So befinden sich alle Einstellungen, welche die Programmoberfläche bestimmen, im Erscheinungsbild-Reiter. Insgesamt gibt es fünf Oberbegriffe im Konfigurationsmenü: Erscheinungsbild, Bezahlung, Update, Netzwerk und Debugging. Im den Netzwerk-Konfigurationen kann zwischen freien und kostenpflichtigen Mixkaskaden gewählt werden. Wie man an Grafik 20 erkennt, erhählt man dort noch Informationen zu den Betreibern der Kaskaden. Insbesondere ist hier auf den angezeigten Anonymitätsgrad der Kaskaden hinzuweisen. Der Anonymitätsgrad steigt mit der Anzahl voneinander unabhängiger Mixe in der Kaskade. Dies ist eine wichtige Information für die Auswahl 19 jre1_5_0_15-windows-i586-p.exe 43

49 des Mixes. Im Fehlerfall kann die vorgenommene Änderung auf den Standardwert zurückgesetzt werden. Abbildung 20: Auswahl der Mixkaskaden Wertung: Die Konfigurationsmöglichkeiten bei JAP sind sehr umfangreich. Durch die grafisch gut aufbereiteten Menüs wird kaum Platz für Missverständnisse oder Bedienungsfehler gelassen. Ist man sich z. B. nicht sicher, ob man den Forwarding-Server aktivieren soll, öffnet sich ein Fenster, das eine genaue Erklärung zu dieser Option enthält. Ebenfalls hilfreich ist der Assistent, der bei der Konfiguration genutzt werden kann. Zudem gibt es sehr viele Hilfetexte im Programm. Auch die Sprache ist frei wählbar, so dass jeder Hilfe Suchende eine sehr gute Hilfestellung erhält. Der Benutzer wird während der Programmausführung auf vieles aufmerksam gemacht, wie z. B. die Java/Javascript Deaktivierung im Browser vorzunehmen. Wegen den hier genannten Gründen wird diese Rubrik als sehr gut bewertet. TOR: Einstellungen können bei TOR einerseits durch die grafische Vidalia- Oberfläche oder andererseits durch Editieren der torrc-konfigurationsdatei vorgenommen werden. Der Einsatz von Vidalia ist also nicht zwingend notwendig. Die Konfigurationen werden lokal beim Client gespeichert. Die Vidalia-GUI hat den Vorteil der einfachen Anwendung, deckt aber leider nicht alle möglichen Konfigurationen rund um TOR ab. Die Oberfläche der GUI (siehe Grafik 21) ist so ge- 44

50 staltet, dass alle Bedienelemente gut sichtbar sind, so dass eine intuitive Steuerung folgen kann. Abbildung 21: Vidalia-GUI Die Programmoberfläche ist unterteilt in eine Status-Zone (oberer Teil) und eine Konfigurations/Informationszone (unterer Teil). Das Einstellungsmenü beinhaltet 7 Oberpunkte 20. Im Oberpunkt Beteiligung kann konfiguriert werden, ob man Verkehrsdaten für andere TOR-Nutzer über den eigenen Router weiterleiten will oder ob nur eine Client-seitige Verbindung ins Netzwerk erwünscht ist. Falls man sich für die Weiterleitung fremder Verkehrsdaten entscheidet, ist noch die Wahl der weiterzuleitenden Protokolle zu treffen. Hier stehen die Protokolle HTTP(S), SSL, POP3, IMAP, IRC, Instant Messaging und verschiedene andere SOCKS fähige Protokolle zur Wahl. Weitere Konfigurationsmöglichkeiten befinden sich unter dem Oberbegriff Fortgeschrittene. Hier gibt es, wie man es in Grafik 22 sehen kann, die Möglichkeit, den Kontroll-Port mit einem Passwort zu schützen. Weiterhin ist es Dauer-Anwendern hier möglich, TOR als Dienst unter Windows laufen zu lassen. Demnach wird TOR schon beim Betriebssystemstart im Hintergrund automatisch gestartet. Als eher unwichtig hingegen ist die Wahl des Aussehens anzusehen, solange ein anderes Aussehen sich nicht positiv auf die Human-Computer-Interaction auswirkt. Die Sprachauswahl ist sehr wichtig, damit keine Missverständnisse bei der Bedienung auftreten. 20 siehe Grafik 22 45

51 Abbildung 22: Vidalia-Konfigurationsmenü Wertung: Negativ zu beurteilen ist die Tatsache, dass die Vidalia-GUI nur einen Teil der möglichen Konfigurationen behandelt. Wer feinere Einstellungen vornehmen will, ist gezwungen, die TOR-Konfigurationsdatei zu editieren. Andernfalls werden die im Vidalia-Paket offerierten Einstellungen einem Großteil der Nutzer genügen. Positiv ist zu bewerten, dass die Nutzung von Vidalia vielen Nutzern den Gebrauch von Tor erleichtert. Das Konfigurationsmenü ist übersichtlich und einfach gestaltet, weshalb hier mit gut gewertet werden kann. Archicrypt Stealth VPN: Die Konfigurationsmöglichkeiten im Programm sind sehr gering. Das liegt daran, dass es nicht nötig ist, selbst viele Konfigurationen zu tätigen. Das Programm verbindet sich von alleine zu einem der zur Verfügung stehenden VPN-Server. Da das anonyme Senden von s nicht unterstützt wird, ist dies in der GUI als Ausnahme zu deklarieren. Wertung: Positiv anzusehen ist die Tatsache, dass bei diesem Produkt keine lange Einarbeitungszeit nötig ist. Technisch versierten Nutzern könnten allerdings Konfigurationsmöglichkeiten fehlen. Da sich dieses Produkt aber nicht an PC- Experten, sondern eher an Heimanwender ohne besondere PC-Kenntnisse richtet, ist in dieser Rubrik mit gut zu urteilen. 46

52 I2P: I2P bietet keine GUI, wie es andere Produkte tun. Alle Konfigurationsvorgänge finden hier direkt im Browser statt. Die Konfigurationen werden in separaten Config-Dateien gespeichert, die sich im I2P Verzeichnis auf der lokalen Festplatte befinden. Die Konfiguration erfolgt hier clientseitig. Nach dem Starten des Programms öffnet sich selbständig ein Startbildschirm im Browser. Dieser Bildschirm enthält unter anderem aktuelle Entwickler Informationen, die Anzahl schon aufgebauter Tunnel und die Uptime. Uptime ist die Zeit, die man zum Netzwerk verbunden ist. Mit einem Klick auf Configuration kommt man in das Konfigurationsmenü. Dieses Menü ist sehr umfangreich, so dass hier nur ein kleiner Teil aufgezeigt wird. Network, Service, Update, Tunnels, Logging, Stats und Advanced sind die Oberpunkte des Menüs. Besonders interessant sind die Einstellungen im Punkt Network. Wie man an Abbildung 23 gut erkennt, kann hier die Länge der Tunnel konfiguriert werden. Die Länge des Tunnels bestimmt den Grad der Anonymität. Wertung: Positiv zu beurteilen ist die hohe Menge an Konfigurationsmöglichkeiten. Der Nutzer kann das System an seine Bedürfnisse anpassen. Das Programm an sich ist sehr gut über den Browser zu verwalten. Da das I2P System komplexer als die anderen hier vorgestellten Anonymisierungsverfahren arbeitet, ist eine höhere Einarbeitungszeit nötig. Hier wird ein anderer, aber dennoch guter Ansatz der Konfiguration verfolgt. Aus diesem Grund ist hier mit gut zu urteilen. Abbildung 23: I2P - Tunnelkonfiguration 47

53 Zielgruppe Dieses Kapitel gibt einen Überblick über die Benutzerfreundlichkeit und daher auch darüber, für welche Zielgruppen sich das Programm eignet. Aus den in den Kapiteln und getroffenen Aussagen kann direkt auf Zielgruppen geschlossen werden. Mögliche Gruppierungen für die Zielgruppe sind: PC-Anfänger fortgeschrittener PC-Benutzer PC-Fachmann Ein wichtiges Kriterium zur Beurteilung hierbei spielt die Mensch-Computer- Interaktion (Human-Computer-Interaction). Die Benutzerführung im Programm soll weitgehend selbsterklärend sein. Auch der Punkt der Visibility, nämlich die sofortige Sichtbarkeit aller Bedienelemente, soll vom Programm gut umgesetzt sein. Sind komplizierte Konfigurationsschritte zur Inbetriebnahme des Dienste nötig? Ebenfalls soll geprüft werden, ob spezielles Fachwissen nötig ist. JAP: Aufgrund der vielen positiven Eigenschaften, die in den Kapiteln und erläutert wurden, kann dieses Programm für einen PC-Anfänger empfohlen werden. Das Microsoft-Betriebssystem erlaubt eine grafische und daher unkomplizierte Installation und Verwaltung des Produktes. Ebenso hilfreich sind die vielen Hilfetexte im Programm, welche nicht nur für Experten verständlich geschrieben sind. TOR: Eine Zuordnung zu einer Zielgruppe fällt hier recht schwer. Nutzt man das Vidalia-GUI, reicht es, wenn man ein PC-Anfänger ist. Hilfreich sind auch die zahlreichen Anleitungen im Internet. Für alles Weitere, z. B. die Editierung der torrc-konfigurationsdatei, ist das Wissen eines fortgeschrittenen PC-Benutzers nötig. Archicrypt Stealth VPN: Aufgrund des geringen Installationsaufwandes und der einfachen Handhabung des Programms kann das Programm von einem PC-Anfänger bedient werden. Lange Einarbeitung ist nicht nötig. Die Entwickler haben sich darauf konzentriert, ein möglichst einfaches und unkompliziertes Produkt zu erstellen. I2P: Die Installation von I2P ist sehr einfach. Sehr viel komplizierter sind allerdings die umfangreichen Konfigurationsmöglichkeiten. Das Projekt befindet sich noch in einer frühen Experimentierphase und wird bis jetzt größtenteils von Ex- 48

54 perten getestet. Das aktuelle Produkt kann daher nur für ein PC-Fachmann empfohlen werden Fragen zur technischen Seite des Verfahrens / Produktes Dieses Kapitel vergleicht die zu evaluierenden Produkte aufgrund ihrer technischen Fertigkeiten. Die technischen Einzelheiten wurden hierbei teilweise aus Design-Papern entnommen oder in Form eines Tests ermittelt Internet-Protokolle Für diese Fragestellung wurden die gängigsten Internetprotokolle in Kombination dazugehöriger Programme getestet. Da sich ein Ergebnis in Form einer Tabelle besonders gut darstellen lässt, wird diese Weise zur Veranschaulichung gewählt. JAP: Da durch JAP lediglich HTTP und HTTPS anonymisierbar sind, ist nur anonymes Surfen im Internet möglich. Das HTTP Protokoll gehört zu den meist verwendeten Protokollen im Internet. PROTOKOLL ARBEITET MIT JAP UMSETZUNG/PORT HTTP ja Firefox: :4001 HTTPS ja Firefox: :4001 FTP nur Download (passiv) Firefox: :4001 IMAP/POP3 nein/nein SMTP nein SSH nein Jabber nein IRC nein Torrent nein Tabelle 9: Internet-Protokolle (JAP) Wertung: Bei der JAP-Anwendung liegt das anonymisierte Surfen im Vordergrund. Eine generelle Anonymisierung aller Internetprotokolle ist hier nicht verwirklicht. Neben dem Surfen ist lediglich der anonymisierte FTP-Download mit dem Anon-Dienst möglich. Laut Korrespondenz mit Entwicklern ist es mit der Premium-Version von JAP möglich, das FTP-Protokoll in Bezug auf Upload und Download zu anonymisieren. Die geringe Anzahl unterstützter Protokolle kann nur als ausreichend bewertet werden. 49

55 TOR: Der Onion-Router arbeitet mit einer Vielzahl aller Internet-Protokolle zusammen. Allerdings gibt es Fälle, in denen die Benutzung von TOR gewisse Risiken birgt. Beim -Verkehr beispielsweise ist darauf zu achten, dass der - Abruf mit TLS oder SSL verschlüsselt ist, da ansonsten das Passwort im Klartext den Exit-Node passiert. Betreibern von Exit-Nodes wäre es dann möglich, die Passwörter aufzuzeichnen. Ein anderer ungünstiger Anwendungsfall besteht im BitTorrent-Netzwerk. Dies kann mit TOR kombiniert werden. So ist es möglich, unter fremder IP-Adresse illegale bzw. urheberrechtlich geschütztes Material herunterzuladen. Dies führt den Download illegaler, urheberrechtlich geschützter Daten auf den Betreiber des Exit-Nodes zurück. Der Node-Betreiber hat dann eventuell mit juristischen Problemen zu kämpfen, obwohl er selbst keine Urheberrechtsverletzung begangen hat. PROTOKOLL ARBEITET MIT TOR UMSETZUNG/PORT HTTP ja Firefox: :8118 HTTPS ja Firefox: :8118 FTP ja Leap FTP Socks 5:9050 IMAP/POP3 ja/ja Thunderbird Socks 5:9050 SMTP ja Thunderbird Socks 5:9050 SSH ja Putty Socks 5:9050 Jabber ja Miranda Socks 5:9050 IRC ja Miranda Socks 5:9050 Torrent ja µtorrent Socks 5:9050 Tabelle 10: Internet-Protokolle (TOR) Wertung: Die hohe Flexibilität von TOR ist mit sehr gut zu beurteilen. Durch Einsatz des SOCKS-Protokoll kann TOR transparent und protokollunabhängig mit vielen Anwendungen arbeiten. Archicrypt Stealth VPN: Aufgrund der hohen Anzahl an unterstützten Protokollen kann das Programm entsprechend viel eingesetzt werden. Die fehlende Unterstützung der protokolle POP3, IMAP und SMTP wird hierbei extra vom Hersteller bewirkt, um möglichen Missbrauch vorzubeugen. Technisch realisierbar wäre auch eine Anonymisierung der -Protokolle. 50

56 PROTOKOLL ARBEITET MIT ARCHICRYPT UMSETZUNG/PORT HTTP ja Firefox + TAP-Device HTTPS ja Firefox + TAP-Device FTP ja Leap FTP TAP-Device IMAP/POP3 nein/nein SMTP nein SSH ja Putty + TAP-Device Jabber ja Miranda TAP-Device IRC ja Miranda TAP-Device Torrent ja µtorrent + TAP-Device Tabelle 11: Internet-Protokolle (Archicrypt Stealth VPN) Wertung: Durch das virtuelle TAP-Device wird jede Kommunikation mit dem Internet durch das VPN-Netz geleitet. Die hohe Anwendbarkeit des Programms wird mit sehr gut bewertet. I2P: Das HTTP-Protokoll für das normale Internet kann mithilfe von Outproxies anonymisiert werden. Dies ist allerdings nur ein Zusatz, da sich dieses Projekt größtenteils auf den internen Einsatz spezialisiert. Um s im internen Netz sowie auch im normalen Internet anonym zu versenden, ist die Applikation Susimail zu benutzen. FTP und SSH kann funktionieren, wenn man die Tunnel- Services entsprechend einrichtet. PROTOKOLL ARBEITET MIT I2P UMSETZUNG/PORT HTTP ja (auch ins Internet) Firefox: : Outproxy HTTPS nein FTP nein IMAP/POP3 nein/ja (auch ins Internet) Susimail Account SMTP ja (auch ins Internet) Susimail Account SSH nein Jabber ja (nur intern) Psi: :5222 IRC ja (nur intern) mirc: :6668 Torrent ja (nur intern) I2PSnark: Socks Tabelle 12: Internet-Protokolle (I2P) Wertung: I2P unterstützt in einem frühen Stadium schon viele Protokolle. In Zukunft ist noch mit mehreren Erweiterungen zu rechnen, was auch die positive Bewertung rechtfertigt. 51

57 Ist die Einwahl ins Anonymisierungsnetz verschlüsselt? Falls die Einwahl ins Anonymisierungsnetz nicht verschlüsselt ist, könnte dies zu erheblichen Sicherheitsmängeln in Bezug auf die Anonymität eines Nutzers führen. Beispielsweise könnten Nutzername und Passwörter im Klartext übertragen werden. Die Verschlüsselung soll auch davor schützen, dass der nächste Kommunikationspartner identifiziert werden kann. Ein Anonymisierungsdienst muss ebenso vor der lokalen Überwachung des Internet-Verkehrs schützen. JAP: Beim Kommunikationsvorgang werden laut Korrespondenz mit JAP Entwicklern die Daten im Anonymisierungsnetz mehrfach mit AES-128 verschlüsselt. Mit mehrfacher Verschlüsselung ist hier gemeint, dass Datenpakete für jeden Mix-Server in der Kaskade einzeln mit AES-128 Bit-Schlüssellänge verschlüsselt werden. Dies geschieht also 2- oder 3-fach, je nach Länge der Mixkaskade 21. Damit ist natürlich auch die erste Mixkaskade im Netz gemeint. Eine Untersuchung mit dem Programm Wireshark (siehe Kapitel 12.2) kam zu dem Ergebnis, dass die Daten verschlüsselt werden. Ebenso wird die verschlüsselte Einwahl ins Anonymisierungsnetz in Fachliteratur [BM03] erwähnt. Wertung: Eine unverschlüsselte Einwahl ins Anonymisierungsnetz wäre aus oben genannten Sicherheitsgründen sofort mit ungenügend zu bewerten. Der hier verwendete AES-128 Algorithmus wurde in der Vergangenheit mehreren kryptoanalytischen Untersuchungen bzw. Angriffen ausgesetzt. Da der Algorithmus in diesen Tests überzeugen konnte, gilt er als sicher. Der Einsatz und die Wahl dieses Verschlüsselungs-Algorithmus ist demnach verständlich. TOR: Aus der Fachliteratur[DMS08, DM08] geht hervor, dass für die Absicherung der Verbindungen TLS/SSLv3 verwendet wird. Damit sind die Verbindungen der Onion-Router untereinander gemeint und auch die Einwahl in das Netzwerk. Im Allgemeinen wird dieses Verschlüsselungsprotokoll als sicher angesehen. Auch mit Wireshark war es nicht möglich, sensible Daten abzufangen. Wertung: Der Einsatz und die Wahl der verwendeten Verschlüsselungsalgorithmen ist aus obigen Gründen als sinnvoll anzusehen. Die Tatsache, dass auch bei TOR sensible Daten einer Verschlüsselung unterliegen, ist als sehr gut einzuschätzen. Archicrypt Stealth VPN: Um mit fremder IP-Adresse im Internet surfen zu können, wählt sich die Archicrypt Software bei einem VPN-Server ein. Diese Einwahl entsteht unter Verwendung von OpenVPN. Die Verschlüsselung setzt hierbei auf dem OpenSSL Protokoll auf. Es ist also auch hier nicht möglich, mit Sniffer-Tools 21 https://www.jondos.de/de/node/644 52

58 Informationen im Klartext mit zu lesen. Wertung: Die VPN-Technik gilt als ausgereift und sicher in Bezug auf Angreifer, die versuchen, die Verschlüsselung zu brechen. Die Verwendung der Verschlüsselung ist also mit sehr gut zu bewerten. I2P: Im Anonymisierungsnetzwerk werden Daten nur verschlüsselt übertragen. Auch die Kommunikation zwischen dem Eingang des Anonymisierungsnetzes und des Nutzers ist verschlüsselt. Der Test mit Wireshark bestätigte diese Aussage. Lediglich beim Endrouter werden diese Daten dann unverschlüsselt weitergegeben, genau wie bei JAP und TOR. Bei I2P kommen mehrere Verschlüsselungsalgorithmen zum Einsatz. Es gibt ein symmetrisches Verfahren (AES-256), ein asymmetrisches Verfahren (ElGamal-2048), ein Verfahren zur Erstellung von Signaturen (DSA-1024) und ein Hashing-Algorithmus (SHA256). Es war angedacht, die Kommunikation mit TLS/SSL bzw. SSH abzusichern, was aber zu technischen Problemen führte [Sch08a]. Wertung: Bei I2P wird sehr viel Wert auf kryptographische Schutzmaßnahmen gelegt. Die hier eingesetzten Signatur- und Verschlüsselungsverfahren gelten in der aktuellen Implementierung als sicher. Ein Verfahren gilt generell solange als sicher, bis Gegenteiliges bewiesen ist, was in diesen Fällen noch nicht vorkam. Lediglich bei der ersten, hier nicht mehr verwendeten Version vom Secure Hash Algorithmus wurden Schwächen in Bezug auf die Kollisonsfreiheit festgestellt. Deshalb ist hier die Kryptographie mit sehr gut anzusehen Anonymisierungs-Umfang Hier werden mit Hilfe eines eigens dafür erstellten PHP-Skriptes 22 mögliche Parameter zur Identifizierung ausgewertet. Abgefragt werden folgende Merkmale: IP-Adresse Host Browser Betriebssystem Herkunftsland Die Aufgabe eines Anonymisierungsnetzwerkes besteht darin, das die IP-Adresse des Nutzers durch die IP-Adresse des Ausgangsrouters vom Anonymisierungsnetz ersetzt wird. Selbst wenn alle Felder verändert werden, ist dies noch kein Beweis 22 siehe Anhang, Kapitel

59 für echte Anonymität. JAP: Die JonDos Software besteht den Anonymitätstest. Sie erfüllt die Mindestanforderungen. Hier wird lediglich die echte IP-Adresse unkenntlich gemacht, indem die IP-Adresse des letzten Mix der Mixkaskade verwendet wird. Wertung: Es wäre vorteilhaft, wenn die JAP-Software auch andere Identifizierungsmerkmale anonymisieren würde. Die Anonymisierung der IP-Adresse ist ein befriedigender Ansatz. TOR: Der Onion-Router ersetzt die IP-Adresse durch die IP-Adresse des Exit- Nodes. Was allerdings unverändert bleibt, ist das Betriebssystem und der Browser. Diese Attribute lassen sich durch den Einsatz des Uagen-Perl-Skriptes beliebig ändern. Das Herkunftsland muss hier nicht unbedingt Deutschland sein. Das Land und der Host ist generell abhängig vom Standort des Exit-Node. Wertung: Ähnlich wie bei der JAP-Software werden einige Attribute nicht anonymisiert. Auch hier entsteht nur ein befriedigender Eindruck. Archicrypt Stealth VPN: Auch hier werden die Mindestanforderungen erfüllt. Zwar wird die IP-Adresse durch die Adresse des Archicrypt VPN-Servers ersetzt und der Provider somit unkenntlich gemacht, aber alle anderen Attribute bleiben unverändert erhalten. Wertung: Die Software konzentriert sich auf die Anonymisierung der IP-Adresse, was auch hier nur mit befriedigend geltend gemacht wird. I2P: Als IP-Adresse im Internet fungiert hier die Adresse des gewählten Outproxy. Momentan gibt es nur ein Outproxy (false.i2p) für dieses Projekt. Parameter wie Browser und Betriebssystem werden vom Outproxy überdeckt. Lediglich das Herkunftsland des Outproxies wird angezeigt. Im internen Netz selbst gelingt es nicht, die IP-Adresse herauszufinden (siehe dazu Kapitel ). Wertung: I2P verdeckt mehr Attribute als die anderen Produkte. Diese Implementierung wird mit gut bewertet Partizipiert sich der eigene Router an der Weiterleitung fremder Pakete? Diese Fragestellung zielt darauf ab, festzustellen, ob die eigene IP-Adresse, sprich der eigene Router, für das Routing fremder Pakete benutzt wird. Das eigentliche Problem besteht in der Tatsache, dass die eigene IP-Adresse mit illegalen Aktivitäten anderer Nutzer in Zusammenhang gebracht werden könnte. Für Strafverfolgungsbehörden ist es mitunter schwer nachzuvollziehen, dass zwar ein illegales Paket über den eigenen Router geleitet wurde, das aber nicht für jemanden selbst 54

60 bestimmt war. Falls der eigene Router fremde Pakete weiterleitet, sollte dies jedem Nutzer ganz klar angezeigt werden. Ebenso muss es die Möglichkeit geben, diese Weiterleitung bei Nichtgefallen auszuschalten. JAP: Bei JAP geschieht eine Weiterleitung der Pakete ausschließlich über die Mixe bzw. die Mixkaskaden. Wer das Projekt unterstützen will, darf unter Einhaltung bestimmter Voraussetzungen 23, einen Mix betreiben. Die einzige Möglichkeit, dass fremde Pakete über den eigenen Router gelangen, ist die Forwarding Function. Dadurch kann JAP-Nutzern, denen es nicht möglich ist, sich direkt mit JAP im Internet einzuwählen, der Zugang über den eigenen JonDo-Proxy gewährt werden. Sinnvoll ist dies für Nutzer, welche in Länder mit Internet-Restriktionen sitzen. Wertung: Der JAP-Nutzer muss keinen Verkehr für andere Nutzer über seine eigenen Ressourcen weiterleiten. Dies ist aus oben genannten Gründen als positiv anzusehen. Die Entwickler schützen somit die Nutzer vor eventuellen unangenehmen Konsequenzen. TOR: Standardmäßig ist man mit dem TOR-Netzwerk als Client verbunden. Das bedeutet, dass man keinerlei Pakete für andere Teilnehmer weiterleitet. Dies ist in den Exit-Policies der torrc-konfigurationsdatei so festgehalten. Wer allerdings das Projekt in Form eines Servers unterstützen will, kann dies tun. Bevor man diesen Schritt wagt, sollte man sich allerdings über mögliche Konsequenzen 24 informieren. Eine Anleitung 25 dazu gibt es online. Zur Erleichterung kann hier die Vidalia-GUI genutzt werden. Wie auf den Abbildungen 24 und 25 der nächsten Seite erkennbar ist, sind mehrere Parameter zu berücksichtigen. Anzupassen ist hier die zu Verfügung stehende Bandbreite. Ebenso muss bestimmt werden, welche Protokolle der Server weiterverarbeiten soll. Nach dem Abschließen dieser Konfigurationsvorgänge leitet man Verkehrsdaten für andere Nutzer über den eigenen Router

61 Abbildung 24: Konfiguration eines TOR-Relay (1) Abbildung 25: Konfiguration eines TOR-Relay (2) 56

62 Wertung: Es ist sinnvoll, dass standardmäßig keine Weiterleitung fremder Pakete stattfindet. Die Möglichkeit, dies bei Gefallen zu tun, und damit das Projekt zu unterstützen, ist gegeben. Die diesbezügliche Vorgehensweise der Entwickler ist als sehr sinnvoll zu betrachten. Archicrypt Stealth VPN: Bei der hier eingesetzten OpenVPN-Technik gibt es diesen Ansatz nicht. Die Nutzer dieses Dienstes müssen zu keiner Zeit ihre echte IP-Adresse für den Internetzugang anderer Nutzer bereitstellen. Wertung: Wie in Kapitel schon erläutert, richtet sich dieses Produkt vorwiegend an den PC-Anfänger. Dieser Art von Endnutzer ist sich nicht immer über die mögliche Konsequenzen einer Datenweiterleitung für andere Nutzer bewusst. Dementsprechend ist es gut, dass dies von der technischen Seite her nicht realisiert ist. I2P: Sobald man sich ins Anonymisierungsnetzwerk einwählt, steht der eigene Router für Datenweiterleitungen anderer Nutzer bereit. Dabei kann der eigene Router die Position eines Hop-Routers, eines Endpoint-Routers oder die eines Gateway-Routers übernehmen. Lediglich als Exit-Router für das öffentliche Internet kann der eigene Router nicht dienen. Momentan gibt es einen statischen Proxy (false.i2p) für das Internet. Wer keine Daten für andere Nutzer weiterleiten möchte, kann dies konfigurieren, indem er den Parameter Participating tunnels auf 0 stellt. Ebenso kann der Parameter Bandwith-Share konfiguriert werden. 26 Somit steht jedem Nutzer die freie Wahl zu. Wertung: Da man hier frei entscheiden kann, inwiefern man sich an der Datenweiterleitung beteiligt, kann man eventuelle Konsequenzen von vornherein ausschließen. Diese Implementierung ist sehr gut Anonymisierungsprodukte in Bezug auf die Vorratsdatenspeicherung Hier soll analysiert werden, inwieweit der vom Anonymisierungsnetzwerk generierte Verkehr im Rahmen der Vorratsdatenspeicherung erfasst wird. Die Nutzung von Anonymisierungsdiensten ist gesetzlich legal. Trotzdem wird jeglicher Verkehr dieser Dienste in Deutschland durch die Vorratsdatenspeicherung erfasst. Die generelle Frage ist, ob durch die Vorratsdatenspeicherung Anonymisierungsdienste überflüssig werden, da ja jeglicher Verkehr dieser Dienste aufgezeichnet wird. JAP: Um zu prüfen, inwiefern beim AN.ON Projekt die Vorratsdatenspeicherung durchgeführt wird, wird der Standort jedes Mixes aller verfügbaren Mixkaskaden geprüft. Die Mixkaskaden weisen dabei, je nach angestrebter Sicherheit in Bezug 26 dies ist im Punkt Client tunnels for shared clients zu bewerkstelligen 57

63 auf Anonymität eine Länge von 2 bis 3 hintereinander geschalteten Mixen auf. In jeder Kaskade ist mindestens ein Mix enthalten, der den Standort Deutschland hat. Somit ist zumindest ein Teil jeder Kaskade von der Vorratsdatenspeicherung betroffen. Wenn der Rest der Kaskade im EU-Ausland steht, ist er ebenfalls von der Vorratsdatenspeicherung betroffen. Da diese Kaskaden im Gegenteil zu TOR- Nodes statisch sind, ist hier auch keine Änderung möglich. Wertung: Der hier festgestellte Sachverhalt ist negativ zu bewerten, da zumindest ein Teil der Kommunikation über die Kaskaden von der Vorratsdatenspeicherung erfasst werden wird. Teilweise gibt es sogar Mixkaskaden, wo jeder eingebundene Mix in Deutschland steht. Das ist in Bezug auf die Vorratsdatenspeicherung unvorteilhaft. In Zukunft müssen die Mixe gezielt in Ländern in denen keine Vorratsdatenspeicherung oder sonstige Internet-Beschränkungen herrschen, aufgestellt werden. Die JonDos GmbH hat sich auf ihrer Homepage [Jon08] selbst zu diesem Thema geäußert und auch eine Internationalisierung des Dienstes vorausgesagt. TOR: Der Onion-Router baut seine Circuits in der Regel dynamisch auf. Dies ist aber nicht zwingend der Fall. Es besteht die Möglichkeit die am Circuit-Aufbau beteiligten Router in der torrc-konfigurationsdatei anzugeben. Somit ist es auch möglich, alle Router mit Standort Deutschland davon auszugrenzen. Auf diese Weise kann der komplette Tunnel, bestehend aus Entry, Rend und Exit-Node, vorkonfiguriert werden. Listing 1 zeigt ein mögliches Szenario. EntryNodes TorJapan, papio RendNodes cuogh ExitNode dodep, defendyourfreedom S t r i c t E n t r y n o d e s 1 S t r i c t E x i t N o d e s 1 Listing 1: Node-Festlegung in torrc #TorJapan : Japan # papio : Daenemark #cuogh Sweden #defendyourfreedom F r a n k f r e i c h #dodep Sweden Die Kommunikation beginnt im Entry-Node. Dieser Knoten liegt hier entweder in Japan oder in Dänemark. Der Rend-Node, also der mittlere Knoten, ist hier aus Schweden. Selbstverständlich könnte man noch beliebig mehr Knoten hinzufügen. Es empfiehlt sich sogar, hier Redundanzen in Bezug auf Ausfallsicherheit herzustellen. Der Exit-Node liegt hier wahlweise in Schweden oder Frankreich. Der Strict Befehl garantiert, dass nur die dort aufgeführten Nodes verwendet wer- 58

64 den. Ohne den Strict Befehl würden diese Nodes lediglich bevorzugt werden. Informationen zu den TOR-Nodes gibt es im Internet. 27 Durch einen Test mit Wireshark 28 konnte gezeigt werden, dass hier wirklich TorJapan als Entry-Node für die Kommunikation genutzt wird. Mit dem in Kapitel 12.1 vorgestellten PHP-Skript lässt sich dann auch der Exit-Node bestimmen. Möglich wäre es auch, Router aufzuzählen, welche nicht benutzt werden dürfen. So könnten alle Nodes in einem Land ausgeschlossen werden, das eine Vorratsdatenspeicherung betreibt. Listing 2 zeigt dies. Listing 2: Node-Ausschluss in torrc ExcludeNodes a t a r i, FoeBuD3, lolnode, chaoscomputerclub17, YingYang, Orion01 Auf diese Weise wurden nun einige deutsche und chinesische TOR-Server gebannt. Die Liste ist natürlich mit allen EU-Mitgliedsstaaten, die eine Vorratsdatenspeicherung betreiben, beliebig zu erweitern. Wertung: TOR ist sehr flexibel in der Konfiguration. Durch Konfiguration ist es möglich, an der Vorratsdatenspeicherung vorbeizulenken. Eine Festlegung auf ganz bestimmte Nodes im Netzwerk kann allerdings Korrelationen zulassen. Dies könnte im schlimmsten Fall sogar zur Deanonymisierung beitragen. Damit wäre das Gegenteil des Gewollten erreicht. Ebenfalls nicht geklärt ist, ob ein privater DSL-Nutzer, der sporadisch das TOR-Netzwerk unterstützt, zu den Telekommunikationsdiensten zu zählen ist [Kre07a]. In dem unwahrscheinlichen Fall wäre auch ein privater DSL-Nutzer zur Speicherpflicht angehalten. Trotzdem eignet sich der TOR-Dienst sehr gut dazu, bestimmte Länder auszugrenzen. Archicrypt Stealth VPN: Das Archicrypt Produkt enthält nicht die Möglichkeit, sich die VPN-Server nach Belieben auszuwählen. Die Software verbindet automatisch, unter Beachtung des Parameters Load-Balancing, zu einem zur Verfügung stehenden Server. Die VPN-Server der Firma Archicrypt stehen ausschließlich in Deutschland. Somit ist die Firma in vollem Umfang der Vorratsdatenspeicherung unterworfen. Wertung: Dieser Anonymisierungsdienst hat im Gegensatz zu TOR nicht die Möglichkeit, durch Konfiguration an der Vorratsdatenspeicherung vorbei zu lenken. Dies wird durch den statischen Aufbau verhindert. Es stellt sich nun die Frage, inwieweit ein Anonymisierungsdienst, der in vollem Maße unter die Vorratsdatenspeicherung fällt, sinnvoll ist. Anstatt dem ISP in Bezug auf die Verwahrung personenbezogener Daten zu vertrauen, muss der Kunde hier dem Anonymisierungsdienst trauen. Genau wie auch bei JAP ist hier eine Ausweitung des Dienstes Capture-File befindet sich auf CD im Verzeichnis Wireshark-Dateien/Tor-Node-Beobachtungen 59

65 auf Länder ohne Vorratsdatenspeicherung ratsam, da ansonsten die Hauptfunktion dieses Dienstes, nämlich die Anonymisierung, nicht gegeben sein kann. Ebenfalls würde das bedeuten, alle in Deutschland bzw. der Europäischen Union stehenden Server aufzulösen. Die aktuelle Situation kann nur als unzureichend betrachtet werden. I2P: Jeder I2P-Nutzer lenkt standardmäßig, wie in Kapitel erläutert, Verkehr für andere Nutzer über den eigenen Router weiter. Da das I2P-Netz weltweit fungiert, ist es nur partiell in Ländern aktiv, welche eine Vorratsdatenspeicherung betreiben. Eine Ausgrenzung bestimmter Länder konnte in den Konfigurationsmöglichkeiten nicht entdeckt werden. Technisch betrachtet ist das I2P-Netz ein Overlay Netzwerk. In den gesetzlichen Statuten zur Vorratsdatenspeicherung kann keine Information darüber gefunden werden, ob die Vorratsdatenspeicherung auch Overlay-Netzwerke betrifft. Absatz 1 von Artikel 1 [Eur07] trifft die Aussage, dass öffentliche Kommunikationsnetze unter die Vorratsdatenspeicherung fallen. Im Gegensatz zu einem reinem Darknet wird I2P wohl als öffentliches Netz angesehen werden. Wie aus Kapitel 8.4 hervorgeht, wird innerhalb des I2P-Netzes mit Hilfe der Destinations gearbeitet. Demnach hat die IP-Adresse eine untergeordnete Rolle. Die Vorratsdatenspeicherung soll aber genau diese IP-Adresse und den Zeitpunkt speichern. Ebenfalls nicht geklärt ist folgender Fakt: Im Gegensatz zu JAP läuft die Kommunikation bei I2P nicht über Server bzw. statische Mixe, sondern über die Router anderer I2P-Nutzer. Fraglich ist jetzt, wer hier der Speicherungspflicht unterliegt. Würde man die Statuen analog zu TOR und JAP, wo jeder Server bzw. Mixbetreiber in Deutschland zur Vorratsdatenspeicherung verpflichtet ist, anlegen, würde dies eine Speicherpflicht für jeden I2P-Nutzer, der Verkehrsdaten für andere Teilnehmer routet, bedeuten. Dies würde das Ende dieses Netzwerks bedeuten, da wahrscheinlich nur wenige Personen dazu bereit wären. Allerdings ist dies als sehr unwahrscheinlich anzusehen, dass Privatpersonen in diesem Fall zur Speicherung verpflichtet werden. Wertung: Demnach gibt es juristische wie auch technische Fakten, welche das I2P-System in Bezug auf die vorstehende Vorratsdatenspeicherung als empfehlenswert auszeichnen. Aufgrund der anderen Konzeption des Systems entstehen hier mögliche Vorteile gegenüber anderen Verfahren. Aus diesen Gründen ist hier mit sehr gut zu urteilen Ändert sich die zugewiesen IP-Adresse im Laufe der Verwendung? Verbindet man sich in ein Anonymisierungsnetzwerk, ist man mit der IP-Adresse des Ausgangsrouters im Internet unterwegs. Diese Adresse kann während der Nutzung mehrfach protokolliert werden. Manche Dienste bieten an, diese Adresse in periodischen Abständen zu ändern. Natürlich entsteht hierbei wieder Routing- 60

66 Aufwand, was die Geschwindigkeit kurzzeitig nachhaltig beeinträchtigen kann. Je nach Sichtweise wird auch bewusst auf diese Änderung verzichtet. Ändert sich nur die IP-Adresse, aber alle anderen Identifizierungsmerkmale bleiben gleich, kann dies ungewollt Aufmerksamkeit erregen. JAP: Ein Wechsel der genutzten Mix-Kaskade führt zwangsläufig zu einer anderen wahrgenommen IP-Adresse. Ein Wechsel der Kaskade wird aber niemals während einer laufenden Verbindung durchgeführt. Lediglich wenn eine Kaskade Probleme hat, wird automatisch gewechselt. Ebenso kann beobachtet werden, dass beim Programmstart des Öfteren gewechselt wird. Im Normalfall ist man also nach Verbindung zu einer Kaskade immer mit der gleichen IP-Adresse online. Wertung: Der automatische Wechsel in Problemfällen erleichtert den Surfvorgang. Beim AN.ON-Projekt würden sich in Bezug auf die Anonymität, laut Gespräch mit den Entwicklern, keine Vorteile daraus ergeben, wenn sich die benutzte Kaskade zeitlich ändern würde. Jede Kaskade verfügt über genügend Strategien, wie z. B. Padding und Mixing der Nachrichten, um die Nutzer-Identifikation sehr schwer zu machen. Welche Kaskade benutzt wird, spielt keine Rolle, solange sich mindestens 2 Mixe in der Kaskade befinden, wovon die Betreiber unabhängig zueinander agieren. TOR: Nach Prüfung und Recherche[The08a] kann die Aussage getroffen werden, dass TOR alle 10 Minuten seine Circuits ändert. Eine Änderung der wahrgenommen IP-Adresse erfolgt daher im 10 Minuten Takt. Es gibt zwei deklarierte Ausnahmen. Sollte zum einem ein Tunnel unterbrochen werden, z. B. weil ein Knoten wegfällt, wird sofort automatisch ein anderer Tunnel angesteuert. Die zweite Ausnahme sind längere TCP-Streams. Ein solcher Stream wird auch länger als 10 Minuten über denselben Tunnel geleitet. Wertung: Genau wie JAP wechselt auch TOR in Problemfällen den Verbindungsweg. Dies ist als sinnvoll anzusehen, da es die Benutzerfreundlichkeit fördert. Das Ändern der verwendeten Tunnel hat den Zweck, eine Informationsauswertung zu erschweren. Daher ist dieses Vorgehen mit gut zu bewerten. Archicrypt Stealth VPN: Bei der Einwahl in den VPN-Tunnel erhält man eine IP-Adresse vom VPN-Server. Diese IP-Adresse bleibt für die Zeit, in der man online ist, gleich. Die vom VPN-Server erhaltene IP-Adresse wurde über den Zeitraum von mehreren Stunden beobachtet, ohne eine Änderung festzustellen. Lediglich nach einem Disconnect und einer erneuten Verbindung zum VPN-Netzwerk erhält man möglicherweise eine andere IP-Adresse. In der GUI des Programms wird durch ein Schloss symbolisiert, dass dies die verschlüsselte IP-Adresse ist. Wertung: Dies ist ein für VPN standardmäßiges Vorgehen. Es ist kein Algorithmus implementiert, welcher in bestimmten Perioden dem Nutzer eine andere IP- 61

67 Adresse zuweist. Positiv fällt auf, dass es eine Funktion gibt, mit deren Hilfe man die zugewiesene IP-Adresse verifizieren kann. I2P: Hier ist nur die IP-Adresse des Outproxy feststellbar. Die Adresse des Outproxy zum normalen Internet ist statisch, d.h. es ist immer dieselbe Adresse. Im Overlay-Netzwerk selbst werden alle 10 Minuten neue Tunnel aufgebaut. Somit ändern sich auch die an der Kommunikation beteiligten Instanzen. Die Identität dieser Router wird durch Einsatz und Kombination von asymmetrischer Verschlüsselung (2048-Bit ElGamal) und digitaler Signaturverfahren (1024-Bit DSA) geschützt [Kub08] 29. Mit IP-Adressen wird im internen Netz nicht gearbeitet. Von dem Eepproxy bis zur eepsite werden die Daten ohne IP-Adresse transportiert und kommen dort auch ohne IP-Adresse an. Geroutet wird hier durch den Einsatz der Destinations, welche für die IP-Adresse einstehen. Die einzige IP-Adresse, die dort ist, ist die IP-Adresse des lokalen Eepproxy, sprich die Wertung: Bei diesem Ansatz wird die IP-Adresse, das wichtigste Identifizierungsmerkmal im Internet, durch Destinations ersetzt. Bei anderen Anonymisierungsverfahren wird darauf gesetzt, die Adressen anderer Nutzer zu verwenden, um so seine echte Identität zu verbergen. Der Ansatz in I2P ist neuartig und komplexer als bei anderen Verfahren. Es ändern sich hier demnach nicht die IP- Adressen, aber dennoch die an der Kommunikation beteiligten Instanzen. Dies führt zu einer Erschwerung der Informationsauswertung und ist daher positiv anzusehen Messung von Latenzzeit und Bandbreite der Anonymisierungsdienste Nur die wenigsten Anwender eines Anonymisierungsdienstes haben das technische Verständnis, die vom Dienst generierte Anonymität korrekt beurteilen zu können. Aus diesem Grund ist die Geschwindigkeit des Anonymisierungsdienstes ein relevanter Faktor bei der Wahl des Dienstes. Die Geschwindigkeit bezieht sich einmal auf die Latenzzeit (Millisekunden) und einmal auf die Bandbreite (KByte/s). Die Latenzzeit beschreibt die Round-Trip-Time (RTT) im Netz. Eine Webseite mit vielen kleinen Dateien wird sehr langsam geladen, wenn die Latenzzeit hoch ist. Beim Download einer großen Datei hingegen wirkt sich eine hohe Latenzzeit nicht negativ aus, sobald der Download gestartet ist. Die Bandbreite trifft eine Aussage darüber, wie schnell ein Datenpaket über einen Kommunikationskanal transportiert werden kann. Alle hier evaluierten Dienste haben die Gemeinsamkeit, dass es sich jeweils um low-latency Netze handelt. Die Universität Regensburg hat vor zwei Jahren eine Untersuchung zur Zeitmessung[WHF06] 29 Da diese Quelle ein Video ist, ist es auf der CD beiliegend 62

68 in low-latency Netzen veröffentlicht. Das dazugehörige Mess-Programm Perfeval ist im Internet[Her08] zu beziehen. Dies ist bislang der einzige wissenschaftliche Ansatz für die Messung in Anonymisierungsdiensten. Testszenario: Mit Hilfe des Programms Perfeval lassen sich laut [WHF06] zwei Testszenarien ausführen. Die Simulation steuert zuerst verschiedene Webseiten an, welche mehrere kleine Dateien enthalten (WEB-Szenario). Somit wird die Latenzzeit bestimmt. Da der AN.ON-Dienst und Archicrypt im Gegensatz zu TOR und I2P in Bezug auf die Infrastruktur größtenteils lokal in Deutschland vorzufinden sind, gibt es hier einmal einen Test mit deutschen Webseiten (DE) und einmal einen Test mit internationalen Seiten (EN). Somit ist eine gewisse Fairness garantiert. Die Latenzzeit, bzw. die initiale Verzögerungszeit, ist der zeitliche Unterschied zwischen dem Senden eines HTTP-Requests und dem Erhalten des ersten Teils des Responses. Anschließend werden Downloads fester Größe getätigt, um die Bandbreite zu ermitteln (DL-Szenario). Der Durchsatz setzt sich dabei aus der Menge der erhaltenen Bytes dividiert durch die dazu benötigte Zeit zusammen. Im Internet werden Web Caches und Proxies dafür eingesetzt, die Downloadgeschwindigkeit zu erhöhen. Dies würde die Messung verfälschen. Aus diesem Grund wird der HTTP-Header mit dem Attribut Cache Controll : no cache versendet. Zudem muss Privoxy so konfiguriert werden, dass keine Filterungen und Werbeblockierungen vorgenommen werden. Dies würde wieder Messdaten verfälschen. Die Variable toggle der Privoxy-Konfigurationsdatei muss den Wert 0 erhalten. Testanforderungen: Um valide und brauchbare Messergebnisse zu erhalten, müssen bestimmte Einflüsse vermieden bzw. möglich gering gehalten werden: Externe Faktoren: Ausfallzeiten des Netzwerkes HTTP-Errors Fehler in der Perfeval Software selbst gleichzeitiges Testen des Anonymisierers mit mehreren Computern Performanz Schwankungen auf dem PC worauf Perfeval läuft Performanz Schwankungen auf dem Ziel-Rechner Performanz Verfälschungen durch HTTP-Redirects ein Performanz Limit durch eine zu geringe eigene Bandbreite variierende Performanz durchweg den Tag 63

69 Nach der Messung müssen die gewonnen Informationen nach solchen Faktoren untersucht werden. Eine Performanz-Schwankung auf dem Ziel-Rechner würde sich z. B. durch signifikant gefallene Bandbreite äußern. Sollten nicht geringfügige Einflüsse festgestellt werden, sind die gewonnenen Informationen unbrauchbar. Als nicht geringfügig werden Daten eingestuft, deren Verhältnis von kritisch zu gut höher als 5% ist. Im Fehlerfall ist es wichtig, genau zu bestimmen, wo die Quelle des Fehlers liegt. Mögliche Instanzen sind der Webserver, das Netzwerk, der Anonymisierungsdienst oder die Internet-Verbindung. Die Perfeval Software ist dazu in der Lage, Fehler von Ausfällen zu unterscheiden. So ist in [WHF06] die Funktion dieses Algorithmuses erläutert. Der Algorithmus erkennt einen nicht erfolgreichen HTTP-Request nur dann als Fehler, wenn alle folgenden Bedingungen gelten: eine Verbindung zum Webserver kann eingerichtet werden ein HTTP Test-Request kann über das Netzwerk gesendet werden ein sich darauf beziehender HTTP-Response kann erhalten werden der HTTP Status-Code ist nicht 200 OK (oder ähnlich) der HTTP Status-Code ist nicht 502 Service temporarily overloaded, oder 503 Gateway Timeout Gilt nur eine der genannten Bedingungen nicht, deutet dies auf einen Ausfall hin. Auch Timeouts, welche 60 Sekunden überschreiten, sind ein sicheres Anzeichen für Ausfälle. Implementierung der Testumgebung: Um den in Abschnitt Testanforderungen - genannten Testanforderungen gerecht zu werden, wird die Messung am eigenen Internetanschluss durchgeführt. Nur hier kann garantiert werden, dass außer den Mess-PCs kein weiterer Teilnehmer im Netz ist. Das bedeutet, dass die Messungen keinerlei Schwankungen unterliegen, welche durch andere Netzteilnehmer verursacht werden könnten. An das Netzwerk sind zwei gleichwertige Rechner aus dem Netzlabor C015 angeschlossen, da ja für deutsche und internationale URLs gemessen werden muss. Die Verbindung geht über einen Switch per Kabel direkt an den Router. Vorbereiten der Messung: Im Quellcode des Perfeval-Paketes sind Testcases für die Anonymsisierungsnetzwerke TOR und JAP bereits einprogrammiert. Da dort noch Testcases für I2P und das Archicrypt Produkt fehlen, muss dies äquivalent zu den bereits bestehenden Testcases hinzugefügt werden. Dies soll hier in Listing 3 am Beispiel des I2P-Dienstes verdeutlicht werden. Die Datei common.con f im Perfeval-Verzeichnis ist zu erweitern. 64

70 Listing 3: Presub Methode von I2P #presub von i2p sub presub_ i2p { my $entry = s h i f t ; my $ t r y =0; my ( $cmd, $res ) ; while ( $try <3) { $ t r y ++; # k i l l e x i s t i n g i2p c l i e n t s main : : p r i n t S t a t s ( " K i l l i n g already running c l i e n t \ n " ) ; $cmd = $cmd_pskill ; $cmd =~ s /! args! / i2p. exe / i ; main : : p r i n t S t a t s ( " cmd : $cmd \ n " ) i f ( $main : : verbose ==1) ; system ( $cmd) ; # s t a r t new instance of i2p main : : p r i n t S t a t s ( " S t a r t i n g new c l i e n t... " ) ; $cmd = $cmd_i2p ; $cmd =~ s /! args! / $entry >{presub_arg } / i ; main : : p r i n t S t a t s ( " \ n cmd : $cmd " ) i f ( $main : : verbose ==1) ; system ( $cmd) ; i f ( $? == (255 < <8) ) { main : : p r i n t S t a t s ( " \ n!!! E r r o r! Cannot spawn process! " ) i f ( $main : : verbose ==1) ; return 0; } ## w ait some time u n t i l I2P i s ready main : : p r i n t S t a t s ( " Waiting $waittime_i2p seconds... \ n " ) ; sleep ( $waittime_i2p ) ; ## send t e s t request main : : p r i n t S t a t s ( " Testing connection... " ) ; $cmd = $cmd_ perfeval_ test_ proxy ; $cmd =~ s /! proxy! / $entry >{proxy } / i i f ( defined ( $entry >{proxy } ) ) ; # i f successful r e t u r n 1 # otherwise r e t u r n 0 $res = t e s t r e q u e s t ($cmd ) ; i f ( $res ==1) { return 1; } } return 0; }

71 Die Erläuterung des Codes steht hier nicht im Vordergrund. Es geht nur um einen kleinen Teil des kompletten Quellcodes. Deshalb wird hier nur knapp erklärt, wozu das in Listing 3 programmierte Codestück vorhanden ist. In den Zeilen 12 bis 17 wird der laufende I2P-Prozess beendet. Dies ist natürlich erst ab dem zweiten Testcase nötig. In den Zeilen 19 bis 28 wird das I2P-Netzwerk gestartet. Im Fehlerfall wird eine Fehlermeldung generiert. Die Zeilen 32 bis 34 geben hier die Sekunden an, die gewartet werden, bis die Messungen nach dem erfolgreichen Verbinden zum Anonymisierungsdienst starten. Zu beachten ist, dass die Variable waiting (25 Sek.) durch die Variable waiting_i2p (300 Sek.) ersetzt wurde. Da das I2P-Netzwerk konzeptionell eher einem P2P Netzwerk gleicht, benötigt es eine höhere Zeit, um betriebsbereit zu sein. Dies wurde mit der neuen Variablen berücksichtigt. Jetzt muss noch äquivalent zu TOR und JAP eine Postsub Methode hinzugefügt werden. Die Postsub Methode beendet das jeweilige Programm, nachdem die Messung erfolgreich verlief. Listing 4: Postsub Methode von I2P # postsub von I2P sub postsub_ i2p { # k i l l a l l e x i s t i n g i2p c l i e n t s main : : p r i n t S t a t s ( " K i l l i n g I2P c l i e n t. \ n " ) ; my $cmd ; $cmd = $cmd_pskill ; $cmd =~ s /! args! / i2p. exe / i ; main : : p r i n t S t a t s ( " cmd : $cmd \ n " ) i f ( $main : : verbose ==1) ; system ( $cmd) ; } return 1; Nachdem diese zwei Methoden erfolgreich hinzugefügt wurden, muss noch der jeweilige Testcase im Quellcode aufgerufen werden. Dies geschieht im Falle von I2P folgendermaßen: Listing 5: Push Methode von I2P $ t e s t ={ name => $conf : : name_prefix. i2p, u r l s f i l e => $conf : : u r l s f i l e, params => prevent caching =1, proxy => h t t p : / / l o c a l h o s t :4444, presub => \& presub_i2p, presub_arg =>, postsub => \& postsub_ i2p, 66

72 } ; $ t e s t ; Die Push-Methode enthält die für die Ausführung notwendigen Parameter. Hier wird z. B. der Port angegeben, auf dem der I2P-Proxy läuft, das Cachen wird ausgeschaltet, und die vorher definierten Pre- und Postsub Methoden werden übergeben. Damit wäre die Editierung der Datei common.con f vorerst beendet. Jetzt müssen im Unterverzeichnis hel pers noch die entsprechenden Stapelverarbeitungsdateien für den jeweiligen Dienst generiert werden. Die erste Stapelverarbeitungsdatei setzt den Proxy für den Anonymisierungsdienst als Umgebungsvariable im Betriebssystem fest (siehe Listing 6). Listing 6: Proxy als Umgebungsvariable definieren (I2P) set http_proxy= h t t p : / / l o c a l h o s t :4444/ Die zweite bat-datei (runi2p.bat) enthält den Pfad des Dienstes und startet ihn o f f Listing 7: runi2p.bat echo Running I2P %1... G: cd "G : \ Programme \ i2p " s t a r t i2p. exe Damit dieser Dienst dann auch aufgerufen wird, ist noch ein Eintrag der jeweiligen Stapelverarbeitungsdatei in der Datei common.con f nötig (siehe Listing 8). Listing 8: Hinzufügen eines Dienstes # command used to s t a r t JAP c l i e n t our $cmd_jap = helpers \ \ runjap. bat! args! ; # command used to s t a r t TOR c l i e n t our $cmd_tor = helpers \ \ r u n t o r. bat! args! ; # command used to s t a r t I2P c l i e n t our $cmd_i2p = helpers \ \ runi2p. bat! args! ; # command used to s t a r t ARCHICRYPT c l i e n t our $cmd_archicrypt = helpers \ \ r u n a r c h i c r y p t. bat! args! ; Mit diesen Schritten ist nun ein völlig neuer Dienst ins Perfeval-Messprogramm implementiert. Perfeval ist völlig unabhängig von der zu Grunde liegenden Anonymisierungstechnik, da es lediglich einen Browser simuliert, der Webseiten 67

73 nacheinander abruft. Solange der zu untersuchende Dienst als HTTP-Proxy-Server fungiert, kann man Perfeval dazu nutzen. Probleme vor dem Messvorgang: Beim Start von I2P unter Windows öffnet sich automatisch der Standardbrowser, um die Router Console anzuzeigen. Für die Messung würde das bedeuten, dass sich ein neuer Tab im Browser öffnet, wenn der I2P-Dienst aufgerufen wird. Dies ist im Rahmen der Messung eher störend, bzw. nicht notwendig. Dementsprechend ist im I2P-Installationsverzeichnis in der Datei clients.con f ig der entsprechende Eintrag auszukommentieren. Nun startet lediglich der I2P-Dienst ohne automatisches Öffnen des Browsers. Auch das Archicrypt Programm warf mehrere Probleme auf. Um die Verbindung ins Anonymisierungsnetzwerk zu starten, muss nach Programmstart mit der Maus der Button Verbinden getätigt werden. Eine automatische Verbindung nach Programmstart ist nicht konfigurierbar. Somit wird lediglich das Starten der Archicrypt Software durch das Perfeval-Skript vorgenommen, aber nicht das notwendige Verbinden. Dementsprechend muss eine automatisierte Lösung für das Betätigen des Verbinden Buttons erstellt werden. Für diese Makrogenerierung eignet sich unter Windows die Software AutoIt 30. Mittels Skriptsprache können hier immer wieder kehrende Aufgaben automatisiert werden. Listing 9 zeigt das Skript, welches die Archicrypt Software automatisiert. Listing 9: Automatisierung mit AutoIt ; S c r i p t S t a r t Add your code below here Run ( " VPNClient. exe " ) WinWait ( " ArchiCrypt S t e a l t h VPN", " panel " ) C o n t r o l C l i c k ( " ArchiCrypt S t e a l t h VPN", " panel ", " Button1 " ) Der Run-Befehl nimmt als Argument die auszuführende Anwendung an und startet diese. Mit dem WinWait-Befehl wird sichergestellt, dass vor Zugriffen auf die GUI solange gewartet wird, bis die GUI vollständig geladen ist. Der ControlClick- Befehl nimmt als Argument das aktuelle Fenster und den zu betätigenden Button entgegen. Durch den Befehl wird der angegebene Button aktiviert. Nachdem dieses Skript fehlerfrei kompiliert wurde, steht eine ausführbare Datei zur Verfügung. Da das Archicrypt-Produkt genau wie auch I2P länger als 25 Sekunden für die erfolgreiche Verbindung ins Anonymisierungsnetz benötigt, wird hier extra die Variable waiting_archicrypt mit dem Wert von 75 Sekunden deklariert. Je nach Auslastung der Server kann die Verbindung eine knappe Minute dauern. Um sicher zu gehen, dass die Verbindung vollständig aufgebaut ist, wurde hier ein Puffer dazugegeben. Zuletzt war die Tatsache zu beachten, dass das Archicrypt-VPN-Produkt

74 nicht über bestimmte Ports kommuniziert, sondern direkt über die OpenVPN- Verbindung. Demnach waren im Quellcode der Datei common.con f die Zeilen für die Proxy-Abfrage auszukommentieren. Betroffen sind die Zeilen 542, 543, 547 und 548. Auch im Testcase zu Archicrypt war die Zeile, welche die Proxyangaben entgegen nimmt, auszukommentieren. Im Testszenario-Abschnitt wurde bereits darauf hingewiesen, dass hier deutsche Seiten (DE) und internationale Seiten (EN) getestet werden. Jeder Test findet auf einem eigens dafür vorgesehenen Rechner statt. Selbstverständlich handelt es sich dabei um baugleiche Maschinen, siehe Kapitel 10 Tabelle 9. Damit keine Interferenzen entstehen, müssen diese beiden Testläufe zeitlich getrennt voneinander laufen. Dazu ist zunächst zu ermitteln, wie lange ein Testlauf dauert. Nach ersten Beobachtungen kann gesagt werden, dass ein Testlauf ungefähr zwischen 40 und 80 Minuten dauert. Leider sind diese Werte hier sehr unkonstant. Dementsprechend werden hier als Puffer noch 10 Minuten dazu addiert, um gewissen Schwankungen und Timeouts vorzubeugen. Die Länge eines Testlaufs (Cycle) ist in der Datei common.con f zu editieren. In diesem Fall wurde die Länge eines Cycles dargestellt durch die Variable cycle_intervall, auf 180 Minuten editiert. Damit soll folgendes erreicht werden: Testrechner 2 startet mit der Messung der englischen Seiten genau 90 Minuten, nachdem Testrechner 1 die Messung der deutschen Seiten begann. Zu dem Zeitpunkt, an dem Testrechner 2 mit der Messung beginnt, sollte Testrechner 1 planmäßig mit seiner ersten Messung fertig sein. Testrechner 1 wartet dann nach seiner ersten Messung noch die verbleibende Zeit, bis die 180 Minuten voll sind, da dies ja die Zeit ist, in der Testrechner 2 arbeitet. Zudem wurde die Variablen maxruntime auf 0 editiert. Der Wert 0 sagt aus, dass ein Testrechner seine Messung bis zum Ende durchführt, auch wenn die dafür vorgesehene Zeit überschritten wird. Demnach kann es zu Überschneidungen kommen. Eine Editierung dieser Variable mit dem Wert 1 würde dazu führen, dass die Messung angehalten wird, sobald die dafür vorgesehene Zeit abgelaufen ist. Dabei spielt es keine Rolle, wie weit die Messung vorangeschritten war. Die Messung startet mit dem Testen der Direktverbindung. Die Direktverbindung dient als Indikator für Latenzzeit und Bandbreite im Vergleich zu den Anonymisierungsdiensten. Die Messungen laufen in folgender Reihenfolge ab: Test der Direktverbindung Test der JAP-Dresden-Mixkaskade Test von TOR Test der Archicrpyt OpenVPN Verbindung Test von I2P über den Outproxy false.i2p 69

75 Die Dresden-Mixkaskade wurde hier extra wegen der hohen Stabilität ausgewählt. Starten der Messung: Nachdem alle zu testenden Verfahren in den Quellcode aufgenommen sind, kann die Messung gestartet werden. Als Voraussetzung werden zwei Windows-XP SP2 Rechner mit installiertem Active Perl genannt. Selbstverständlich müssen auf jedem System auch die Anonymisierungsprodukte installiert sein (siehe dazu Kapitel 12.3 bis 12.6). Die Bedienung des Programms erfolgt über die MS-DOS-Eingabeaufforderung. Zuerst wechselt man in den Perfeval Ordner. Danach ist im Unterordner hel pers die runcmd.bat auszuführen. Dies bewirkt nun eine Vergrößerung der MS-DOS-Eingabeaufforderung auf eine angepasste Größe, um eine bessere Übersicht zu erhalten. Danach wird auf Rechner 1 der Test für deutsche URLs gestartet und auf Rechner 2 der Test für englische URLs (siehe Listing 10). Listing 10: Starten der Messung p e r l c o n t r o l l e r. p l conf=de. conf l o g f i l e =log de. t x t # bzw. p e r l c o n t r o l l e r. p l conf=en. conf l o g f i l e =log en. t x t Die Startzeiten der jeweiligen Messungen werden in den Dateien en.con f und de.con f editiert. Die Startzeit für das DE-Szenario war Sonntag, der 24. August, 18 Uhr. Die Startzeit für das EN-Szenario war Sonntag, der 24. August, Uhr. Interpretation der Messergebnisse: Jeder Testdurchlauf ermittelt kumulierte Messdaten. In der Log-Datei ist die Zeile mit den kumulierten Messdaten daran zu erkennen, dass sie mit zwei ** beginnt. Ein typisches Messergebnis zeigt Listing 11. Listing 11: Typisches akkumuliertes Messergebnis Das Ergebnis sind 17 Werte, welche folgendermaßen zu interpretieren sind: 1. Startup Timestamp (Millisek.) 2. Anzahl der Requests 3. Anzahl der erfolgreich durchgeführten Requests 4. Anzahl der Requests mit mind. einem Server-Fehler 5. Anzahl der Requests mit mind. einem Service / Netzwerk Ausfall 6. HTTP GET Requests zum Netzwerk gesendet 70

76 7. Anzahl erfolgreicher HTTP GET Requests 8. Anzahl von HTTP GET Requests welche in Server-Fehler Fehler enden 9. Anzahl von HTTP GET Requests welche aus Service / Netzwerk Ausfall resultieren 10. akkumulierte Menge des Daten-Downloads in Bytes (insg. für alle URLs) 11. Zeit, die dazu benötigt wurde (Millisek.) 12. Durchsatz: (Wert aus 10 / Wert aus 11) * (1000/1024) in KByte/s 13. durchschnittliche initiale Verzögerung von allen erfolgreichen Requests (Millisek.) 14. akkumulierte Verzögerung resultierend durch Ausfälle (Millisek.) 15. akkumulierter Durchsatz von Datei-Downloads, inklusive Ausfällen (Bytes) 16. Zeit, die dafür gebraucht wurde (Millisek.) 17. Durchsatz: (Wert aus 15 / Wert aus 16) * (1000/1024) in KByte/s Errechnet wird hier das arithmetische Mittel aller initialen Verzögerungen. Der Durchsatz errechnet sich durch die Addition der heruntergeladenen Bytes, dividiert durch die dazu benötige Zeit. Im Anhang werden aus Platzgründen nur die aus den Log-Dateien extrahierten akkumulierten Messdaten zu sehen sein. Die kompletten Log-Dateien können auf der beiliegenden CD im Verzeichnis Messverfahren(Perfeval)/Logs eingesehen werden. Auswertung der Messergebnisse: Zunächst muss geprüft werden, ob es bei den Messungen von DE und EN zu Überschneidungen gekommen ist. Dazu werden die jeweiligen Start- und Endzeiten aller Testläufe miteinander verglichen. Es kann die Aussage getroffen werden, dass es in 4,29% zu Überschneidungen kam. Der kritische Wert liegt hier bei 5%. Dementsprechend kann der hier entstandene Einfluss laut [WHF06] noch als geringfügig eingestuft werden. Zwei kurze Überschneidungen, welche nur eine Länge von 1 Minute, bzw. 2 Minuten aufwiesen, wurden aufgrund ihrer minimalen Länge außen vorgelassen. Da sich die Überschneidungen höchstens auf die Messung der Direktverbindung auswirken konnten. Ebenso muss beachtet werden, dass nur zwei der Überschneidungen eine erwähnenswerte Länge 31 aufwiesen. Als Grund für eine solch unkonstante Verlangsamung ist der Outproxy des I2P-Netzes anzusehen. Dies geht aus den 31 19:33 Minuten u. 29:41 Minuten 71

77 Log-Dateien 32 hervor. Ziel muss es sein, in der Zeit, in der gemessen wird, möglichst viele Messergebnisse zu ermitteln, um so ein immer genaueres Ergebnis zu erhalten. Es fällt auf, dass die Zeit für einen Testlauf, mit Ausnahme der Überschreitungen, meist weit unterschritten wurde. Es kam teilweise zu Stillständen von einer Stunde, bis der andere Rechner dann mit dem nächsten Testlauf begann. Das ist natürlich so nicht gewünscht. Da der Outproxy des I2P-Netzes aber nicht zwingend in einem konstanten Rahmen arbeitet, ist es schon fast nicht möglich, vorher eine eventuelle Dauer eines Testlaufs zu approximieren. Für zukünftige Anwendungen empfiehlt sich daher die Verwendung eines verteilten Algorithmus, der die Start- und Endzeiten einer Messung überwacht, um so automatisch die maximale Menge an Testläufen zu erzielen. Im Rahmen dieser Messung wurden 700 Testcases ausgeführt. Somit kommt man auf 140 Testcases für jede Verbindungsart. Das unterteilt sich in 70 Testcases für DE und 70 Testcases für EN. Bei den Messungen zu DE kam es lediglich bei I2P und Archicrypt in seltenen Fällen zu einem Komplettausfall des jeweiligen Testcases. Beim I2P-Netz konnte ein Testlauf zweimal nicht gestartet werden, 33 da der Outproxy nicht erreichbar war. Bei der Archicrypt Software gab es bei den Messungen für DE einen ausfallenden Testlauf 34. Ursache dafür ist laut Log-Datei, dass das Netzwerk nicht erreichbar ist. Da der Zeitpunkt des ersten Ausfalls vom I2P-Netz und der des Ausfalls der VPN-Verbindung nur 1 Minute auseinanderliegen, ist dies wahrscheinlich auf einen externen Faktor zurückzuführen. Eventuell fand genau zu diesem Zeitpunkt der 24 Stunden Disconnect des Providers statt. Dies wäre nur durch die Anmietung einer Standleitung auszuschließen. Ganz ohne Ausfall oder vorzeitigem Abbruch eines Testlaufs liefen die Messungen der Direktverbindung und die Messungen zu JAP ab. Zu einem vorzeitigen Abbruch eines Testcases kam es beim TOR-Netzwerk und bei der VPN-Verbindung. Dies ist aber eine vernachlässigbar kleine Zahl und zeigt, wie stabil diese Dienste laufen. Kritische Werte ergab wieder der I2P-Dienst, wo ein Testlauf 7 mal mit der Fehlermeldung Proxy is Dead vorzeitig abgebrochen werden musste. Etwas erfolgreicher liefen die Messungen für den internationen Bereich (EN) ab. Die Messungen zur Direktverbindung, JAP und TOR liefen alle komplett und ohne Komplikationen ab. Diese Daten könnten also zur Analyse herangezogen werden. Probleme gab es wieder beim I2P-Netz. Zwei Testläufe konnten nicht gestartet werden, da der Outproxy für das normale Internet zu diesem Zeitpunkt nicht erreichbar war. Zudem brachen drei stattgefundene Testläufe mit der Fehlermeldung Proxy is dead ab. Somit brachen 4,41% der stattgefundenen Testläufe ab. 32 auf CD im Verzeichnis Messverfahren/Perfeval/Log enthalten 33 Mon Sep 01 08:08:20 und Tue Sep 02 08:12:46 34 Mon Sep 01 08:07:46 72

78 Nochmals sei hier darauf hingewiesen, dass sich das I2P-Netzwerk nicht auf die Anonymisierung des normalen Internets spezialisiert, sondern intern arbeitet. Bei der Archicrypt VPN-Verbindung gab es lediglich einen vorzeitigen Abbruch des Testlaufes 35 mit der Fehlermeldung Network seems to be down. Tabelle 13 zeigt das arithmetische Mittel aller initialen Verzögerungen aller erfolgreichen Requests (Wert 13). Die Ergebnisse bestätigen die Erwartungen. Während die in Deutschland ansässigen Dienste JAP und Archicrypt bessere Latenzzeiten im deutschen Testszenario (DE) erzielen, sind die globalen Netzwerke TOR und I2P im internationalen Testszenario (EN) schneller, als im deutschen Testszenario. Die Direktverbindung arbeitet im internationalen Bereich geringfügig schneller. SZENARIO DE EN Direct 490,93 msec 464,47 msec JAP 901,76 msec 958,63 msec TOR 5452,87 msec 4883,21 msec Archicrypt VPN 1082,74 msec 1409,65 msec I2P 10805,02 msec 10333,26 msec Tabelle 13: Arithmet. Mittelwert für die gemessenen Latenzzeiten (Millisek.) In Tabelle 14 sind die Bandbreiten der beiden Testszenarien dargestellt. Hier ist genau wie in Tabelle 14 der arithmetische Mittelwert aus den kumulierten Ergebnissen in den Log-Dateien berechnet worden. Dabei ist die Bandbreite für das DE-Szenario deutlich höher, teilweise doppelt so hoch wie die Bandbreite für das EN-Szenario. Das JAP-Netzwerk hat sich in Bezug auf Bandbreite in beiden Testszenarien als der beste Dienst herausgestellt. SZENARIO DE EN Direct 71,805 kb/s 36,589 kb/s JAP 42,112 kb/s 28,073 kb/s TOR 15,774 kb/s 7,415 kb/s Archicrypt VPN 37,129 kb/s 18,345 kb/s I2P 3,186 kb/s 2,420 kb/s Tabelle 14: Arithmet. Mittelwert für die gemessenen Bandbreiten (Kilobyte/s) Eine umfassende mathematische bzw. statistische Analyse wie in [WHF06] kann hier schon aus Zeitgründen im Rahmen dieser Bachelorarbeit nicht durchgeführt werden. Ebenso muss gesagt werden, dass 700 Testläufe bei der Messung 35 Mon Sep 01 21:45:40 73

79 eventuell für eine sehr genaue Erhebung zu wenig sein könnten. Es war allerdings nicht möglich, einen Internet-Anschluss länger als die hier angegebene Zeit nur für die Messung zur exklusiven Nutzung zu erhalten. Was aber anhand dieser Messergebnisse durchaus möglich ist, ist ein Vergleich der vier Anonymisierungsdienste in Bezug auf Bandbreite und Latenzzeit. Dies ist im Hinblick auf die Evaluation wichtig. Für zukünftige Messungen wären hier allerdings bessere Bedingungen und eine längere Messzeit ratsam. Die kumulierten Messergebnisse sind im Anhang (Kapitel 12.7) einzusehen Verkehrsdaten-Protokollierung Hierbei soll geprüft werden, ob es während des laufenden Betriebes im Anonymisierungsnetzwerk zu Protokollierungs-Aktivitäten kommt. Es soll geklärt werden, ob beispielsweise eine generelle Nutzer-Identifizierung möglich ist. JAP: Da das AN.ON-Projekt quelloffen ist, wäre es ein möglicher Ansatz, den Code nach verdächtigen Stellen zu untersuchen. Da der Code mehr als Zeilen umfasst, wäre dies ein sehr zeitaufwändiges Vorhaben. Zudem besitzt nicht jeder die notwendigen Programmierkenntnisse, um die dort zur Verfügung stehenden Informationen auszuwerten. Der allgemeine Tenor sagt aber aus, dass hier keine Protokollierungs-Mechanismen stattfinden. Ausnahmen wurden bisher von den Entwicklern explizit deklariert, wie z. B. die Zusammenarbeit mit Strafverfolgungsbehörden[KM08]. Die TU-Dresden bezieht sich im Internet detailliert auf diese Fragestellung. Es wird erläutert, dass höchstens eine zukünftige zielgerichtete Überwachung realisierbar ist. Dies ist durch die sogenannte Crime Detection Function möglich. Hierbei ist die Mitarbeit aller Mixe in der Kaskade notwendig. Der zu deanonymisierenden Verbindung wird dabei eine eindeutige Markierung zugeordnet. Eine rückwirkende Auswertung der Verkehrsdaten ist fast unmöglich. Für eine rückwirkende Aufdeckung müssen die aufgezeichneten Daten aller Mixe dem betreffenden Mix vorgelegt werden, damit dieser die Daten deanonymisieren kann. Dies funktioniert allerdings nur solange, wie das entsprechende Schlüsselpaar im Mix noch Gültigkeit besitzt, bzw. solange der Zugriff auf den Schlüssel möglich ist. Ist das nicht mehr der Fall, ist eine rückwirkende Aufdeckung unmöglich [20008]. Weitere Auskünfte gibt die Betriebsvereinbarung 36. Sie richtet sich an die Betreiber von Mix-Server und dient dem Schutz der Nutzers, in Bezug auf die angestrebte Anonymität. Besonders Paragraph 4, in dem es um die Weiterleitung und Speicherung von Daten geht, sticht hervor. In Unterpunkt 3 heißt es zwar, dass ein Mixbetreiber Verkehrsdaten aufzeichnen darf, diese aber nicht zur Nutzeridentifikation brauchbar sein dürfen. Dies darf lediglich zur sta- 36 https://www.jondos.de/de/operationalagreement 74

80 tistischen Datenerhebung erfolgen, und auch nur nach schriftlicher Genehmigung der JonDos-GmbH. Ebenfalls zu erwähnen ist Paragraph 5, Einsatz und Verwendung der Mixsoftware. Dort ist sichergestellt dass nur die von JonDos entwickelte Mixsoftware genutzt werden darf. Eine Änderung am Quellcode sei unzulässig. Um diesem Fall vorzubeugen, ist die JonDos-GmbH zur regelmäßigen Kontrolle verpflichtet. Jeder Mixbetreiber muss vor der Aufnahme des Betriebes eine Selbstverpflichtung unterzeichnen. Wichtiger Bestandteil dieser Verpflichtung 37 ist die Untersagung, Log-Dateien zu generieren. Wertung: Die Hersteller schenken diesem Thema eine hohe Beachtung. In zahlreichen Dokumenten wird versichert, dass keine Datenprotokollierung stattfindet. Begründet wird dies durch technische und juristische Belange. Zu bedenken ist, dass alle Aussagen und Dokumente bezüglich der Datenprotokollierung direkt vom Hersteller selbst und nicht von dritten unabhängigen Personen stammen. Das liegt daran, dass lediglich die Entwickler öffentlich zu diesem Thema Stellung nahmen. Wer ganz sicher gehen will, muss den Quellcode untersuchen. Diese umfangreichen Maßnahmen zur Sicherstellung der Anonymität werden mit gut bewertet. TOR: Eine nachträgliche Identifizierung von TOR-Nutzern ist laut den Entwicklern [Lub08] nicht möglich. Technisch kann dies mithilfe der Perfect Forward Secrecy[DMS08] verdeutlicht werden. Die Perfect Forward Secrecy kommt z. B. bei den Verbindungen der Onion-Router untereinander zum Tragen. Wie in Kapitel 7.4 schon erklärt, werden bei TOR sogenannte Session-Keys verwendet. Dies sind kurzlebige Schlüssel. Die Perfect Forward Secrecy beruht nun auf der Tatsache, dass bei einer neuen Verbindung auch ein neuer Session-Key erzeugt und genutzt wird. Der alte Key wird demnach verworfen. Ist der alte Key vernichtet, kann auch der dazugehörige Verkehr nicht mehr entschlüsselt werden. Die Maßnahme der Perfect Forward Secrecy findet sich heute in vielen Verschlüsselungsverfahren wieder, da sie sich bewährt hat. Wertung: Auch hier gibt es lediglich Aussagen der Entwickler zur nachträglichen Identifizierung. Dies muss immer kritisch bedacht werden. Bis jetzt gab es im TOR-Netzwerk im Gegensatz zum AN.ON-Projekt noch keine Protokollierungsmaßnahmen. Archicrypt Stealth VPN: Ab Dezember 2008 findet bei der Firma Archicrypt die Vorratsdatenspeicherung statt 38. Allerdings muss eine Vorratsdatenspeicherung im Internet erst ab dem verwirklicht sein. Die Herausgabe von sensiblen Daten erfolgt hier nach Korrespondenz mit Entwicklern nur nach rich Information direkt vom Unternehmen 75

81 terlicher Anordnung. Theoretisch möglich wäre folgendes Szenario: Der Betreiber von den Archicrypt Servern könnte jede IP-Adresse, welche einen Tunnel aufbaut, mit einer ID versehen. Somit wäre ein eindeutige Zuordnung IP-Adresse zu ID möglich. Zudem könnten im Hintergrund Skripte laufen, welche den Surfvorgang des Archicrypt Kunden protokollieren. Das wäre z. B. in Zusammenarbeit mit Strafverfolgungsbehörden denkbar. Eine Identifizierung im laufenden Betrieb und eine nachträgliche Identifizierung durch Protokolldateien wäre somit theoretisch und praktisch problemlos möglich. Wertung: Da hier nur eine Instanz, also der VPN-Server für die Anonymisierung zuständig ist, müssten nicht wie bei JAP oder TOR mehrere Instanzen zur Deanonymisierung zusammenarbeiten. Somit muss man dem Betreiber ein hohes Maß an Vertrauen entgegen bringen. Man kann hier von einer Verlagerung des Vertrauens sprechen. Anstatt seinem ISP zu vertrauen, muss man nun dem Anonymisierungsunternehmen vertrauen. Daher wird dieser Sachverhalt als negativ angesehen. I2P: Ein mögliches Szenario wäre, über seinen eigenen Router Verkehr für andere Teilnehmer zu lenken, wie es ja in den Standard-Einstellungen gewünscht ist. Diese Informationen könnte man selbstverständlich aufzeichnen. Ebenso selbstverständlich ist, dass diese Verkehrsdaten verschlüsselt sind. Eine solche Verschlüsselung in akzeptabler Zeit zu brechen, ist mit heutiger Technik nicht möglich. Zudem muss beachtet werden, dass die Verkehrsdaten durch Tunnel geleitet werden. Diese Tunnel bauen sich alle 10 Minuten neu auf. Dementsprechend ist es nicht länger als 10 Minuten möglich, zusammenhängende Informationen aufzuzeichnen. Wertung: Hier wird ein ähnlicher Ansatz verfolgt wie im TOR-Netzwerk. Selbst wenn es einem Angreifer durch Brechen der Verschlüsselung gelingen würde, die aufgezeichneten Informationen auszuwerten, besitzt der Angreifer nur einen Teil der Nachrichten. Um an dieser Stelle weiter anzusetzen, müsste der Angreifer direkt wissen, über welchen Tunnel nach Ablauf der Time-to-Live (TTL) eines Tunnels weitergeleitet wird. Bis jetzt gibt es keine Lösung für dieses Vorhaben. Dementsprechend kann diese Implementierung als robust bewertet werden Preis- / Leistungsverhältnis Kommerzielle Aspekte bestehen nur partiell bei JAP und dem Produkt der Steganos GmbH. Es soll aufgezeigt werden, ob sich überhaupt der Kauf eines Produktes lohnt oder die freien Varianten genügen. Falls sich der Kauf lohnt, für welche Art von Nutzer wäre dies ratsam? JAP: Der Preis setzt sich hier lediglich aus der Nutzung der Kaskaden zusam- 76

82 men. Die dafür notwendige Client-Software ist kostenlos. Die JonDos GmbH bietet kostenpflichtige Kaskaden an. Die freien Kaskaden werden z. B. von der TU-Dresden und dem Computer Chaos Club angeboten. Der Vorteil der kostenpflichtigen Kaskaden liegt in einer garantierten Verfügbarkeit und höherer Geschwindigkeit. Zudem sind diese Kaskaden meist über mehrere Länder verteilt, was die Auswertung von Verkehrsdaten durch Behörden erschweren könnte. Wer an einem kostenpflichtigen Service interessiert ist, hat die Möglichkeit, den für sich passenden Tarif auszusuchen. Es gibt Tarife für Viel-Surfer und Tarife für Personen, welche selten im Internet sind. Jeder Tarif ist begrenzt in maximale Laufzeit und maximales Volumen. Ist eins dieser beiden Attribute aufgebraucht, läuft der Tarif aus. Wertung: Positiv zu erwähnen ist die Möglichkeit der anonymen Bezahlung [Wen07], da dies sehr wohl im Interesse der Kunden ist. Mit diesem Angebot ermöglicht die JonDos GmbH die Verwirklichung des 13 Abs. 6 des TMG. Die Einstufung in verschiedene Tarife, je nach Surfverhalten, und die anonyme Bezahlung sind als sehr positiv anzusehen. Die angegebenen Preise 39 lassen sich durch die erhaltene Leistung rechtfertigen. Archicrypt Stealth VPN: Mit dem Kauf des Produktes erhält man eine Lizenz, welche zum anonymen Surfen berechtigt. Auch hier gibt es je nach Surfverhalten verschiedene Tarife. Jeder Tarif, bis auf den Try-Tarif, hat eine Laufzeit von einem Jahr, wobei es eine monatliche Volumen-Beschränkung gibt. Die Wahl eines Tarifes mit hohem Volumen ist im Verhältnis gesehen billiger als ein Tarif mit kleinem Monatsvolumen. Wertung: Die Bezahlung erfolgt hier nicht anonym. Positiv sind aber die verschiedenen Tarife, welche jedem Nutzer zur Wahl stehen. Die Preise 40 befinden sich in einem moderaten Rahmen. Auffallend ist, dass sich die Tarife jeweils durch ein größeres Volumen bzw. durch eine höhere Laufzeit als die der Jondos GmbH darstellen. 39 siehe Tabelle siehe Tabelle 16 TARIF PREIS MAX. LAUFZEIT MAX. VOLUMEN Tiny 1 2 Monate 120 MB Medium 5 3 Monate 700 MB Large 10 3 Monate 1,5 GB XXL 30 7 Monate 5 GB Huge 50 1 Jahr 10 GB Tabelle 15: Preistabelle JAP 77

83 TARIF PREIS LAUFZEIT MAX. VOLUMEN VPN Light 39,95 1 Jahr 1 GB pro Monat VPN ,95 1 Jahr 25 GB pro Monat Megapack VPN 149,95 1 Jahr 25 GB pro Monat VPN (Try) 5 7 Tage 50 MB VPN (25) 11,95 1 Monat 25 GB VPN (1000) 199,95 1 Jahr 85 GB pro Monat Tabelle 16: Preistabelle Archicrypt Stealth VPN 41 In Bezug auf JAP kann gesagt werden, dass die kommerzielle Nutzung der Kaskaden nicht immer zwingend nötig ist. Die freien Kaskaden bieten eine akzeptable Verfügbarkeit und Geschwindigkeit. Wer allerdings eine garantierte Verfügbarkeit und eine hohe konstante Geschwindigkeit benötigt, kommt an den kommerziellen Kaskaden nicht vorbei. Denkbar wäre dies z. B. für Geschäftskunden. Die Nutzung kostenpflichtiger Mix-Kaskaden empfiehlt sich in dem Moment, in dem eine hundertprozentig richtige Funktion des Dienstes unausweichlich ist. Natürlich empfiehlt es sich auch für jeden Privatanwender, der Wert auf hohen Komfort legt. Die gleiche Empfehlung gilt selbstverständlich für das Archicrypt- Produkt. Ebenfalls für das Archicrypt-Produkt spricht die Tatsache, dass es das einfachste und unkomplizierteste Produkt ist. Es empfiehlt sich für Personen, welche keinen Wert auf vielfältige Konfigurationen legen und eine einfach anzuwendende Lösung wollen. Eventuell wäre noch über ein spezielles Flatrate-Angebot für Vielsurfer nachzudenken, da dies bis jetzt von keiner Firma verwirklicht wurde. 41 Anmerkung: Im Archicrypt Megapack VPN sind neben der eigentlichen Dienstleistung noch weitere Software-Produkte wie ArchiCrypt Live, ArchiCrypt Live Browse, ArchiCrypt Safe, ArchiCrypt Shredder, ArchiCrypt Pro, ArchiCryptX Change (Standard), ArchiCrypt Stega, Archi- Crypt NoSpam, ArchiCrypt Stealth VPN (300) und ArchiCrypt System Doctor enthalten. 78

84 11 Zusammenfassung und Ausblick Im Rahmen dieser Arbeit wurde zuerst auf die Funktionsweise der einzelnen Verfahren eingegangen. Danach wurde, darauf aufbauend, eine Evaluierung der einzelnen Verfahren bzw. Produkte nach verschiedenen Gesichtspunkten gestaltet. Einen generellen Testsieger auf diese Weise zu ermitteln, ist schwierig, da hier kein Scoring angewandt wurde, woraus sich direkt ablesen lässt, welches Verfahren die meisten Punkte erhielt. Trotzdem soll hier aus den Bewertungskommentaren resumiert werden, welches Verfahren zu empfehlen ist. Im Rahmen der Evaluation erhielt das TOR-Verfahren die meisten positiven Bewertungen. Demnach sollte das TOR-Verfahren den Vorzug erhalten. Im Einzelfall kann aber auch anders entschieden werden. Die Frage, welcher Anonymisierungsdienst zu verwenden sei, sollte zumindest teilweise vom beabsichtigten Verwendungszweck abhängig gemacht werden. Von vornherein auszuschließen ist nur ein Anonymisierungsdienst. Die VPN-Lösung der Steganos GmbH in Kooperation mit der Softwareentwicklung Patric Remus ist aus zwei Gründen nicht anonymisierend. Bei diesem Verfahren dient nur eine Instanz zur Anonymisierung, der VPN-Server, so wurde es in Kapitel 10.3 erläutert. Da dies nur eine Instanz ist, kann der Betreiber den kompletten darüber stattfindenden Verkehr überwachen. Eine Zuordnung von Verkehrsdaten zu den echten IP-Adressen der Nutzer ist daher möglich. Dies entspricht der Situation, welche auch bei dem eigenen Internet-Service-Provider vorliegt 42. Hier ist die Rede von Vertrauensverlagerung. Dies gilt für jeden Anonymisierungsdienst, der auf VPN-Basis arbeitet. Der zweite Grund, weshalb diese Anonymisierungslösung unzulänglich ist, besteht darin, dass die genutzten VPN-Server alle in Deutschland stehen. Im Falle der anstehenden Vorratsdatenspeicherung werden demnach die Verkehrsdaten erfasst und auf Verlangen an Behörden weitergereicht. Diesbezüglich ist selbstverständlich auch der JAP-Dienst zu erwähnen, der unter der gleichen Gesetzeslage steht. Positiv fällt hier hingegen aber auf, dass hier 3 Instanzen zur Nutzerdeanonymisierung zusammenarbeiten müssen. Dadurch ist eine höhere Anonymität gewährleistet. Trotzdem muss im Hinblick auf zukünftige gesetzliche Rahmenbedingungen eine Internationalisierung des JAP-Dienstes erfolgen. Lediglich TOR und I2P sind aus den in Kapitel genannten Gründen als geeignet anzusehen. Ein weiterer relevanter Auswahlparameter ist die Flexibilität des Dienstes. Hier wird die Frage danach gestellt, welche Protokolle mit dem Anonymisierungsdienst verwendbar sind. Wer lediglich anonym surfen will, hat die freie Wahl zwi- 42 solange man nicht den Verkehr vor seinem ISP durch den Einsatz von Anonymisierungsdiensten vorbei leitet 79

85 schen allen Produkten, da dies die Grundfunktion eines jeden hier aufgezeigten Produktes ist. Die Anonymisierung weiterer Internetprotokolle wird zwar unter anderem von der Archicrypt-Software bewerkstelligt, diese ist aber aus oben genannten Gründen nicht zu empfehlen. Demnach ist hier der TOR-Dienst zu empfehlen, der mit einer Vielzahl der Internetprotokolle arbeiten kann. I2P und JAP können nur partiell zu dieser Aufgabe herangezogen werden. Auch wenn die Messungen der Latenzzeit und Bandbreite hier nicht überbewertet werden sollten, aufgrund der in Kapitel genannten Gründe kann immerhin ein Vergleich zwischen den evaluierten Verfahren gezogen werden. Der JAP- Dienst ist sowohl bei Latenzzeit als auch Bandbreite der schnellste Anonymisierungsdienst. Kritische Ergebnisse waren nur bei dem I2P-Netzwerk zu verzeichnen. Nebst hoher Instabilität, welche sich durch Abbruch von Testläufen oder dem nicht Erreichen des Outproxys bemerkbar macht, sind im Test sehr geringe Bandbreiten und sehr hohe Latenzzeiten ermittelt worden. Die Zukunft vieler Anonymisierungsdienste ist ungewiss. Dies liegt an der noch unklaren gesetzlichen Lage. Es müssen noch viele Details geregelt werden. Die zukünftige Entwicklung von Anonymisierungsdiensten wird möglicherweise im Rahmen der Darknet- oder Overlaynetzwerke stattfinden. Für diese Netzwerke existieren noch keine juristischen Ansätze. Außerdem ist in diesen Netzen die Umsetzung neuer Techniken leichter möglich als auf der Struktur des normalen Internets. Dies kann man am Beispiel zu I2P gut sehen. Abschließend können also drei der vier hier vorgestellten Produkte eine Lösungsmöglichkeit für die Problematik der Anonymisierung bieten. Bedacht werden sollte immer, dass kein Verfahren eine vollständige, nicht aufdeckbare Anonymität garantieren kann. 80

86 Literatur [20007] JAP TEAM: JAP und Verschlüsselung. In: Technische Universität Dresden desc/encr_jap.html (2007), 13. Oktober [20008] JAP TEAM: JAP und Strafverfolgung. In: Technische Universität Dresden strafverfolgung/index_de.html (2008), 14. Juni [Bac07] BACHFELD, Daniel: Anonymisierungsnetz Tor abgephisht, Teil 2. In: Heise Zeitschriften Verlag security/anonymisierungsnetz-tor-abgephisht- Teil-2--/news/meldung/99318 (2007), 27. November [BLTR06] BAUER, Johannes ; LIEBSCHER, Albrecht ; THIELKING-RIECHERT, Klaus: OpenVPN Grundlagen, Konfiguration, Praxis. In: dpunkt.verlag GmbH (2006) [BM03] BÄUMLER, Helmut ; MUTIUS, Albert von: Anonymität im Internet. In: SecuMedia Verlag (2003) [CBR04] CHESWICK, William R. ; BELLOVIN, Steven M. ; RUBIN, Avi: Firewalls und Sicherheit im Internet. In: ADDISON-WESLEY (2004), Juni [Dav81] DAVID, Chaum: Untraceable electronic Mail, return adresses and digital pseudonyms, Communications of the ACM. 24 (1981), Februar, Nr. 2 [Dem03] DEMUTH, Thomas: Ein Beitrag zur Anonymität in Kommunikationsnetzen. In: Shaker Verlag (2003) [DH07] DINGER, Jochen ; HARTENSTEIN, Hannes: Die vermeintliche Robustheit von Peer-to-Peer-Netzen. In: Universität Karlsruhe dinger-jochen--182/pdf/dinger.pdf (2007), 20. Dezember [DM08] DINGLEDINE, Roger ; MATHEWSON, Nick: Tor Protocol Specification. https://www.torproject.org/svn/trunk/doc/ spec/tor-spec.txt (2008), 12. Februar

87 [DMS08] DINGLEDINE, Roger ; MATHEWSON, Nick ; SYVERSON, Paul: TOR: The Second-Generation Onion Router. https:// tor-design.html (2008), 12. Februar [Eur07] [Fed07] EUROPÄISCHE UNION: RICHTLINIE 2006/24/EG DES EURO- PAEISCHEN PARLAMENTS UND DES RATES :105:0054:0063:DE:PDF (2007), 10. Oktober FEDERRATH, Prof. Dr. H.: Allgemeine Informationen zum theoretischen Verfahren. In: Technische Universität Dresden http: //anon.inf.tu-dresden.de/japtechbgpaper.pdf (2007), 13. Oktober [FHW98] FUHRBERG, Kai ; HAEGER, Dirk ; WOLF, Stefan: Internet- Sicherheit. In: Carl Hanser Verlag München Wien (1998) [GSRZ08] GAMER, Thomas ; SORGE, Christoph ; RAABE, Dr. O. ; ZITTER- BART, Prof. Dr. M.: Datenschutz in Kommunikationsnetzen. In: Universität Karlsruhe (2008), 15. Februar [Her08] [Jon08] HERRMANN, Dominik: Perfeval. In: Universität Regensburg http: //www-sec.uni-r.de/herrmann/perfeval.zip (2008), 15. August JONDOS GMBH: Wir sind bereit - die Vorratsdatenspeicherung kann kommen. https://www.jondos.de/de/node/801 (2008), 27. August [K 07] KÖPSEL, Stefan: AnonDienst - Design und Implementierung. In: Technische Universität Dresden (2007), 14. Oktober [Kel07] [KM08] KELTER, Harald: Das Ende der Anonymität? Datenspuren in modernen Netzen. In: SecuMedia Verlag (2007), 9. Oktober KÖPSEL, Stefan ; MIOSGA, Tobias: Strafverfolgung trotz Anonymität. In: Technische Universität Dresden, Institut für Systemarchitektur sidar/prima2005/programm.html (2008), 12. Juli

88 [Kre07a] KREMPL, Stefan: 24C3: Hackerfreiräume und Anonymisierungsdienste. In: Heise Zeitschriften Verlag (2007), 28. Dezember [Kre07b] KREMPL, Stefan: TOR-Server durch Vorratsdatenspeicherung von Schließung bedroht. In: Heise Zeitschriften Verlag http: //www.heise.de/newsticker/tor-server-durch- Vorratsdatenspeicherung-von-Schliessungbedroht--/meldung/ (2007), 15. Dezember [Kub08] [Kya98] KUBIZIEL, Jens: To be or I2P - A introduction into anonymous communication with I2P. (2008), 27. Februar KYAS, Othmar: Sicherheit im Internet. In: An International Thomason Publisihing Company (1998) [Lub08] LUBEK, Sven: Ich habe einen stichhaltigen Grund, einen Tornutzer zu finden. Können Sie helfen? In: Tor.de Anonym online 10._Ich_habe_einen_stichhaltigen_Grund% 2C_einen_Tornutzer_zu_finden._K%C3% B6nnen_Sie_helfen%3F (2008), 15. Juli [Mar99] [Pfi07a] [Pfi07b] [PW07] MARX, Gary T.: What s in a Name? Some Reflections on the Sociology of Anonymity. In: The Information Society, special issue on anonymous communication forthcoming (1999) PFITZMANN, Andreas: Anonymity, Unobservability, and Pseudonymity - A Proposal for Terminology. In: Technische Universität Dresden Anon_Terminology_v0.8.doc (2007), 14. Oktober PFITZMANN, Andreas: Sicherheit in Rechnernetzen. In: Technische Universität Dresden ~pfitza/dsukrypt.pdf (2007), 14. Oktober PLÖTNER, Johannes ; WENDZEL, Steffen: Praxisbuch Netzwerk- Sicherheit. In: Galileo Computing (2007)

89 [Rem08] REMUS, Patric: Archicrypt Stealth VPN Steckbrief. http: //www.archicrypt.com/sbstealthvpn.htm (2008), 13. April [RFC99] Hypertext Transfer Protocol HTTP/1.1. In: Internet Engineering Task Force (1999), Juni [RR98] [Rue07] REITER, Michael K. ; RUBIN, Aviel D.: Crowds: Anonymity for Web Transactions. In: ACM Transactions on Information and System Security (1998) RUETTEN, Christiane: Anonymisierungsnetz Tor abgephisht. In: Heise Zeitschriften Verlag Anonymisierungsnetz-Tor-abgephisht--/news/ meldung/95770 (2007), 10. September [Sch08a] SCHWEYER, Tassilo: How Cryptography Works. (2008), 2. April [Sch08b] SCHWEYER, Tassilo: How Garlic Routing Works. (2008), 2. April [Sch08c] SCHWEYER, Tassilo: How the Network Database (netdb) Works. (2008), 2. April [Sch08d] SCHWEYER, Tassilo: How Tunnel Routing Works. http: //www.i2p2.de/how_tunnelrouting (2008), 2. April [Sch08e] SCHWEYER, Tassilo: I2P s Threat Model. how_threatmodel (2008), 2. April [Sch08f] SCHWEYER, Tassilo: Introduction to How I2P Works. (2008), 2. April [Sim08] SIMPSON, W.: IP in IP Tunneling. In: IETF - The Internet Engineering Task Force rfc1853.txt?number=1853 (2008), 22. April [The08a] THE DEBIAN PROJECT: Debian-Sicherheitsankündigung DSA openssl Voraussagbarer Zufallszahlengenerator. http: //www.debian.org/security/2008/dsa-1571 (2008), 13. Mai

90 [The08b] THE TOR PROJECT: TOR-Übersicht. https:// (2008), 15. Februar [Wei07] WEICHERT, Dr. T.: Stellungnahme des ULD vom zum Gesetzesentwurf der Bundesregierung für ein Gesetz zur Neuregelung der Telekommunikationsüberwachung und anderer verdeckter Ermittlungsmassnahmen sowie zur Umsetzung der Richtlinie 2006/24/EG, BR-Drucksache 275/07. In: Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein https:// vorratsdatenspeicherung.htm#_toc (2007), 10. Oktober [Wen07] WENDOLSKY, Rolf: Preise und Bezahlmethoden. https: //www.jondos.de/de/payment (2007), 14. Oktober [WHF06] WENDOLSKY, Rolf ; HERRMANN, Dominik ; FEDERRATH, Hannes: Performance Comparison of low-latency Anonymisation Services from a User Perspective. In: Universität Regensburg WeHF2007PETPerfevalPreproceedings.pdf (2006), Februar

91 Abbildungsverzeichnis 1 Senderanonymität (Unilaterale Anonymität)[Kel07] Empfängeranonymität (Unilaterale Anonymität)[Kel07] Unverkettbarkeit (Bilaterale Anonymität)[Kel07] Grade der Anonymität[RR98] Anonymisierung in Tauschbörsen Wikipedia Verbot für JAP-Benutzer HTTP Header Anzeige mit aktuellem Referer Aufbau des Systems [K 07] Struktur eines Mix-Paketes [K 07] Visualisierung des Konzeptes [Fed07] Funktionen des Mix-Systems [Pfi07b] Topologie des Onion-Routing [Dem03] Control Cell [DM08] Relay Cell [DM08] Verbindung zum Zielrechner mit TOR I2P Tunnel eingehender I2P Tunnel verschlüsselte Verbindung zum Archicrypt VPN-Server [Rem08] Tunnel-Prinzip [PW07] Auswahl der Mixkaskaden Vidalia-GUI Vidalia-Konfigurationsmenü I2P - Tunnelkonfiguration Konfiguration eines TOR-Relay (1) Konfiguration eines TOR-Relay (2) JAP-Installation Komponentenauswahl Java-Installation Installation des Vidalia-Bundle Installation der Archicrypt Software Überprüfung des Hashwertes Installation der I2P Software

92 Tabellenverzeichnis 1 Anonymisierungsdienste im Internet Anonymisierungsprogramme für das Internet (Stand ) Flags eines Mix-Paketes Unterschiedliche Informationsbasis für verschiedene Mixe mögliche Optionen von CMD [DM08] Optionen des Relay-CMD [DM08, DMS08] Aufgaben der Nodes Testrechner Internet-Protokolle (JAP) Internet-Protokolle (TOR) Internet-Protokolle (Archicrypt Stealth VPN) Internet-Protokolle (I2P) Arithmet. Mittelwert für die gemessenen Latenzzeiten (Millisek.) Arithmet. Mittelwert für die gemessenen Bandbreiten (Kilobyte/s) Preistabelle JAP Preistabelle Archicrypt Stealth VPN

93 12 Anhang 12.1 PHP-Skript für IP-Adressen Auskunft Die Vergabe von IP-Adressen erfolgt länderspezifisch. Somit ist eine Zuordnung IP-Adresse zu Land möglich. Das freie Projekt IP to Country 43 bietet für diesen Dienst eine Datenbank in Form einer csv-datei an. Bevor man mithilfe von PHP die IP-Adresse auswerten kann, muss die entsprechende Datenbank initialisiert werden. Dazu wird die Datenbank country_db über den PHPMyAdmin erstellt. Da es möglich ist, im PHPMyAdmin SQL-Code einzugeben, wird im Weiteren so verfahren. In der Datenbank wird nun eine Tabelle erstellt, welche die Werte aus der csv-datei entgegennehmen soll. Dies geschieht mit folgendem Befehl: CREATE TABLE i p t o c o u n t r y ( ip_from i n t ( 4 ), i p _ t o i n t ( 4 ), country_code2 char ( 2 ), country_code3 char ( 3 ), country_name varchar ( 50 ) ) ; Listing 12: Erstellung der Tabelle Jetzt werden mit dem Befehl aus Listing 13 Listing 13: Erstellung der Tabelle load data i n f i l e c : \ \ ip to country. csv into table i p t o c o u n t r y f i e l d s terminated by, enclosed by " l i n e s terminated by \ n die notwendigen Daten in die Tabelle eingelesen. Zur Optimierung kann der Befehl optimize table iptocountry angewendet werden. Nun ist ein Zugriff auf die Datenbank möglich. Hier wird nun kurz die Funktionsweise des Skriptes erklärt, welches in dem Kapitel verwendet wurde. Die Erläuterung wird anhand des hier abgebildeten Quellcodes vorgenommen. <? Listing 14: PHP-Skript für IP-Adressauskunft $ip = getenv ( "REMOTE_ADDR" ) ; echo " <b> I h r e IP i s t : </b> " ; p r i n t $ip ; echo <br > ; echo " <b>host : </b> " ; $host = gethostbyaddr ( $ip ) ; echo $host ; echo <br > ; 43

94 echo " <b>browser : </b> " ; $browser = $_SERVER[ HTTP_USER_AGENT ] ; echo $browser ; echo <br > ; $os = " unknown " ; i f ( s t r s t r ( $browser, " Windows 98 " ) ) $os= " Windows 98 " ; e l s e i f ( s t r s t r ( $browser, "NT 4.0 " ) ) $os= " Windows NT " ; e l s e i f ( s t r s t r ( $browser, "NT 5.1 " ) ) $os= " Windows XP" ; e l s e i f ( s t r s t r ( $browser, "NT 6.0 " ) ) $os= " Windows V i s t a " ; e l s e i f ( s t r s t r ( $browser, " Win " ) ) $os= " Windows " ; e l s e i f ( s t r s t r ( $browser, "Mac" ) ) $os= "Mac OS" ; e l s e i f ( s t r s t r ( $browser, " Linux " ) ) $os= " Linux " ; e l s e i f ( s t r s t r ( $browser, " Unix " ) ) $os= " Unix " ; echo " <b>betriebssystem : </b> " ; echo $os ; $dbh=mysql_connect ( " l o c a l h o s t :3306 ", " r o o t ", " " ) ; mysql_select_db ( " country_ db " ) ; $country_query = "SELECT country_code2, country_name FROM i p t o c o u n t r y ". "WHERE IP_FROM<= i n e t _ a t o n ( $REMOTE_ADDR ) ". "AND IP_TO>= i n e t _ a t o n ( $REMOTE_ADDR ) " ; $country_ exec = mysql_query ( $country_ query ) ; $ccode_array=mysql_fetch_array ( $country_exec ) ; $country_code=$ccode_array [ country_code2 ] ; $country_name=$ccode_array [ country_name ] ; echo <br > ; echo " <b>land : </b> " ; echo " $country_code $country_name " ;?> mysql_close ( $dbh ) ; In den Zeilen 2 bis 4 wird mithilfe der speziellen PHP-Umgebungsvariablen REMOTE_ADDR die IP-Adresse abgefragt und ausgegeben. Ähnlich wird in den Zeilen 7 bis 10 der Host, also der Internet-Service-Provider abgefragt. In den Zei-

95 len 11 bis 13 wird mit der Variable HTTP_USER_AGENT der verwendete Browser ermittelt. Da in dieser Ausgabe auch immer das verwendete Betriebssystem aufgeführt wird, kann man diese Ausgabe leicht mit einer Stringfunktion durchsuchen. Diese Stringfunktion in den Zeilen 15 bis 31 sucht nach bestimmten Keywords, welche einen Rückschluss auf das eingesetzte Betriebssystem zulassen. In den Zeilen 33 und 34 erfolgt nun der Datenbankzugriff. In der Datenbank wurden vorher mehrere tausend Datensätze eingelesen, welche eine Zuordnung von einer IP- Adresse zu einem Land ermöglichen. Übergabeparameter sind die IP-Adresse von dem Computer auf dem die Datenbankanwendung läuft. In diesem Fall der MySQL typische Port 3306, der Root-Nutzer und das Passwort. Dann wird die Datenbank country_db ausgewählt. In den Zeilen 36 bis 38 geschieht Folgendes: Es wird eine Zuordnung zur Besucher-IP gemacht. Dadurch dass COUNTRY_CODE2 und COUNTRY_NAME selektiert werden, entsteht eine Ausgabe, welche die ersten zwei Buchstaben eines Landes und dann den Landesnamen ausgibt. Für Amerika wäre dies beispielsweise US - UNITED STATES. In Zeile 40 wird dieses Suchergebnis abgefragt und in Zeile 41 wird der Ergebnisdatensatz in ein Array übertragen. Da in diesem Array nun aber zwei Werte stehen, nämlich COUNTRY_CODE2 und COUNTRY_NAME, wird dies in den Zeilen 42 und 43 noch einer separaten Variablen zugewiesen, welche dann zusammen in Zeile 47 ausgegeben werden. Am Ende muss die Verbindung durch mysql_close noch geschossen werden Untersuchung mit Wireshark Ziel ist es, zu zeigen, dass die Kommunikation zwischen dem eigenen PC und dem Eingangsknoten/Eingangskaskade des Anonymisierungsnetzes verschlüsselt ist. Laut Literatur ist dies bei jedem hier aufgezeigten Verfahren der Fall. Auf diese Weise soll der Inhalt der Kommunikation sowie an der Kommunikation beteiligte Instanzen verborgen werden: Login/Username Passwort besuchter Webserver/Webseiten und deren IP-Adresse Um dies aufzuzeigen, eignet sich das Programm Wireshark sehr gut. Die Kommunikation erfolgt in diesem Testszenario über WLAN. Für dieses Szenario wurde sich in einem Forum 44 angemeldet, welches nur HTTP unterstützt, d.h. ohne den Einsatz von Anonymisierungsprodukten, die den Verkehr verschlüsseln, ist es möglich, den Kommunikationsinhalt auslesen. Im Falle von TOR, JAP und Archicrypt Stealth VPN bietet es sich an, in den Capture Filter den Parameter tcp 44 Login: fh-brs, Passwort: xuv69sakt3

96 einzufügen, damit nur TCP Pakete angezeigt werden. Das bietet sich in diesem Fall an, da genannte Verfahren ausschließlich über das TCP-Protokoll kommunizieren. Bei I2P war UDP als Filter zu nehmen, da es größtenteils mit UDP arbeitet. Ebenfalls sinnvoll ist es, da man ja die Pakete zwischen Eingangsknoten/Eingangskaskade und eigenem Rechner untersuchen will, lediglich die Pakete zu untersuchen, welche als Quelle den eigenen PC haben. Wireshark ist standardmäßig so konfiguriert, dass es im Promiscuous Mode scannt. Diese Einstellung wurde hier beibehalten. Der Capture-Filter sah demnach folgendermaßen aus: src host && tcp bzw. src host && udp. Die anschließenden Tests liefen erwartungsgemäß und daher erfolgreich ab. Es konnte aus den Paketen keine der oben genannten sensiblen Daten erhoben werden Installation des JAP-Clients Die Installation wird durch einen Doppelklick auf die Datei japsetup.exe gestartet. Die Setup Datei kann von der Projektseite bezogen werden. Anfänglich muss ausgewählt werden, welche Komponenten installiert werden sollen (siehe Grafik 26). Zwingend notwendig ist nur die JAP-Komponente. Die Swing-Bibliothek ist nur relevant, wenn man eine Java-Version installiert hat, welche kleiner als 1.2 ist. Die Swing-Installation soll nur vorgenommen werden, wenn beim Programmstart eine entsprechend Fehlermeldung auftritt. Die Java-Komponente sollte nur ausgewählt werden, wenn noch kein Java auf dem System installiert ist. 45 die jeweiligen Capture-Files sind auf der CD im Ordner Wireshark-Dateien/Einwahl-Verschlüsselung zu finden

97 Abbildung 26: JAP-Installation Komponentenauswahl Im nächsten Schritt ist der Installationspfad für das Programm auszuwählen. Falls bei der Komponentenauswahl Java markiert wurde, startet die automatisch nach der JAP-Installation, die Java-Installation. Abbildung 27: Java-Installation Danach ist die Installation beendet und das Programm kann gestartet werden. Im Browser ist der HTTP-Proxy auf :4001 zu konfigurieren, damit die Kommunikation über den Java Anon Proxy geleitet wird.

98 12.4 Intstallation des TOR-Vidalia-Bundle Für die Installation muss die Setup-Datei von der Entwicklerseite bezogen werden. Da dort eine PGP-Signatur 46 der Setup-Datei vorhanden ist, ist diese natürlich auch überprüfbar, um sicher zu gehen, dass man das Original Installationspaket der Entwickler erhält, und nicht ein modifiziertes Paket. Die Installation beginnt mit der Ausführung der vidalia-bundle exe. Zuerst ist die gewünschte Sprache auszuwählen. Danach ist eine Auswahl zu treffen, was installiert werden soll (siehe Grafik 28). Abbildung 28: Installation des Vidalia-Bundle Danach ist der Installationspfad anzugeben. Nach dem darauf folgenden Kopiervorgang ist die Installation abgeschlossenen. Im Gegensatz zu unixioden Betriebssystem ist hier keine Anpassung der Privoxy-Konfigurationsdatei notwendig. Beim nächsten Start des Firefox-Browsers ist in der unteren rechten Ecke der Tor-Button angebracht. Dieser Button muss bei der Nutzung von TOR aktiviert sein. Das Produkt kann nun genutzt werden Intstallation der Archicrypt Software Die Installation ist sehr einfach und schnell erledigt. Nach dem Aktivieren der Install.exe startet das Installationsmenü. Nach dem Akzeptieren der Lizenzbe- 46

The Second Generation Onion Router. Stefan Hasenauer, Christof Kauba, Stefan Mayer

The Second Generation Onion Router. Stefan Hasenauer, Christof Kauba, Stefan Mayer The Second Generation Onion Router Übersicht Einleitung Verfahren zur Anonymisierung Allgemeines über Tor Funktionsweise von Tor Hidden Services Mögliche Angriffe 2 Einleitung Identifizierung im Internet

Mehr

Der Person: David Chaum

Der Person: David Chaum Chaum Der Person: David Chaum Erfinder einiger krypyographischer Protokoll Fortentwicklung elektronischer Zahlungsmittel Gründer der veröffentlicht Untraceable Electronic Mail, Return Addresses, and Digital

Mehr

Digitale Selbstverteidigung

Digitale Selbstverteidigung Digitale Selbstverteidigung Vorträge & Workshops» Surfen» Mailen» Anonym bleiben Wahl des Browsers Die Qual der Wahl» Es gibt nicht den einzig wahren Browser» Vorteile quelloffener Browser wie z.b. Firefox:

Mehr

Anonymisierung im Internet

Anonymisierung im Internet Anonymisierung im Internet Projekt von Gregor Ihln und Marjan Zargani Gliederung 1.Einleitung - was passiert beim Surfen? Gliederung 2. Der Gläserne Surfer - welche Informationen gebe ich beim Surfen preis?

Mehr

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen

SFTP Datenübertragungsclient PK-SFTP. automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen SFTP Datenübertragungsclient PK-SFTP automatische Verbindung zu einem SFTP-Server in einstellbaren Zeitintervallen senden, abholen und verifizieren der bereitstehenden Daten Protokollierung der Datenübertragung

Mehr

Anonymes Kommunizieren mit Mixminion

Anonymes Kommunizieren mit Mixminion Anonymes Kommunizieren mit Mixminion Seminar Peer-to-Peer Netzwerke Claudius Korzen Institut für Informatik Albert-Ludwigs-Universität, Freiburg SS 2009 28. Juli 2009 1/ 35 Überblick 1 Motivation 2 Grundlagen

Mehr

Gefahren aus dem Internet 6 Aktive Angriffe April 2010

Gefahren aus dem Internet 6 Aktive Angriffe April 2010 6 Aktive Angriffe Lernziele Sie können grob erklären, wie ein Angreifer in Ihren Computer eindringen kann. Sie können herausfinden, welche Ports auf Ihrem Computer offen sind. Sie wissen, warum der Einsatz

Mehr

Einführung in die Informationstechnik. VII Handyviren Anonym im Netz surfen

Einführung in die Informationstechnik. VII Handyviren Anonym im Netz surfen Einführung in die Informationstechnik VII Handyviren Anonym im Netz surfen 2 Handyschadsoftware erster Handyvirus: 2004 für SymbianOS: Cabir Verbreitung über Bluetooth Ab Herbst 2004 Trojaner Mosquit.a:

Mehr

Technischer Datenschutz im Internet

Technischer Datenschutz im Internet Technischer Datenschutz im Internet Prof. Dr. Lehrstuhl Management der Informationssicherheit Uni Regensburg http://www-sec.uni-regensburg.de/ Was ist Sicherheit? Techniken zum Schutz? Stand der Technik?

Mehr

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen)

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen) Datenschutzerklärung der Etacs GmbH Die Etacs GmbH wird den Anforderungen des Bundesdatenschutzgesetzes (BDSG) gerecht.personenbezogene Daten, d.h Angaben, mittels derer eine natürliche Person unmittelbar

Mehr

Wiederholung: Informationssicherheit Ziele

Wiederholung: Informationssicherheit Ziele Wiederholung: Informationssicherheit Ziele Vertraulichkeit: Schutz der Information vor unberechtigtem Zugriff bei Speicherung, Verarbeitung und Übertragung Integrität: Garantie der Korrektheit (unverändert,

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

Impressum. Angaben gemäß 5 TMG: Vertreten durch: Kontakt: Registereintrag: Umsatzsteuer-ID: Farbenmühle mcdrent GmbH & CO. KG Hagdorn 13 45468 Mülheim

Impressum. Angaben gemäß 5 TMG: Vertreten durch: Kontakt: Registereintrag: Umsatzsteuer-ID: Farbenmühle mcdrent GmbH & CO. KG Hagdorn 13 45468 Mülheim Impressum Angaben gemäß 5 TMG: Farbenmühle mcdrent GmbH & CO. KG Hagdorn 13 45468 Mülheim Vertreten durch: Jens Müller Kontakt: Telefon: 004915168497847 E-Mail: info@mcdrent.de Registereintrag: Eintragung

Mehr

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH

Virtual Private Networks. Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Virtual Private Networks Hans Peter Dittler BRAINTEC Netzwerk-Consulting GmbH Inhalt Einleitung Grundlagen Kryptographie IPSec Firewall Point-to-Point Tunnel Protokoll Layer 2 Tunnel Protokoll Secure Shell

Mehr

Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG SCHRITT 1: INSTALLATION

Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG SCHRITT 1: INSTALLATION Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG Obwohl inzwischen immer mehr PC-Nutzer wissen, dass eine E-Mail so leicht mitzulesen ist wie eine Postkarte, wird die elektronische Post

Mehr

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten

Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten Versuch: Eigenschaften einer Unterhaltung Instant Messaging Unterhalten Sie sich leise mit Ihrem Nachbarn über ein aktuelles Thema. Dauer ca. 2 Minuten welche Rollen gibt es in einem IM-System? Analysieren

Mehr

FTP-Leitfaden RZ. Benutzerleitfaden

FTP-Leitfaden RZ. Benutzerleitfaden FTP-Leitfaden RZ Benutzerleitfaden Version 1.4 Stand 08.03.2012 Inhaltsverzeichnis 1 Einleitung... 3 1.1 Zeitaufwand... 3 2 Beschaffung der Software... 3 3 Installation... 3 4 Auswahl des Verbindungstyps...

Mehr

Pseudonymität und Anonymität im Internet

Pseudonymität und Anonymität im Internet Pseudonymität und Anonymität im Internet jerome, vdd, timo81, klmann, cmeyer, ministr, gsl, sorrow, mase Carl von Ossietzky Universtiät Oldenburg 31. Januar 2008 Inhalt 1 Einleitung 2 Livesuche 3 Gruppenarbeit

Mehr

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de

Remote Tools. SFTP Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de Remote Tools SSH SCP Proxy SFTP Port X11 christina.zeeh@studi.informatik.uni-stuttgart.de Grundlagen SSH Inhalt Remote-Login auf marvin Datentransfer Graphische Anwendungen Tunnel VPN SSH für Fortgeschrittene

Mehr

Internet: Was ist das? - Routing

Internet: Was ist das? - Routing Internet: Was ist das? - Routing Auch Router Server Router Client ClientServer? Grundlagen Internet Sicherheit Angriffe Schutz Internet Map, The Opte Project Internet: Was ist das? - Netzwerk Peer-to-Peer

Mehr

Spurenarm und anonym surfen

Spurenarm und anonym surfen Spurenarm und anonym surfen Kire Swiss Privacy Foundation www.privacyfoundation.ch Digitale Gesellschaft www.digitale-gesellschaft.ch Workshop Spurenarm und anonym surfen Inhaltsverzeichnis Einführung

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0

SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 SECURE DATA DRIVE CLIENTSEITIGE VERSCHLÜSSELUNG Technical Insight, Oktober 2014 Version 1.0 mit den eingetragenen Materialnummern Inhalt Inhalt... 2 1 Vorwort... 3 2 Allgemeines zur Verschlüsselung...

Mehr

FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION. Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht

FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION. Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht FREIHEIT GESTALTEN VERSCHLÜSSELUNG ALS FREIHEIT IN DER KOMMUNIKATION Christian R. Kast, Rechtsanwalt und Fachanwalt für IT Recht INHALTSÜBERSICHT Risiken für die Sicherheit von Kommunikation und die Freiheit

Mehr

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen

SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen SSL/TLS Sicherheit Warum es sich lohnt, sich mit Ciphersuites zu beschäftigen Immo FaUl Wehrenberg immo@ctdo.de Chaostreff Dortmund 16. Juli 2009 Immo FaUl Wehrenberg immo@ctdo.de (CTDO) SSL/TLS Sicherheit

Mehr

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr.

SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY. Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. SICHERE DATENHALTUNG IN DER CLOUD VIA HANDY 1 Tuba Yapinti Abschlussvortrag der Bachelorarbeit Betreuer: Prof. Reinhardt, Dr. Bernd Borchert GLIEDERUNG 1. Motivation Gründe für die Entwicklung Ideen für

Mehr

Anonymität ist nicht binär. Oder: der Versuch, ein schwer angreifbares Netzwerk zu erstellen. www.i2p2.de

Anonymität ist nicht binär. Oder: der Versuch, ein schwer angreifbares Netzwerk zu erstellen. www.i2p2.de Anonymität ist nicht binär. Oder: der Versuch, ein schwer angreifbares Netzwerk zu erstellen. www.i2p2.de Übersicht I2P ist ein low latency Mix Netzwerk: Geringe Latenz im sec. Bereich, die gering genug

Mehr

ESecuremail Die einfache Email verschlüsselung

ESecuremail Die einfache Email verschlüsselung Wie Sie derzeit den Medien entnehmen können, erfassen und speichern die Geheimdienste aller Länder Emails ab, egal ob Sie verdächtig sind oder nicht. Die Inhalte von EMails werden dabei an Knotenpunkten

Mehr

Mitarbeiterinformation

Mitarbeiterinformation Datenschutz & Gesetzliche Regelungen Praktische Hinweise Kontakt zu Ihrem Datenschutzbeauftragten Elmar Brunsch www.dbc.de Seite 1 von 5 Einleitung In den Medien haben Sie sicher schon häufig von Verstößen

Mehr

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Das E-Mail-Programm Outlook 98 von Microsoft bietet Ihnen durch die Standard- Integration des E-Mail-Protokolls S/MIME (Secure/MIME) die Möglichkeit,

Mehr

Datenschutzerklärung / Haftungshinweis / Disclaimer: Haftung für Inhalte

Datenschutzerklärung / Haftungshinweis / Disclaimer: Haftung für Inhalte Datenschutzerklärung / Haftungshinweis / Disclaimer: Haftung für Inhalte Die Inhalte unserer Seiten wurden mit größter Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte

Mehr

Datenschutzerklärung von SL-Software

Datenschutzerklärung von SL-Software Datenschutzerklärung von SL-Software Software und Büroservice Christine Schremmer, Inhaberin Christine Schremmer, Odenwaldring 13, 63500 Seligenstadt (nachfolgend SL-Software bzw. Wir genannt) ist als

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Schwachstellenanalyse 2013

Schwachstellenanalyse 2013 Schwachstellenanalyse 2013 Sicherheitslücken und Schwachstellen in Onlineshops Andre C. Faßbender Schwachstellenforschung Faßbender 09.01.2014 Inhaltsverzeichnis 1. Abstract... 3 2. Konfiguration der getesteten

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr

Nutzungsbedingungen. Urheberschutz

Nutzungsbedingungen. Urheberschutz Nutzungsbedingungen Urheberschutz Die in der genutzten Event-App veröffentlichten Inhalte und Werke sind urheberrechtlich geschützt. Jede vom deutschen Urheberrecht nicht zugelassene Verwertung bedarf

Mehr

VPN mit Windows Server 2003

VPN mit Windows Server 2003 VPN mit Windows Server 2003 Virtuelle private Netzwerke einzurichten, kann eine sehr aufwendige Prozedur werden. Mit ein wenig Hintergrundwissen und dem Server- Konfigurationsassistenten von Windows Server

Mehr

Tor. Anonym surfen. Kire. Swiss Privacy Foundation

Tor. Anonym surfen. Kire. Swiss Privacy Foundation Tor Anonym surfen Kire Swiss Privacy Foundation Inhaltsverzeichnis Browser-Spuren - technisch und rechtlich Tor - der Zwiebelrouter Übersicht Client installieren und konfigurieren Ubuntu Linux Firefox

Mehr

Installationsanleitung OpenVPN

Installationsanleitung OpenVPN Installationsanleitung OpenVPN Einleitung: Über dieses Dokument: Diese Bedienungsanleitung soll Ihnen helfen, OpenVPN als sicheren VPN-Zugang zu benutzen. Beachten Sie bitte, dass diese Anleitung von tops.net

Mehr

Nationale Initiative für Internet- und Informations-Sicherheit

Nationale Initiative für Internet- und Informations-Sicherheit Sichere Kommunikation im Zeitalter von PRISM? Nationale Initiative für Internet- und Informations-Sicherheit Mathias Gärtner, NIFIS e.v. zweiter Vorstand Öffentlich bestellter und vereidigter Sachverständiger

Mehr

Anonymes Surfen - Eine Einführung

Anonymes Surfen - Eine Einführung Grundlagen 16.02.2008 Gliederung Grundlagen 1 Anonymes Surfen - Grundlagen 2 Fox 3 TOR - The Onion Router Park Opera -Proxy.NET 4 5 der Anonymisierung Grundlagen Anonymes Surfen - Grundlagen Ohne Anonymisierung:

Mehr

Domain Name Service (DNS)

Domain Name Service (DNS) Domain Name Service (DNS) Aufgabe: den numerischen IP-Adressen werden symbolische Namen zugeordnet Beispiel: 194.94.127.196 = www.w-hs.de Spezielle Server (Name-Server, DNS) für Listen mit IP-Adressen

Mehr

Vortrag Keysigning Party

Vortrag Keysigning Party Vortrag Keysigning Party Benjamin Bratkus Fingerprint: 3F67 365D EA64 7774 EA09 245B 53E8 534B 0BEA 0A13 (Certifcation Key) Fingerprint: A7C3 5294 E25B B860 DD3A B65A DE85 E555 101F 5FB6 (Working Key)

Mehr

OFTP2 - Checkliste für die Implementierung

OFTP2 - Checkliste für die Implementierung connect. move. share. Whitepaper OFTP2 - Checkliste für die Implementierung Die reibungslose Integration des neuen Odette-Standards OFTP2 in den Datenaustausch- Workflow setzt einige Anpassungen der Systemumgebung

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen

Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Grundbegriffe der Kryptographie II Technisches Seminar SS 2012 Deniz Bilen Agenda 1. Kerckhoff sches Prinzip 2. Kommunikationsszenario 3. Wichtige Begriffe 4. Sicherheitsmechanismen 1. Symmetrische Verschlüsselung

Mehr

Verteilte Systeme. Übung 10. Jens Müller-Iden

Verteilte Systeme. Übung 10. Jens Müller-Iden Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Technische Realisierungen von Sperren im Internet

Technische Realisierungen von Sperren im Internet Technische Realisierungen von Sperren im Internet Prof. Dr. Universität Regensburg Lehrstuhl Management der Informationssicherheit http://www-sec.uni-regensburg.de/ 1 Technische Realisierungen von Sperren

Mehr

White Paper. Datenschutz für Betreiber von WLAN-Hotspots Die VPN-Server-Lösung von hotsplots. Stand: März 2007

White Paper. Datenschutz für Betreiber von WLAN-Hotspots Die VPN-Server-Lösung von hotsplots. Stand: März 2007 White Paper Datenschutz für Betreiber von WLAN-Hotspots Die VPN-Server-Lösung von hotsplots Stand: März 2007 hotsplots GmbH Dr. Ulrich Meier, Jörg Ontrup Stuttgarter Platz 3 10627 Berlin E-Mail: info@hotsplots.de

Mehr

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8 Byte-Taxi Bedienungsanleitung Seite 1 von 8 Inhaltsverzeichnis 1. Beschreibung 3 2. Systemvoraussetzungen 4 3. Installationsanleitung 5 4. Bedienung 6 5. Infos & Kontakt 8 Seite 2 von 8 1. Beschreibung

Mehr

Session Management und Cookies

Session Management und Cookies LMU - LFE Medieninformatik Blockvorlesung Web-Technologien Wintersemester 2005/2006 Session Management und Cookies Max Tafelmayer 1 Motivation HTTP ist ein zustandsloses Protokoll Je Seitenaufruf muss

Mehr

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

Zertifizierung von Mixbetreibern (JonDonym)

Zertifizierung von Mixbetreibern (JonDonym) Zertifizierung von Mixbetreibern (JonDonym) Die Identität der Betreiber von JonDonym-Mixen wird durch Certification Authorities zertifiziert. Neben der JonDos GmbH bietet auch die German Privacy Foundation

Mehr

Prozessbeschreibung des Trackings zur Firmenerkennung

Prozessbeschreibung des Trackings zur Firmenerkennung Prozessbeschreibung des Trackings zur Firmenerkennung Überblick Nach 1 Abs.1 des Datenschutzgesetzes soll der Einzelne davor geschützt werden, durch den Umgang mit seinen personenbezogenen Daten in seinem

Mehr

Wozu sind Firewalls und VPN gut?

Wozu sind Firewalls und VPN gut? Wozu sind Firewalls und VPN gut? Wo wir hin wollen Einführung Was sind und wie funktionieren IP, TCP und UDP? Wie passt eine Firewall in dieses Bild? VPN, Verschlüsselung und ihre Auswirkungen Aktuelle

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

1 Praktikum Protokolle SS2007 Fachhochschule OOW 15.05.2007. VPN Dokumentation. Erstellt von: Jens Nintemann und Maik Straub

1 Praktikum Protokolle SS2007 Fachhochschule OOW 15.05.2007. VPN Dokumentation. Erstellt von: Jens Nintemann und Maik Straub 1 Praktikum Protokolle SS2007 Fachhochschule OOW VPN Dokumentation 1 2 Praktikum Protokolle SS2007 Fachhochschule OOW Inhaltsverzeichnis Thema Seite 1. Einleitung 3 2. Unsere Aufbaustruktur 3 3. Installation

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Stephan Hansen-Oest Rechtsanwalt. erstellt von: Sachverständiger für IT-Produkte (rechtlich)

Stephan Hansen-Oest Rechtsanwalt. erstellt von: Sachverständiger für IT-Produkte (rechtlich) Technisches und rechtliches Rezertifizierungs-Gutachten Einhaltung datenschutzrechtlicher Anforderungen durch das Produkt PrimeSharing Team Drive 2.1 (vormals PrimeSharing TeamDrive) der TeamDrive Systems

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Steganos Secure E-Mail Schritt für Schritt-Anleitung für den Gastzugang SCHRITT 1: AKTIVIERUNG IHRES GASTZUGANGS

Steganos Secure E-Mail Schritt für Schritt-Anleitung für den Gastzugang SCHRITT 1: AKTIVIERUNG IHRES GASTZUGANGS Steganos Secure E-Mail Schritt für Schritt-Anleitung für den Gastzugang EINLEITUNG Obwohl inzwischen immer mehr PC-Nutzer wissen, dass eine E-Mail so leicht mitzulesen ist wie eine Postkarte, wird die

Mehr

Authentication Header: Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen

Authentication Header: Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen IP Security Zwei Mechanismen: Authentication : Nur Datenauth. (Exportbeschränkungen) Empfehlung: Nicht mehr umsetzen Encapsulating Security Payloads (ESP): Verschl., Datenauth. Internet Key Exchange Protokoll:

Mehr

Datenschutzinformation. 1. Angaben, die Sie im Rahmen der Registrierung oder des Bewerbungsprozesses als Assembly-Gastgeber

Datenschutzinformation. 1. Angaben, die Sie im Rahmen der Registrierung oder des Bewerbungsprozesses als Assembly-Gastgeber Datenschutzinformation Ihre Daten sind bei uns in guten Händen. Im Folgenden informieren wir Sie darüber, welche personenbezogenen Daten wir (die EQUANUM GmbH als Betreiberin der Food-Assembly Webseite)

Mehr

1. Interface. Wireshark (Ehtereal)

1. Interface. Wireshark (Ehtereal) Wireshark (Ehtereal) Das Programm Wireshark Network Protocol Analyzer dient dazu, wie der Name schon sagt, ersichtlich zu machen, welche Datenpakete die Netzwerkkarte empfängt bzw. sendet. In Form von

Mehr

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen

Verteilte Systeme. 10.1 Unsicherheit in Verteilten Systemen Verteilte Systeme Übung 10 Jens Müller-Iden Gruppe PVS (Parallele und Verteilte Systeme) Institut für Informatik Westfälische Wilhelms-Universität Münster Sommersemester 2007 10.1 Unsicherheit in Verteilten

Mehr

Datenschutzerklärung der Ypsilon.Net AG

Datenschutzerklärung der Ypsilon.Net AG Datenschutzerklärung der Ypsilon.Net AG Die Ypsilon.Net AG wird den Anforderungen des Bundesdatenschutzgesetzes (BDSG) gerecht. Personenbezogene Daten, d.h Angaben, mittels derer eine natürliche Person

Mehr

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen ewon - Technical Note Nr. 005 Version 1.3 Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen 08.08.2006/SI Übersicht: 1. Thema 2. Benötigte Komponenten

Mehr

Datenschutzerklärung für RENA Internet-Auftritt

Datenschutzerklärung für RENA Internet-Auftritt Datenschutzerklärung für RENA Internet-Auftritt Vielen Dank für Ihr Interesse an unserem Internetauftritt und unserem Unternehmen. Wir legen großen Wert auf den Schutz Ihrer Daten und die Wahrung Ihrer

Mehr

Google Analytics. - datenschutzrechtliche Betrachtung -

Google Analytics. - datenschutzrechtliche Betrachtung - Google Analytics - datenschutzrechtliche Betrachtung - 1 Agenda Terms & Conditions Datenschutzhinweise Google Analytics Allgemeine Datenschutzhinweise von Google Regelungssachverhalte: Cookies Nutzungsprofile

Mehr

Java Anon Proxy Hilfe

Java Anon Proxy Hilfe Java Anon Proxy Hilfe Willkommen zur Java Anon Proxy Hilfe. Bitte wählen ein Thema. Benötigen Sie Hilfe für Ihre ersten Konfigurationsschritte, klicken Sie bitte: Erste Schritte Themen Über Java Anon Proxy

Mehr

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo

Kryptographische Verfahren. zur Datenübertragung im Internet. Patrick Schmid, Martin Sommer, Elvis Corbo Kryptographische Verfahren zur Datenübertragung im Internet Patrick Schmid, Martin Sommer, Elvis Corbo 1. Einführung Übersicht Grundlagen Verschlüsselungsarten Symmetrisch DES, AES Asymmetrisch RSA Hybrid

Mehr

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software

Übersicht. Was ist FTP? Übertragungsmodi. Sicherheit. Öffentliche FTP-Server. FTP-Software FTP Übersicht Was ist FTP? Übertragungsmodi Sicherheit Öffentliche FTP-Server FTP-Software Was ist FTP? Protokoll zur Dateiübertragung Auf Schicht 7 Verwendet TCP, meist Port 21, 20 1972 spezifiziert Übertragungsmodi

Mehr

White Paper. Datenschutz für den Betrieb von WLAN-Hotspots Die VPN-Routing-Lösung von HOTSPLOTS. Stand: Mai 2012

White Paper. Datenschutz für den Betrieb von WLAN-Hotspots Die VPN-Routing-Lösung von HOTSPLOTS. Stand: Mai 2012 White Paper Datenschutz für den Betrieb von WLAN-Hotspots Die VPN-Routing-Lösung von HOTSPLOTS Stand: Mai 2012 hotsplots GmbH Dr. Ulrich Meier, Dr. Jörg Ontrup Rotherstr. 17 10245 Berlin E-Mail: info@hotsplots.de

Mehr

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden Vorwort In unserem elektronischen Zeitalter erfolgt der Austausch von Informationen mehr und mehr über elektronische Medien wie zum Beispiel

Mehr

II. Zweckbestimmung der Datenerhebung, -verarbeitung oder nutzung

II. Zweckbestimmung der Datenerhebung, -verarbeitung oder nutzung Öffentliches Verfahrensverzeichnis der IMMAC Holding AG Das Bundesdatenschutzgesetz (BDSG) schreibt im 4g vor, dass der Beauftragte für den Datenschutz jedermann in geeigneter Weise die Angaben entsprechend

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Kapitel 6 Internet 1

Kapitel 6 Internet 1 Kapitel 6 Internet 1 Kapitel 6 Internet 1. Geschichte des Internets 2. Datenübertragung mit TCP/IP 3. Internetadressen 4. Dynamische Zuteilung von Internetadressen 5. Domain-Namen 6. Internetdienste 2

Mehr

Datenschutzerklärung der Vinosent GbR

Datenschutzerklärung der Vinosent GbR Erklärung zum Datenschutz Wir, die Vinosent GbR, freuen uns über Ihren Besuch auf unserer Internetseite und Ihrem Interesse an unserem Unternehmen. Der Schutz Ihrer personenbezogenen Daten ist uns ein

Mehr

Anonym und werbefrei im Web surfen

Anonym und werbefrei im Web surfen Features, Hacks, Gadgets: Teil 1 Dieser Artikel ist ein Teil des Extra-Kapitels»Features, Hacks, Gadgets«aus dem»praxisbuch Mac OS X Tiger«. Das Kapitel wurde in einzelne Artikel aufgeteilt, die in sich

Mehr

Collax Business Server NCP Secure Entry Client Interoperability Guide V. 1.3. Collax Business Server (V. 3.0.12) NCP Secure Entry Client 8.

Collax Business Server NCP Secure Entry Client Interoperability Guide V. 1.3. Collax Business Server (V. 3.0.12) NCP Secure Entry Client 8. Collax Business Server NCP Secure Entry Client Interoperability Guide V. 1.3 Collax Business Server (V. 3.0.12) NCP Secure Entry Client 8.21 Dies ist eine Anleitung, die die Konfigurationsschritte beschreibt,

Mehr

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen Gliederung 1. Was ist Wireshark? 2. Wie arbeitet Wireshark? 3. User Interface 4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen 1 1. Was

Mehr

VPN Virtual Private Network

VPN Virtual Private Network VPN Virtual Private Network LF10 - Betreuen von IT-Systemen Marc Schubert FI05a - BBS1 Mainz Lernfeld 10 Betreuen von IT-Systemen VPN Virtual Private Network Marc Schubert FI05a - BBS1 Mainz Lernfeld 10

Mehr

VIRTUAL PRIVATE NETWORKS

VIRTUAL PRIVATE NETWORKS VIRTUAL PRIVATE NETWORKS Seminar: Internet-Technologie Dozent: Prof. Dr. Lutz Wegner Virtual Private Networks - Agenda 1. VPN Was ist das? Definition Anforderungen Funktionsweise Anwendungsbereiche Pro

Mehr

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie

Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Aufbau eines virtuellen privaten Netzes mit Peer-to-Peer-Technologie Wolfgang Ginolas Fachhochschule Wedel 21. September 2009 Wolfgang Ginolas (Fachhochschule Wedel) 21. September 2009 1 / 14 Einleitung

Mehr

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation

Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Digitale Signaturen für Ï Signaturzertifikate für geschützte email-kommunikation Ein Großteil der heutigen Kommunikation geschieht per email. Kaum ein anderes Medium ist schneller und effizienter. Allerdings

Mehr

Verschlüsselung eines drahtlosen Netzwerkes

Verschlüsselung eines drahtlosen Netzwerkes Verschlüsselung eines drahtlosen Netzwerkes Die größte Sicherheitsgefahr eines drahtlosen Netzwerkes besteht darin, dass jeder, der sich innerhalb der Funkreichweite des Routers aufhält einen Zugriff auf

Mehr

PGP-Verschlüsselung. PGP-Verschlüsselung beim email-versand von Dateien in der Micro-Epsilon-Gruppe. Mit Abstand der bessere Weg

PGP-Verschlüsselung. PGP-Verschlüsselung beim email-versand von Dateien in der Micro-Epsilon-Gruppe. Mit Abstand der bessere Weg PGP-Verschlüsselung PGP-Verschlüsselung beim email-versand von Dateien in der Micro-Epsilon-Gruppe PGP-Verschlüsselung - Theorie Verschlüsselungsverfahren können in zwei grundsätzlich verschiedene Klassen

Mehr

Secure Socket Layer (SSL) - Zertifikate

Secure Socket Layer (SSL) - Zertifikate e Einführung Zur Übertragung sensibler Daten über das Internet wurde das SSL-Protokoll entwickelt. SSL steht für Secure Socket Layer (dt. "sichere Sockelschicht") das von der Firma Netscape und RSA Data

Mehr

Remote Tools SFTP. Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de

Remote Tools SFTP. Port X11. Proxy SSH SCP. christina.zeeh@studi.informatik.uni-stuttgart.de Proxy Remote Tools SFTP SSH X11 Port SCP christina.zeeh@studi.informatik.uni-stuttgart.de Inhalt Grundlagen SSH Remote-Login auf marvin Datentransfer Graphische Anwendungen Tunnel VPN SSH für Fortgeschrittene

Mehr

Tipps für sichere Kommunikation

Tipps für sichere Kommunikation Tipps für sichere Kommunikation 1. Verschlüssele deine Computer / Handy Windows: Truecrypt Mac OSX: FileVault 2 Linux: bei Installation Verschlüsselungsoption auswählen Android: Systemeinstellungen 2.

Mehr

Datenschutzerklärung. Datum: 16.12.2014. Version: 1.1. Datum: 16.12.2014. Version: 1.1

Datenschutzerklärung. Datum: 16.12.2014. Version: 1.1. Datum: 16.12.2014. Version: 1.1 Datenschutzerklärung Datum: 16.12.2014 Version: 1.1 Datum: 16.12.2014 Version: 1.1 Verantwortliche Stelle im Sinne des Bundesdatenschutzgesetzes ist: Deutsch-Iranische Krebshilfe e. V. Frankfurter Ring

Mehr

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt April 2011 Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt 1. Einleitung E-Mails lassen sich mit geringen Kenntnissen auf dem Weg durch die elektronischen Netze leicht mitlesen oder verändern.

Mehr

Installationsanleitung

Installationsanleitung Installationsanleitung POP3 und Bridge-Modus Inhaltsverzeichnis 1 POP3 und Bridge-Modus 2 1.1 Funktionsweise von POP3 mit REDDOXX 2 1.2 Betriebsarten 3 1.2.1 Standard-Modus 3 1.2.2 Bridge-Modus 6 1.2.3

Mehr

Homomorphe Verschlüsselung

Homomorphe Verschlüsselung Homomorphe Verschlüsselung Sophie Friedrich, Nicholas Höllermeier, Martin Schwaighofer 11. Juni 2012 Inhaltsverzeichnis Einleitung Motivation Mathematische Definitionen Wiederholung Gruppe Ring Gruppenhomomorphisums

Mehr

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse

Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Strategie zur Verfolgung einzelner IP-Pakete zur Datenflussanalyse Peter Hillmann Institut für Technische Informatik Fakultät für Informatik Peter.Hillmann@unibw.de Peter Hillmann 1 Gliederung 1. Motivation

Mehr

P2P - Sicherheit Georg Lukas 2003-12-03 Seminar "Kommunikation in P2P-Netzen"

P2P - Sicherheit Georg Lukas 2003-12-03 Seminar Kommunikation in P2P-Netzen P2P - Sicherheit Georg Lukas 2003-12-03 Seminar "Kommunikation in P2P-Netzen" Ziele des Vortrags Sicherheit auf Konzept-Ebene Kommunikationsprotokolle Datenspeicherung Resistenz gegen Störungen, Angriffe,

Mehr

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

Mehr

Benutzerhandbuch für FaxClient für HylaFAX

Benutzerhandbuch für FaxClient für HylaFAX Benutzerhandbuch für FaxClient für HylaFAX Vielen Dank, daß Sie entschlossen haben, dieses kleine Handbuch zu lesen. Es wird Sie bei der Installation und Benutzung des FaxClients für HylaFAX unterstützen.

Mehr