I2P: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
No edit summary
Line 92: Line 92:


=== Ablauf Tunnel-Aufbau ===
=== Ablauf Tunnel-Aufbau ===

# Potentielle Peers suchen (RouterInfo aus netDB)
# Peers zum Tunnelaufbau auswählen
# Tunnelpfad aus gewählten Peers erstellen
# "Build Tunnel"-Nachricht an Peer #1 senden
# 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 ==
== Sicherheit und Anonymität ==

* 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 ===
=== 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 ===
=== 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 ==
== 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 ==
== 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 ==

* [http://www.i2p2.de I2P-Webseite]
* [http://hal.inria.fr/docs/00/63/22/59/PDF/TMA2012-LNCS.pdf Monitoring the I2P Network], Juan Pablo Timpanaro, Isabella Chrisment, Olivier Festor, INRIA Nancy-Grand Est, France. 13. Oktober 2011
* [http://torstatus.all.de Tor-Status]

Revision as of 09:57, 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

  • 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