I2P

Informationen zum I2P Projekt

• I2P = 'Invisible Internet Project'

• 2003 gegründet
• Dezentrales, anonymisierendes Netzwerk für sichere Kommunikation
• "Community-Driver"
• Entwickler teilweise selbst anonym
• Finanziert durch Spenden

• Open Source
• Geschrieben in JAVA
• Aktuelle Version: 0.9.5 (2013-03-08)

Netzwerk

Funktionsweise

• Netzwerkschicht
• Nachrichtenbasiert (Payload + Management)

Transportprotokolle

• SSU (Secure Semireliable UDP)
• NTCP (NIO-based TCP)

Router

• Software
• Teil des Netzwerks
• Traffic-Routing

Destination

• Anonyme Endpunkte
• Kryptografische Identifier

Tunnel-Konzept

• Verbindungen zwischen zwei Routern (end-to-end) ohne Tunnel
  • Sender kann Empfänger identifizieren (z.B. IP-Adresse
  • Empfänger kann Sender identifizieren
  • Anonymität nicht gegeben!

• Verbindungen zwischen zwei Routern (end-to-end) durch Tunnel

• • Tunneln der Daten durch mehrere Router (mix network)
  • Benötigt Peers (andere Router) zum Tunnelbau

netDb

• Lokale Datenbank
• von jedem Router selbst verwaltet
• enthalten RouterInfo und LeaseSets
• für Routing nötig
• verbreitet durch DHT (Distributed Hash Tables)

RouterInfo

• Informationen zum Kontaktieren von Routern
• Von Router erstellt und verbreitet
• Nicht sensitiv, einfache Veröffentlichung möglich

• Enthaltene Daten
  • Routeridentität (2048-Bit ElGamal PublicKey, X.509-Zertifikat, ...)
  • Kontaktdaten (IP-Adresse/Domain Name, Port)
  • Zeitpunkt der Veröffentlichung (Alter der Informationen)
  • Daten zur Auslastung, Bandbreite, ...
  • ...
  • Signatur der Daten (mit 1024-Bit DSA-Key des Routers)

LeaseSets

• Informationen zum Kontaktieren eines Endpunkts (Destination)
• Von Router erstellt und verbreitet
• Sensitiv, anonyme Verbreitung erforderlich

• Enthaltene Daten:
  • Leases (Informationen zu Tunnelgateways zu einem Endpunkt)
  • Endpunktidentität (ElGamal, Zertifikati, ...)
  • ...
  • Signatur der Daten

• Daten pro Lease
  • RouterInfo des Tunnelgateways
  • Tunnel-ID auf dem Router
  • Ablaufdatum

Network Seeding

Problem:

• Wie findet man erste Peers um die lokale netDB zu füllen?

• Einzige Lösung: von Nutzern auf Webseiten veröffentlicht RouterInfos müssen von dort importiert werden

Ablauf Tunnel-Aufbau

1. Potentielle Peers suchen (RouterInfo aus netDB)
2. Peers zum Tunnelaufbau auswählen
3. Tunnelpfad aus gewählten Peers erstellen
4. "Build Tunnel"-Nachricht an Peer #1 senden
5. Peer #1 entscheidet über seine Teilnahme am Tunnel, sendet ggf. "Build Tunnel"-Nachricht an Peer #2 usw. Falls ein Peer ablehnt, wird ein anderer ausgewählt.

Sicherheit und Anonymität

Garlic Routing

• Erweiterung des Onion-Routings
• Nachricht vom Tunnel-Gateway mehrfach verschlüsselt (mit Public-Key)
• entschlüsseln jeweils einer Ebene: Nachricht und Anweisung

• Erweiterung: Mehrere "Cloves" in einer Nachricht möglich
• Clove enthält jeweils die Nachricht und eine Anweisung zum Weiterleiten

Kryptografie

• Verwendete Krypto-Algorithmen:
  • ElGamal (asymmetrische Verschlüsselung), 2048-Bit
  • AES (symmetrische Verschlüsselung), 256-Bit, CBC-Modus
  • DSA (Signatur), 1024-Bit
  • SHA256 (Hash)

• Garlic Encryption (ElGamal/SessionTag+AES), von a nach h
• Tunnel Encryption (AES), von a nach d und von e nach h
• Transport Encryption (Diffie-Hellman, AES), von a nach b, von b nach c, ..., von g nach h

Garlic Encryption (ElGamal/SessionTag+AES)

• ElGamal-Block + AES-Block
• AES-Key und Pre-Initialisierungsvektor (je 32-Byte) mit ElGamal-PublicKey verschlüsselt
• Empfänger entschlüsselt ElGamal-Block
• AES-IV = erste 16 Bytes von SHA256(Pre-IV)
• Empfänger kann nun AES-Block entschlüsseln

• AES-Block enthält Session-Tags, Payload-Hash und Payload
• Empfänger speichert Session-Tags und dazugehörigen AES-Key

• Zukünftige Nachrichten werden auf Session-Tags geprüft
• verwende nun bereits bekannten AES-Key ohne teuren ElGamal-Algorithmus

Tunnel Encryption (AES)

• AES-Key und AES-IV im Tunnel-Build-Request enthalten
• werden bis zum Verfall des Tunnels im Router gespeichert

Transport Encryption (Diffie-Hellman/AES)

• auf Transport-Ebene (NTCP, SSU Protokolle)
• AES-Key wird bei Router-zu-Router-Verbindungen mit Diffie-Hellman ausgehandelt

Angriffsvektoren

• Perfekte Anonymität nicht möglich
• Ziel: Angriffe so schwer und teuer wir möglich zu machen

• • Brute-Force
  • Timing
  • Intersection
  • Denial of Service
  • Partitioning
  • Harvesting
  • Sybil
  • Buddy Exhaustion

Vergleich zu TOR

Vorteile gegenüber TOR

• Optimiert für "Hidden Services" innerhalb des Netzwerks (Performance)
• Vollständig verteilt und selbst-organisierend
• Keine zu vertrauenden Institutionen (Directory-Server, DoS)
• Client-Verbindungen skalieren, Tunnel für alle Kommunikationspartner nutzbar
• Jeder routet Traffic für jeden
• Tunnel kurzlebig, weniger Angriffsfläche zum Daten sammeln
• TCP und UDP

Nachteile gegenüber TOR

• Wesentlich weniger Benutzer
• TOR besser erforscht, Paper, formale Studien bzgl. Performance und Anonymität
• TOR optimiert für Outproxying
• TOR besser dokumentiert
• TOR im allgemeinen bessere Performance

Fazit

• Einsatz abhängig vom Bedrohungsszenario
• für Dienste innerhalb des Netzwerkes ("Hidden Services") gut geeignet
• effektiv gegen Zensur, schwer zu blocken
• für alltägliches Surfen im www besser TOR verwenden

Links

• I2P-Webseite
• Monitoring the I2P Network, Juan Pablo Timpanaro, Isabella Chrisment, Olivier Festor, INRIA Nancy-Grand Est, France. 13. Oktober 2011
• Tor-Status