July 2, 2014 at 05:17Building your own communications network on top of I2P
With modern trends aimed at total listening and collecting all kinds of information, the use of secure means of communication is more relevant than ever. Encryption of the transmitted data themselves solves the problem only partially, since the fact of the exchange of information between participants is more important than its content.
In most modern systems, whether it is e-mail, ICQ or twitter, the server owner has all this data and can, if necessary, share it upon receipt of an official or unofficial request about it. Below is a project of a network built on top of I2P, in which the owner uses his nodes only to ensure more stable operation and as gateways to the regular Internet, having no more information than ordinary I2P nodes.
Consider the mechanisms for ensuring the anonymity and confidentiality of I2P, which we will rely on to build our network:
Previously , it was shown that in fact I2P is a two-level design: a router that provides interaction with other routers and tunnels, and protocols designed to transfer data between applications. If the protocols for the router seem to be carefully thought out and effective, then the application protocols leave much to be desired and are a heap of various concepts and ideas, due to the desire to make them as versatile and transparent as possible for existing applications. In our case, the task is greatly simplified, since we assume an exchange between our customers, therefore we can use our own protocol.
Another I2P problem is that when I try to access the address, an error “address not found” occurs, although the resource with the specified address is currently online. This happens due to the incompleteness of the network database, for example, immediately after the start, when information about many routers becomes outdated and it takes time to update it. And since the addresses publish their LeaseSets on the "closest" floodfills, the client may still not have the necessary floodfills in the database. Our clients will use a second network database containing a set of nodes corresponding to our servers and publish their LeaseSets only on these nodes, which will allow finding LeaseSets of each other immediately.
Each I2P node is identified by an I2P address, which is 2 pairs of public and private keys generated at the time the node was created randomly, without any correlation with the IP address or location. There is no central source of addresses, it is assumed that the probability of coincidence of two randomly generated addresses is negligible. The owner of the node is the one who has a file with a full set of keys. Two public keys and a 3-byte certificate (currently always zero) form a 387-byte node identifier, by which the node becomes known in I2P. Since the full 387-byte identifier is rather inefficient for comparing, sorting and transferring data, a 32-byte SHA-256 hash from the identifier is used to designate the node, which we use to identify the client. Since the address contains a signature key, it will be difficult for an attacker to impersonate another client, this is equivalent to selecting such a key pair, the hash from which will correspond to this identifier. If necessary, the client can confirm that it is he who is hiding behind the I2P address by signing a document with his key.
So, our network will consist of the clients of our network launched on computers and the servers belonging to us. Both clients and servers are full-fledged I2P routers, while the servers are declared high-speed and are primarily designed to allow transit traffic, while clients mainly use their own tunnels, and transit traffic to mask their activity. Information about servers is public and known to clients, at the same time, servers do not know anything about clients and are not able to distinguish clients from ordinary I2P nodes. Clients will choose nodes for the tunnels so that the tunnel has exactly one server, and the remaining nodes belong to other participants in regular I2P. Even if all our servers are under the control of an attacker, then one node will not be enough, to identify the other end of the standard I2P 3-step tunnel. The user will always have the opportunity to see the routes of the tunnels, as well as exclude suspicious nodes.
On the other hand, one of our servers in a tunnel is necessary to increase the reliability of tunnels by early detection of tunnels that have stopped working. This is one of the fundamental problems of I2P: if the node agreed to participate in the transit tunnel and then stopped working (for example, the user stopped it), the creator of the tunnel does not know anything about this and continues to use the idle tunnel for a long time. Unlike regular I2P, our clients will actively send test messages to the tunnel, and as soon as our server detects that there is no traffic in the tunnel, it will publish a notification for clients, thereby allowing the client to stop using such a tunnel immediately.
To exchange data between our customers, I2NP type 20 - Data message containing arbitrary data can be used, or type 11 - Garlic message. Initially, the following exchange scheme between addresses was supposed in I2P: the LeaseSet of the addressee should be requested, then a message of the Garlic type should be generated, indicating the address as the destination, encrypt it with the public encryption key from the LeaseSet and send to the appropriate tunnel. Having received such a message, the router decrypted it and then determined to whom the message was intended. But in this case, the encryption key had to be the same for all addresses sitting on this router, which created a big security hole, therefore, in the modern I2P implementation, each address has its own set of incoming tunnels and the encryption key, accordingly, the router can determine the address without a “garlic” message. Having abandoned the use of “garlic” encryption, we get rid of another bulky I2P design - AES / ElGamal engine, and we can use encryption that is more effective for our tasks, while sending messages of type 11 to make our traffic indistinguishable from regular I2P.
Clients can exchange mail both among themselves within the network, and with external recipients. In the first case, I2P addresses are used directly, and messages are sent through tunnels from the LeaseSet addressee. If the client cannot find LeaseSet with this address, it will continue to do so for a certain time, after which it will generate a message about the impossibility of delivery.
In the second case, the client should use one of our servers as an outgoing SMTP server. Each of our servers will have its own address, and the client’s address will correspond to the user name assigned by the server, together forming a valid mail address. If the client wants to send an e-mail message outside the network, he must find the LeaseSet server (and he will certainly find it), after which the server recognizes the message as a mail and sends it to the addressee as a regular SMTP server. The recipient will only know the addresses of our SMTP server, and even if someone wants to find out from us who is hiding behind this or that address, the maximum that we tell is the I2P address, and whose address is still unknown to us. If the server receives the message from outside,
In order to combat spam, we will introduce restrictions on the number of messages sent from each I2P address. In order for the address to be able to send messages outside, it will have to register on the server and find out its name, at the same time we will require a certificate from it, obtained as a result of some resource-intensive computational task, thereby complicating the mass generation of addresses, while not creating problems for those who you only need one or more addresses.
Thus, we get a network that, on the one hand, ensures the anonymity and confidentiality of the information transmitted, the disclosure of which is impossible without access to the client’s computer, and on the other hand, maintains a high level of trust between clients using cryptographic identification tools. Using your own protocol and only it between clients can significantly simplify the implementation and increase the reliability of the network, the appearance of new high-speed routers will improve the performance and bandwidth of I2P itself.
I would like to hear the opinion of the respected Habr community regarding the proposed project as a whole, and first of all about potential attacks to deanonymize clients, as well as other weaknesses and vulnerabilities.
In most modern systems, whether it is e-mail, ICQ or twitter, the server owner has all this data and can, if necessary, share it upon receipt of an official or unofficial request about it. Below is a project of a network built on top of I2P, in which the owner uses his nodes only to ensure more stable operation and as gateways to the regular Internet, having no more information than ordinary I2P nodes.
Consider the mechanisms for ensuring the anonymity and confidentiality of I2P, which we will rely on to build our network:
- Each I2P participant is a router known to the rest of the network and one or more addresses that form the “invisible” network itself. The meaning of I2P lies in the practical impossibility of knowing which router this or that address is located on.
- An I2P address is a public key pair for asymmetric encryption and signature. A private key pair is stored by the owner and is a confirmation of the authenticity of the address. In other words, for authentication, instead of passwords, this file with keys is used - an analogue of an electronic digital signature can be, if necessary, implemented as a token
- Connections between routers are encrypted using AES, the session key for which is agreed in several steps, including checking the signature of the host address in order to counter man-in-the-middle attacks
Previously , it was shown that in fact I2P is a two-level design: a router that provides interaction with other routers and tunnels, and protocols designed to transfer data between applications. If the protocols for the router seem to be carefully thought out and effective, then the application protocols leave much to be desired and are a heap of various concepts and ideas, due to the desire to make them as versatile and transparent as possible for existing applications. In our case, the task is greatly simplified, since we assume an exchange between our customers, therefore we can use our own protocol.
Another I2P problem is that when I try to access the address, an error “address not found” occurs, although the resource with the specified address is currently online. This happens due to the incompleteness of the network database, for example, immediately after the start, when information about many routers becomes outdated and it takes time to update it. And since the addresses publish their LeaseSets on the "closest" floodfills, the client may still not have the necessary floodfills in the database. Our clients will use a second network database containing a set of nodes corresponding to our servers and publish their LeaseSets only on these nodes, which will allow finding LeaseSets of each other immediately.
Each I2P node is identified by an I2P address, which is 2 pairs of public and private keys generated at the time the node was created randomly, without any correlation with the IP address or location. There is no central source of addresses, it is assumed that the probability of coincidence of two randomly generated addresses is negligible. The owner of the node is the one who has a file with a full set of keys. Two public keys and a 3-byte certificate (currently always zero) form a 387-byte node identifier, by which the node becomes known in I2P. Since the full 387-byte identifier is rather inefficient for comparing, sorting and transferring data, a 32-byte SHA-256 hash from the identifier is used to designate the node, which we use to identify the client. Since the address contains a signature key, it will be difficult for an attacker to impersonate another client, this is equivalent to selecting such a key pair, the hash from which will correspond to this identifier. If necessary, the client can confirm that it is he who is hiding behind the I2P address by signing a document with his key.
So, our network will consist of the clients of our network launched on computers and the servers belonging to us. Both clients and servers are full-fledged I2P routers, while the servers are declared high-speed and are primarily designed to allow transit traffic, while clients mainly use their own tunnels, and transit traffic to mask their activity. Information about servers is public and known to clients, at the same time, servers do not know anything about clients and are not able to distinguish clients from ordinary I2P nodes. Clients will choose nodes for the tunnels so that the tunnel has exactly one server, and the remaining nodes belong to other participants in regular I2P. Even if all our servers are under the control of an attacker, then one node will not be enough, to identify the other end of the standard I2P 3-step tunnel. The user will always have the opportunity to see the routes of the tunnels, as well as exclude suspicious nodes.
On the other hand, one of our servers in a tunnel is necessary to increase the reliability of tunnels by early detection of tunnels that have stopped working. This is one of the fundamental problems of I2P: if the node agreed to participate in the transit tunnel and then stopped working (for example, the user stopped it), the creator of the tunnel does not know anything about this and continues to use the idle tunnel for a long time. Unlike regular I2P, our clients will actively send test messages to the tunnel, and as soon as our server detects that there is no traffic in the tunnel, it will publish a notification for clients, thereby allowing the client to stop using such a tunnel immediately.
To exchange data between our customers, I2NP type 20 - Data message containing arbitrary data can be used, or type 11 - Garlic message. Initially, the following exchange scheme between addresses was supposed in I2P: the LeaseSet of the addressee should be requested, then a message of the Garlic type should be generated, indicating the address as the destination, encrypt it with the public encryption key from the LeaseSet and send to the appropriate tunnel. Having received such a message, the router decrypted it and then determined to whom the message was intended. But in this case, the encryption key had to be the same for all addresses sitting on this router, which created a big security hole, therefore, in the modern I2P implementation, each address has its own set of incoming tunnels and the encryption key, accordingly, the router can determine the address without a “garlic” message. Having abandoned the use of “garlic” encryption, we get rid of another bulky I2P design - AES / ElGamal engine, and we can use encryption that is more effective for our tasks, while sending messages of type 11 to make our traffic indistinguishable from regular I2P.
Clients can exchange mail both among themselves within the network, and with external recipients. In the first case, I2P addresses are used directly, and messages are sent through tunnels from the LeaseSet addressee. If the client cannot find LeaseSet with this address, it will continue to do so for a certain time, after which it will generate a message about the impossibility of delivery.
In the second case, the client should use one of our servers as an outgoing SMTP server. Each of our servers will have its own address, and the client’s address will correspond to the user name assigned by the server, together forming a valid mail address. If the client wants to send an e-mail message outside the network, he must find the LeaseSet server (and he will certainly find it), after which the server recognizes the message as a mail and sends it to the addressee as a regular SMTP server. The recipient will only know the addresses of our SMTP server, and even if someone wants to find out from us who is hiding behind this or that address, the maximum that we tell is the I2P address, and whose address is still unknown to us. If the server receives the message from outside,
In order to combat spam, we will introduce restrictions on the number of messages sent from each I2P address. In order for the address to be able to send messages outside, it will have to register on the server and find out its name, at the same time we will require a certificate from it, obtained as a result of some resource-intensive computational task, thereby complicating the mass generation of addresses, while not creating problems for those who you only need one or more addresses.
Thus, we get a network that, on the one hand, ensures the anonymity and confidentiality of the information transmitted, the disclosure of which is impossible without access to the client’s computer, and on the other hand, maintains a high level of trust between clients using cryptographic identification tools. Using your own protocol and only it between clients can significantly simplify the implementation and increase the reliability of the network, the appearance of new high-speed routers will improve the performance and bandwidth of I2P itself.
I would like to hear the opinion of the respected Habr community regarding the proposed project as a whole, and first of all about potential attacks to deanonymize clients, as well as other weaknesses and vulnerabilities.