2008-07-03 12:19:31 +00:00
{% extends "_layout_de.html" %}
2008-07-02 21:04:03 +00:00
{% block title %}Einfü hrung in die Arbeitsweise von I2P{% endblock %}
2010-10-04 23:49:51 +00:00
{% block content %}
2010-10-11 18:18:18 +00:00
< p > Die Webseite wird gerade ü berholt und dieses Dokument kann alte Informationen enthalten< / p >
2008-07-02 21:04:03 +00:00
< p > I2P ist ein Projekt, welches ein Netzwerk zum sicheren und anonymen Kommunizieren planen, aufbauen
und betreuen wird. Nutzer von I2P haben die Kontrolle ü ber die Verteilung zwischen Anonymitä t,
Verlä sslichkeit, genutzter Bandbreite und Verzö gerung. Es gibt keinen zentralen Punkt im Netzwerk,
welcher ü bernommen werden kann um die Integritä t, Sicherheit oder Anonymitä t des Systems zu
komprimieren. Das Netzwerk kann sich in einer Reaktion auf Angriffe selber rekonfiguriern und
wurde so geplant, das es zusä tzliche Ressourcen bei deren Verfü gbarkeit nutzen wird.
Selbstverstä ndlich sind alle Aspekte des Netzwerkes offen und frei verfü gbar.< / p >
< p > Im Gegensatz zu vielen anderen anonymen Netzwerken versucht I2P nicht die Anonymitä t durch
verstecken eines Teils einer Kommunikation, der Sender oder der Empfä nger, herzustellen. I2P
wurde so geplant, das Nutzer von I2P untereinander anonym kommunizieren kö nnen - Sender und
Empfä nger sind fü r den jeweils anderen anonym als auch fü r nicht beteiligte dritte. Zum Beispiel
gibt es zur Zeit I2P interne Webseiten (die anonymes Publizieren/hosten erlauben) und einen
HTTP Proxy in das normale Internet (der anonymes Browsing bietet). Server im I2P Netz betreiben
zu kö nnen ist eine essentielle Angelegenheit, da angenommen werden kann, das die Proxis ins
normale Internet ü berwacht werden, abgeschaltet werden oder gar zu schlimmeren Angriffen genutzt
werden.< / p >
< p > Das Netzwerk selber ist Nachrichten basiert - es ist essentiell eine sichere und anonyme IP Schicht,
in der Nachrichten an kryptographische Schlü ssel (Ziele) geschickt werden;die Nachrichten selber
kö nnen signifikant grö sser als IP Pakete werden. Beispiele fü r die Nutzung des Netzwerkes sind
unter anderem "Eepsites" (Webserver mit normalen Webapplikationen innerhalb von I2P), ein
< a href = "http://bitconjurer.org/BitTorrent/" > BitTorrent< / a > Klient ("I2Psnark") oder ein verteilter
Datencontainer. Mit der Hilfe von mihis < a href = "i2ptunnel" > I2PTunnel< / a >
Applikation kö nnen wir die ü blichen TCP/IP Anwendungen ü ber I2P tunneln, z.B. SSH, IRC, ein squid
Proxy oder gar Audio. Viele Leute werden I2P nicht direkt nutzen oder nicht bemerken, das sie I2P
nutzen. Stattdessen sehen sie nur eine der I2P fä higen Anwendungen oder nur eine Einstellung fü r
verschiedene Proxies, die ihnen Anonyme Verbindungen anbieten.< / p >
< p > Ein wichtiger Teil des Planens, Entwickelns und Testens eines anonymen Netzwerkes ist das
Definieren des < a href = "how_threatmodel" > Angriffsszenarios< / a > , da es "echte" Anonymitä t nicht gibt,
nur steigende Kosten und
Aufwand jemanden zu identifizieren. Kurz gesagt: I2P Absicht ist es, Personen in willkü rlichen
feindseligen Umgebungen einen militä rischen Grad der Anonymitä t zu bieten, versteckt in dem
hinreichendem Datenstrom aus der Aktivitä t anderer Leute, die weniger Anonymitä t benö tigen.
Dieses beinhaltet den Chat von Joe Sixpack mit seinen Freuden, den niemanden mitlesen kann,
Jane Filesharer, die weiß das die grossen Konzerne sie beim Tauschen von Dateien nicht
identifizieren kö nnen, als auch Will Geheimnisverrä ter, der geheime Dokumente verö ffentlicht -
< i > alles in dem selben Netzwerk< / i > , in dem eine Nachricht nicht von einer anderen unterschieden werden
kann.< / p >
< h2 > Warum?< / h2 >
< p > Es existieren eine unglaubliche Anzahl an fantastischen Grü nden, weswegen wir ein System zum
anonymen Kommunizieren benö tigen und jeder hat seine eigenen persö nlichen rationalen Grü nde.
Es gibt viele < a href = "how_networkcomparisons" > andere Bestrebungen< / a > , die auf dem einem oder anderen Weg
unterschiedliche
Arten der Anonymitä t im Internet zu erreichen versuchen, aber wir fanden keine, die unsere
Anforderungen oder unser Angriffszenario abdeckten.< / p >
< h2 > Wie?< / h2 >
< p > In einer ü bersicht existiert das Netzwerk aus einer Gruppe von Knoten ("Router") mit einer
Anzahl an unidirektionalen virtueller Eingangs und Ausgangs Wege ("Tunnel", wie in der
< a href = "how_tunnelrouting" > Tunnel Routing< / a > Seite beschrieben). Jeder Router wird duch eine kryptographische RouterIdentity
eindeutig indentifiziert, diese ist fü r gewö hnlich dauerhaft gü ltig. Diese Router kommunizieren
ü ber vorhandene Transportmechanosmen (TCP, UDP, etc.) und tauschen verschiedene Nachrichten aus.
Klientprogramme haben ihre eigenen kryptographischen Ident ("Destination"), durch den sie
zum Senden und Empfangen von Nachrichten befä higt sind. Diese Klienten kö nnen zu irgendwelchen
Routern Verbindung aufnehmen und authorisieren ihre derzeitige Belegung ("lease") von ein paar
Tunneln, die zum Senden und Empfangen von Nachrichten durch das Netzwerk benutzt werden. I2P
hat eine eigene < a href = "how_networkdatabase" > Netzwerk Datenbank< / a > ("Floodfill") zum skalierbaren sicherem Verteilen von Routing
und Kontaktinformationen.< / p >
2009-06-03 04:01:11 +00:00
< p > < center > < div class = "box" > < img src = "_static/images/net.png" alt = "Network topology example" title = "Network topology example" / > < / div > < / center > < / p > < br >
2008-07-02 21:04:03 +00:00
< p > Im oberen Bild betreiben Alice, Bob, Charlie und Dave je einen Router mit einer einzigen
Destination auf ihren lokalen Router. Sie haben alle ein paar 2-Hop Eingangstunnel je
Destination (mit 1,2,3,4,5 und 6 bezeichnet) und ein paar haben 2-Hop Ausgangstunnel.
Zur Vereinfachung sind Charlies Eingangstunnel und Daves Ausgangstunnel nicht eingezeichnet,
ebenso wie weitere Ausgangstunnel der Router (normalerweise so 5-10 Tunnel gleichzeitig).
Sobald Alice und Bob miteiander reden, sendet Alice eine Nachricht ü ber ihren (pinken)
Ausgangstunnel in Richtung eines vons Bobs Eingangstunneln (grü n, Tunnel 3 oder 4). Sie lernt
den Eingangstunnel durch eine Abfrage der Netzwerk Datenbank kennen, diese Datenbank wird
dauerhaft aktualisiert sobald neue Leases authorisiert sind und ä ltere auslaufen.< / p >
< p > Antwortet Bob nun Alice, geschieht dieses auf der selben Art und Weise - er sendet eine Nachricht
ü ber einen seiner Ausgangstunnel in Richtung eines von Alice Eingangstunnels (Tunnel 1 oder 2).
Um vieles einfacher zu machen, sind viele Nachrichten zwischen Bob und Alice in sogenannte
"< a href = "how_garlicrouting" > Garlics< / a > " eingepackt, in denen die Lease Information vom Sender enthalten ist, so das der
Empfä nger sofort antworten kann ohne in der Netzwerk Datenbank nach den benö tigten Informationen
suchen zu mü ssen.< / p >
< p > Um einigen Attacken aus dem Wege zu gehen ist I2P dezentral aufgebaut, ohne eine zentrale Instanz -
und wie schon richtig geraten existiert kein zentraler Verzeichnisdienst, der Informationen
zur Performance und Kontinuitä t der Router im Netzwerk verwaltet. Daraus folgt, daßjeder Router
eigene Profile verschiedener Router halten und pflegen muss. Ebenso ist jeder Router selber
verantwortlich fü r die Auswahl der korrekten Knoten um die Anforderungen an die Anonymitä t,
Performance und Konitnuitä t des Benutzers zu erfü llen, so wie es in der "
< a href = "how_peerselection" > Knoten Auswahl< / a > " Seite beschrieben ist.< / p >
< p > Das Netzwerk selber nutzt eine signifikante Anzahl von Kryptographischen Techniken und Algorhytmen -
die Liste umfä sst 2048bit ElGamal Verschlü sselung, 256bit AES im CBC Modus mit PKCS#5 Padding,
1024bit DSA Signaturen, SHA256 Hashes, 2048bit Diffie-Hellmann vermittelte Verbindungen mit
Station-zu-Station Authentifizierung und < a href = "how_elgamalaes" > ElGamal / AES+SessionTag< / a > .< / p >
< p > Daten die ü ber I2P gesendet werden, durchlaufen 3 Verschlü sselungen: garlic Verschlü sselung (zur
ü berprü fung ob die Nachrichten beim Empfä nger angekommen ist), Tunnel Verschlü sselung (alle
Nachrichten, die durch einen Tunnel gehen, sind vom Tunnel Gateway bis zum Tunnel Endpunkt
verschlü sselt) und Zwischen-den-Routern-Transport-Schicht Verschlü sselung (z.B. benutzt der TCP
Transport AES256 mit Ephemeral Schlü ssel).< / p >
2009-05-04 19:51:08 +00:00
< p > Ende-zu-Ende (I2CP) Verschlü sselung (von Programm zu Programm) wurde in der I2P Version 0.6 deaktiviert;
Ende-zu-Ende (garlic) Verschlü sselung von Alice Router "a" zu Bobs Router "h" existiert weiterhin.
Bitte beachte im foglendem Bild den anderen Gebrauch der Wö rter! a und h sind die I2P Router mit
der Ende-zu-Ende Verschlü sselung von Router zu Router, Alice und Bob hingegen sind die Programme
die mittels(unverschlü sseltem) I2CP mit den I2P Routern kommunizieren! Sprich: bis zum I2P Router
sind die Daten unverschlü sselt, ab dem I2P Router ist alles Ende-zu-Ende verschlü sselt.< / p >
2008-07-02 21:04:03 +00:00
2009-06-03 04:01:11 +00:00
< center > < div class = "box" > < img src = "_static/images/endToEndEncryption.png" alt = "End to end layered encryption" title = "End to end layered encryption." / > < / div > < / center > < br >
2008-07-02 21:04:03 +00:00
< p > Die genaue Anwendung dieser Algorhytmen sind < a href = "how_cryptography" > woanders< / a > beschrieben.< / p >
< p > Die zwei Hauptbestandteile fü r den militä rischen Grad der Anonymitä t sind explizite, verzö gerte
garlic geroutete Nachrichten und mehr umfassende Tunnel mit Unterstü tzung von Pooling und Mixen
von Nachrichten. Diese Funktionen sind zur Zeit fü r Version 3.0 geplant, aber garlic geroutete
Nachrichten mit keiner Verzö gerung und FIFO Tunnels sind schon implementiert. Zusä tzlich wird
die Version 2.0 den Leuten erlauben, I2P hinter beschrä nkten Routen (mö glicherweise mit vertrauten
Knoten) aufzusetzen und zu betreiben; ebenso werden die flexiblere und anonymere Transports
eingebaut werden.< / p >
< p > Es kamen ein paar berechtigte Fragen bezü glich der Skalierbarkeit von I2P auf. Mit der Zeit werden
sicher detailiertere Analysen kommen, aber Knoten suchen und Integration sollte mit O(log(N))
Komplexitä t eingehen, wä hrend Ende-zu-Ende Nachrichten mit O(1) (frei skalierend) eingehen, da
Nachrichten durch K Hops im Ausgangstunnel und durch weitere K Hops im Eingangstunnel gehen -
die Grö sse des Netzwerkes (N) hat hier keinen Einfluss.< / p >
< h2 > Wann?< / h2 >
< p > I2P startete im Februar 2003 als eine vorgeschlagene Modifizierung zu < a href = "http://freenetproject.org" > Freenet< / a > , damit dieses
alternative Transports, wie z.B. < a href = "http://java.sun.com/products/jms/index.jsp" > JMS< / a > , nutzen kö nne. Dann wuchs es in ein eigenes
'anonCommFramework' im April 2003, worauf es im July zu I2P wurde. Ersten Quelltext gab es im
August 2003, Version 0.2 folgte im September, 0.3 in Mä rz 2004, 0.4 im September 2004, 0.5
wurde Anfang 2005 verö ffentlicht, gefolgt von Version 0.6 Mitte 2005. I2P folgt in der
Entwicklung der derzeitigen < a href = "roadmap" > Roadmap< / a > .< / p >
< p > Das Netzwerk selber ist noch nicht fertig zum allgemeinem Nutzen und sollte nicht von Leuten
mit Bedarf an Anonymitä t genutzt werden bevor es nicht ausfü hrlichen ü berprü fungen stand
gehalten halt.< / p >
< h2 > Wer?< / h2 >
< p > Wir sind ein kleines < a href = "team" > Team< / a > aus merhren Lä ndern aus verschiedenen Kontinenten, das an der
Weiterentwicklung von einzelnen Aspekten des Projektes arbeitet. Wir sind offen fü r weitere
Entwickler, die sich einbringen wollen und auch gegenü ber jedem anderen, der etwas zum
Projekt beibringen kann, sei es Kritiken, Peer Review, Testen, schreiben neuer I2P
kompatibler Anwendungen oder aber auch Dokumentationen. Das gesamte System ist Open Source -
Der Router und ein Großeil des SDK sind zur Gä nze Public Domain mit ein wenig BSD und
Cryptix Lizensiertem Code, wohingegen einige Anwendungen wie I2PTunnel und I2PSnark
GPL lizensiert sind.
Fast alles ist in Java (1.3+/1.5+) geschrieben, einige externe Anwendungen sind jedoch in
Python geschrieben. Der Code arbeitet im aktuellen Kaffee und wir hoffen ihn mö glichst bald
auf < a href = "http://gcc.gnu.org/java/" > GCJ< / a > lauffä hig zu bekommen.< / p >
< h2 > Wo?< / h2 >
< p > Jeder mit Interesse an I2P sollte uns im #I2P IRC Raum (gehostet auf irc.freenode.net,
irc.postman.i2p und irc.freshcoffee.i2p) besuchen. Es gibt zur Zeit keine fest geplanten
Entwicklertreffen, dennoch existiert ein < a href = "meetings" > Archiv< / a > von abgehaltenen Entwickler Treffen.< / p >
< p > Der aktuelle Quelltext ist in < a href = "monotone.html" > Monotone< / a > verfü gbar.< / p >
{% endblock %}
