Building your own communication network over 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 solves the problem only partially, since the very fact of information exchange between the participants is more important than its content.
In most modern systems, whether e-mail, ICQ, or twitter, the server owner has all this data and can, if necessary, share it when receiving an official or unofficial request for it. The following is a draft of a network built on top of I2P, in which the owner uses his nodes only to provide more stable operation and as gateways on the normal Internet, having no more information than regular I2P nodes.
Consider the mechanisms for ensuring anonymity and confidentiality of I2P, on which we will rely to build our network:
')
Earlier , it was shown that I2P is actually a two-tier design: a router that provides interaction with other routers and tunnels, and protocols for transferring data between applications. If the protocols for the router appear to be thoroughly thought out and effective, then the application protocols leave much to be desired and are a jumble of various concepts and ideas caused by the desire to make them as versatile and “transparent” as possible for existing applications. In our case, the task is significantly simplified, since we assume an exchange between our clients, therefore we can use our own protocol.
Another problem I2P is that when you 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 incomplete 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 floodfills “closest to themselves”, the client may simply 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 make it possible to find each other's LeaseSets immediately.
Each I2P node is identified by an I2P address representing 2 pairs of public and private keys generated at the time of creating the node at random, without any correlation with the IP address or location. There is no central address source; it is assumed that the probability of two randomly generated addresses coinciding is negligible. The owner of the node is the one who has a file with a full set of keys. The two public keys and a 3-byte certificate (currently always zero) form a 387-byte node identifier, under which the node becomes known in I2P. Since the full 387-byte identifier is rather inefficient for comparing, sorting and transmitting data, the 32-byte SHA-256 hash from the identifier is used to identify the node, which we use to identify the client. Since the address contains a signature key, it would be difficult for an attacker to impersonate another client; this is equivalent to selecting such a pair of keys, the hash from which will correspond to the given identifier. If necessary, the client can confirm that it is he who hides behind the I2P address by signing a document with his key.
So, our network will consist of clients running on our computers on our network and our servers. Both clients and servers are full-fledged I2P routers, while the servers are declared high-speed and designed primarily to pass transit traffic, while customers mostly use their own tunnels, and transit traffic - to disguise their activity. Server information is public and known to clients, but at the same time, the servers do not know anything about clients and do not have the ability to distinguish clients from regular I2P nodes. Clients will select nodes for the tunnels so that there is exactly one server in the tunnel, and the remaining nodes belong to other members of the usual I2P. Even if all of our servers are under the attacker's control, one node will not be enough to determine the other end of the standard 3-step tunnel for I2P. 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 the tunnel is needed to improve the reliability of the tunnels due to the early detection of tunnels that have ceased to work. 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), then the creator of the tunnel does not know anything about it and continues to use the inoperative tunnel for a long time. Unlike conventional 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 to customers, thereby allowing the client to stop using such a tunnel immediately.
For data exchange between our clients, an I2NP message of type 20 - Data, containing arbitrary data, or a message of type 11 - Garlic can be used. Initially, I2P assumed the following exchange pattern between addresses: the LeaseSet should be requested by the addressee, then a Garlic message should be generated, specifying the address as a destination, encrypting it with a public encryption key from LeaseSet and sending it to the corresponding tunnel. The router, having received such a message, 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 caused a big “hole” in security, so in the current I2P implementation, each address has its own set of incoming tunnels and an encryption key, respectively, the router can determine the address and without the "garlic" message. By refusing to use “garlic” encryption, we get rid of another cumbersome I2P design - the AES / ElGamal engine, and can use encryption that is more efficient for our tasks, while sending type 11 messages to make our traffic indistinguishable from normal I2P.
Clients can exchange mail both within the network and with external recipients. In the first case, I2P addresses are used directly, and messages are sent through tunnels from the addressee’s LeaseSet. If the client cannot detect a LeaseSet with such an 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 name will be the server’s assigned user name, together forming a valid mailing address. If the client wants to send an e-mail outside the network, he must find the LeaseSet server (and he will find it necessarily), after which the server will recognize the message as an e-mail and send it to the addressee as a normal SMTP server. The recipient will know only the addresses of our SMTP server, and even if someone wants to find out from us who is behind this or that address, the maximum that we can communicate is the I2P address, and whose address is still unknown to us. If the server receives a message from the outside, then by name the user finds his I2P addresses and then sends them in the usual way inside our network.
In order to combat spam, we will introduce restrictions on the number of messages sent from each I2P address. In order for an address to send messages to the outside, it will have to register with the server and find out its name, while we require it to receive a certificate resulting from some resource-intensive computational task, thereby making it difficult for mass generation of addresses to be at the same time without creating problems for those only one or several addresses are needed.
Thus, we get a network, on the one hand, providing anonymity and confidentiality of the transmitted information, the disclosure of which is impossible without access to the client’s computer, and on the other hand, maintaining a high level of trust between clients using cryptographic identification tools. The use of a proprietary protocol and only it between clients allows to significantly simplify the implementation and improve the reliability of the network, the emergence of new high-speed routers will improve the performance and throughput of the I2P itself.
I would like to hear the opinion of the distinguished community on the proposed project as a whole, and first of all about potential attacks to de-anonymize customers, as well as other weak points and vulnerabilities.
In most modern systems, whether e-mail, ICQ, or twitter, the server owner has all this data and can, if necessary, share it when receiving an official or unofficial request for it. The following is a draft of a network built on top of I2P, in which the owner uses his nodes only to provide more stable operation and as gateways on the normal Internet, having no more information than regular I2P nodes.
Consider the mechanisms for ensuring anonymity and confidentiality of I2P, on which we will rely to build our network:
- Every 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 finding out on which router this or that address is located
- An I2P address is a pair of public keys for asymmetric encryption and signing. The private key pair is kept by the owner and is an acknowledgment of the authenticity of the address. In other words, for authorization, instead of passwords, this file with keys is used - an analog of a digital signature, maybe, if necessary, implemented as a token
- Connections between routers are encrypted using AES, the session key for which is negotiated in several steps, including verifying the node's address signature in order to counter man-in-the-middle attacks.
')
Earlier , it was shown that I2P is actually a two-tier design: a router that provides interaction with other routers and tunnels, and protocols for transferring data between applications. If the protocols for the router appear to be thoroughly thought out and effective, then the application protocols leave much to be desired and are a jumble of various concepts and ideas caused by the desire to make them as versatile and “transparent” as possible for existing applications. In our case, the task is significantly simplified, since we assume an exchange between our clients, therefore we can use our own protocol.
Another problem I2P is that when you 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 incomplete 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 floodfills “closest to themselves”, the client may simply 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 make it possible to find each other's LeaseSets immediately.
Each I2P node is identified by an I2P address representing 2 pairs of public and private keys generated at the time of creating the node at random, without any correlation with the IP address or location. There is no central address source; it is assumed that the probability of two randomly generated addresses coinciding is negligible. The owner of the node is the one who has a file with a full set of keys. The two public keys and a 3-byte certificate (currently always zero) form a 387-byte node identifier, under which the node becomes known in I2P. Since the full 387-byte identifier is rather inefficient for comparing, sorting and transmitting data, the 32-byte SHA-256 hash from the identifier is used to identify the node, which we use to identify the client. Since the address contains a signature key, it would be difficult for an attacker to impersonate another client; this is equivalent to selecting such a pair of keys, the hash from which will correspond to the given identifier. If necessary, the client can confirm that it is he who hides behind the I2P address by signing a document with his key.
So, our network will consist of clients running on our computers on our network and our servers. Both clients and servers are full-fledged I2P routers, while the servers are declared high-speed and designed primarily to pass transit traffic, while customers mostly use their own tunnels, and transit traffic - to disguise their activity. Server information is public and known to clients, but at the same time, the servers do not know anything about clients and do not have the ability to distinguish clients from regular I2P nodes. Clients will select nodes for the tunnels so that there is exactly one server in the tunnel, and the remaining nodes belong to other members of the usual I2P. Even if all of our servers are under the attacker's control, one node will not be enough to determine the other end of the standard 3-step tunnel for I2P. 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 the tunnel is needed to improve the reliability of the tunnels due to the early detection of tunnels that have ceased to work. 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), then the creator of the tunnel does not know anything about it and continues to use the inoperative tunnel for a long time. Unlike conventional 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 to customers, thereby allowing the client to stop using such a tunnel immediately.
For data exchange between our clients, an I2NP message of type 20 - Data, containing arbitrary data, or a message of type 11 - Garlic can be used. Initially, I2P assumed the following exchange pattern between addresses: the LeaseSet should be requested by the addressee, then a Garlic message should be generated, specifying the address as a destination, encrypting it with a public encryption key from LeaseSet and sending it to the corresponding tunnel. The router, having received such a message, 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 caused a big “hole” in security, so in the current I2P implementation, each address has its own set of incoming tunnels and an encryption key, respectively, the router can determine the address and without the "garlic" message. By refusing to use “garlic” encryption, we get rid of another cumbersome I2P design - the AES / ElGamal engine, and can use encryption that is more efficient for our tasks, while sending type 11 messages to make our traffic indistinguishable from normal I2P.
Clients can exchange mail both within the network and with external recipients. In the first case, I2P addresses are used directly, and messages are sent through tunnels from the addressee’s LeaseSet. If the client cannot detect a LeaseSet with such an 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 name will be the server’s assigned user name, together forming a valid mailing address. If the client wants to send an e-mail outside the network, he must find the LeaseSet server (and he will find it necessarily), after which the server will recognize the message as an e-mail and send it to the addressee as a normal SMTP server. The recipient will know only the addresses of our SMTP server, and even if someone wants to find out from us who is behind this or that address, the maximum that we can communicate is the I2P address, and whose address is still unknown to us. If the server receives a message from the outside, then by name the user finds his I2P addresses and then sends them in the usual way inside our network.
In order to combat spam, we will introduce restrictions on the number of messages sent from each I2P address. In order for an address to send messages to the outside, it will have to register with the server and find out its name, while we require it to receive a certificate resulting from some resource-intensive computational task, thereby making it difficult for mass generation of addresses to be at the same time without creating problems for those only one or several addresses are needed.
Thus, we get a network, on the one hand, providing anonymity and confidentiality of the transmitted information, the disclosure of which is impossible without access to the client’s computer, and on the other hand, maintaining a high level of trust between clients using cryptographic identification tools. The use of a proprietary protocol and only it between clients allows to significantly simplify the implementation and improve the reliability of the network, the emergence of new high-speed routers will improve the performance and throughput of the I2P itself.
I would like to hear the opinion of the distinguished community on the proposed project as a whole, and first of all about potential attacks to de-anonymize customers, as well as other weak points and vulnerabilities.
Source: https://habr.com/ru/post/228331/
All Articles