The Invisible Internet Project

Andrew Savchenko, Moscow, Russian Federation

LVEE 2017

This talk discusses why I2P network is needed, provides an insight on how the I2P network works, how it is different from Tor. Some use cases and safety tips will be discussed.

Introduction

The internet was created as a military DARPA project with security model oriented on external threat like infrastructure destruction. But its stack was not designed to withstand internal threats like IP spoofing or malicious routes injections, or to provide any kind on anonymity.

BPG hijacking cases are quite often these days¹, providers can easily spoof IP addresses or DNS names, http traffic is not secure and even https may be hijacked by bogus or broken CA providers. Search engines, markets, providers and other parties are actively collecting private user data.

To remedy this problems the Tor network was created. While it is a great achievement and compensates aforementioned problems up to a large extent, it is not perfect as any pioneer solution and was already compromised by the powerful adversaries². The main Tor drawbacks are:

highly centralized architecture
most users use entry points and most resources are accessible using exit nodes, so endpoints are not protected from monitoring and spoofing
just 1 hop between entry and exit points, this simplifies statistical analysis

To remedy these problems the second generation of overlay networks was created: the I2P (Invisible Internet project).

How I2P works

I2P and Tor have somewhat different goals: Tor is focused on providing an anonymous access to the Internet resources, while providing hidden services as an additional byproduct. I2P is focused on hidden services only, the network itself does not provide any entrance or exit points to the clear net; of course it is always possible to setup gateways both ways on individual machines.

In I2P each node, every client or server are the network routers by design. Routes in I2P are unidirectional, so request and replies are travelling different paths. Furthermore I2P does not use onion routing scheme like in Tor, instead it uses the garlic routing³: it is a multi-layered encryption scheme:

each transmitted packet is being encrypted and split into chunks which are send via different tunnels
each chunk is mixed with random chunks from transit traffic to form a new packet
between routers P2P encryption is used the same way as in onion scheme
number of hops is not limited and may be changed run-time depending on application needs (usually 2-3 hops are used)
multiple different unidirectional tunnels are being used to send and receive data

This way even if adversary will be able to break router-to-router decryption only chunks of random encrypted packets will be available.

All I2P peers are addressed by 516-byte (or longer) keys containing 256 bytes of public key and 128 bytes of signature. For convenience each address can be shortened to 32 bytes using SHA-256 hash, these addresses are known as b32.i2p. The tunnels for these addresses are available using DHT. This way it is not possible to spoof peer’s address like it can be done in IP network and with much more effort in Tor network, since Tor uses now insecure SHA-1 for that purposes. Only private key holder can decrypt assembled packet.

There is not DNS service in I2P. Address books are used instead and can be fetched from multiple sources, they are just maps between shorter names and b32 addresses and contain full public key for each b32. Of course each host is reachable using b32 address as well. This way is resilient to an attack on centralized directories like in case of root DNS servers or Tor directory services, because there are not directory servers in I2P.

I2P supports number of access protocols, SOCKS is the most commonly used one. Any user can easily setup a unique b32 address for each services available from his host, any TCP or UDP port may be exported.

Implementations

There are two implementations of I2P available, both are the free software. Original implementation⁴ is written in Java.

Due to Java shortcomings in both performance and memory consumption an alternative i2pd[5,6] implementation in C++ was created, allowing to run I2P daemon even on Raspberri Pi class devices⁷.

I2pd is fully compatible with Java I2P, but provides an additional feature of optionally using GOST 34.10 signing with both CryptoPro and TC26 parameter sets and GOST 34.11 hashing⁸. Considering the open nature of TC26 parameter set and fully open algorithms this provides a very good level of data protection, at least from NSA and alike adversaries.

Usage hints

Start your experience from any I2P wiki and/or identity service.

Aside from using http resources there is an interesting application in building your own VPN, since I2P works well behind NAT: just export your own services, you may use b32 white listing for clients as well. Since it is impossible to find unpublished b32 except using full address space brute force, you will have additional privacy.

Even if I2P network may be considered secure itself, do not forget that incautious user will easily lose anonymity and privacy by advanced fingerprinting, so: