I2P: Difference between revisions

From
Jump to navigation Jump to search
Line 103: Line 103:
==== Garlic Routing ====
==== Garlic Routing ====


[[File:EndToEndEncryption.png]]
[[File:OnionRouting.png]]


* Erweiterung des Onion-Routings
* Erweiterung des Onion-Routings

Revision as of 10:20, 9 April 2013

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

OnionRouting.png

  • 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