Vokabeltest: Wichtige Wörter

Das führt direkt zum nächsten Problem: Wenn zwar Sender und Empfänger anonym über ihre zufällig gesetzten Gateways kommunizieren können, wie findet dann das eigene ausgehende Gateway überhaupt den Eingang zum gewünschten Router? Die Lösung ist so genial wie komplex: Im I2P-Netz gibt es eine dezentrale Datenbank namens netDb, die von allen beteiligten Routern mit Informationen gefüttert wird und sich ständig aktualisiert. Die dort gesammelten Metadaten teilen sich in die Kategorien routerInfo und leaseSet auf.

Möchte ein Nutzer sich beziehungsweise einen angebotenen Dienst im I2P-Netz bekannt machen, sendet er bei jeder eigenen Anfrage automatisch einen öffentlichen Schlüssel an die routerInfo zur netDb. Solche Dienste werden als Destinations bezeichnet und können über die öffentlichen Schlüssel angesteuert werden. Damit wissen die Interessenten jetzt bildlich gesprochen zwar, mit welchem Schlüssel sie die Tür aufbekommen - sie wissen aber noch nicht, welche Tür geöffnet werden muss, um den Kontakt herstellen zu können.

Tunnel und Gateways einiger Teilnehmer von I2P als Schema dargestellt (Quelle: i2p.net, Klick vergrößert).

Hier tritt das leaseSet auf den Plan: Jedes einzelne lease ordnet nämlich einer Destination einen ganz bestimmten Tunnel mit passendem eingehenden Gateway zu. Diese Information wird ebenso in der netDb gespeichert wie der Zeitpunkt, an dem die Gültigkeit des Tunnels wieder abläuft. Wo die routerInfo also den Schlüssel bereitstellt, weist ein lease den Weg zur richtigen Tür. Nach durchschnittlich zehn Minuten führt die Tür allerdings aus Sicherheitsgründen ins Leere und ein neuer Tunnel über ein anderes Gateway wird aufgebaut.

Bei jeder Kontaktaufnahme werden mehrere leases zu einem leaseSet zusammengefasst und verschlüsselt per ausgehendem Tunnel über das Gateway an die netDb verschickt. So wird zum einen verschleiert, welcher der gesendeten leases zum angebotenen Dienst führt, die Verschlüsselung sorgt zum anderen dafür, dass die als Zwischenknoten benutzten Router nicht "mitlesen" können, welchen Inhalt das leaseSet hat. Um nicht für jeden einzelnen Dienst im I2P-Netz wiederholt die Destination neu suchen zu müssen, werden alle einmal empfangenen öffentlichen Schlüssel in der hosts.txt im Installationsverzeichnis der I2P-Software gespeichert. Der Schlüsselbund wächst also stetig, nur die richtigen Türen müssen jedesmal erfragt werden.

Verschlüsselte Verwirrspiele mit System

Was bringt also zusammengefasst dieses komplexe Geflecht aus Schlüsseln, Tunneln und Türen? Nutzer des I2P-Netzes können unter Zuhilfenahme der netDb anderen Teilnehmern Destinations in Form von Websites oder Diensten zur Verfügung stellen, ohne ihren Schutz des anonymisierenden Gateways aufgeben zu müssen. Um beim vorherigen Beispiel zu bleiben: User geben ihren Marionetten (Gateways) den Auftrag, einen Türschlüssel öffentlich zu hinterlegen. Und in regelmäßigen Abständen gibt die Puppe bekannt, auf welche Tür der Schlüssel wie lange passt (steht im leaseSet). Auch der potenzielle Besucher bleibt unerkannt, denn er schickt seinerseits die Marionette los, um neue Schlüssel abzuholen und die richtigen Eingänge zu erfahren.