Votre niveau d'anonymat peut se définir par "la difficulté que quelqu'un rencontrera pour trouver des informations vous concernant que vous ne voulez pas qu'il connaisse" - qui vous êtes, où vous vous trouvez, avec qui vous communiquez, ou même quand. L'anonymat "parfait" n'est ici un concept ni pertinent ni utile : un logiciel ne vous rendra pas indiscernable par des gens qui n'utilisent ni ordinateur ni Internet. Nous travaillons plutôt à produire l'anonymat suffisant aux besoins réels, dans la mesure du possible, de qui que ce soit - de ceux qui se promènent simplement sur Internet, à ceux qui échangent des données, jusqu'à ceux inquiets de l'intrusion des organisations et des états.
La réponse à la question de savoir si I2P apportera un anonymat suffisant à vos besoins particuliers est difficile, mais nous espérons que cette page vous éclairera en passant en revue les diverses menaces.
Nous accueillons avec bienveillance toutes recherches et analyses supplémentaires sur la résistance d'I2P aux menaces décrites ci-dessous. Nous avons besoin de plus de recherche sur la littérature existante (dont la plus grande partie est focalisée sur Tor), ainsi que de travaux originaux.
I2P germe des idées de nombreux autres systèmes, mais il faut garder à l'esprit un petit nombre de points essentiels quand on examine la littérature concernée :
Nous avons des plans documentés de mise en œuvre de retards conséquents et de stratégies traitements par lots dont l'existence et le détail des modalités ne sont connus que par le saut ou la passerelle de tunnel particuliers qui reçoivent le message, pour permettre au réseau (croisé à basse latence dans sa caractéristique principale) de fournir un trafic de camouflage aux communications de latence plus élevée (p.ex. les e-mails). Nous savons que l'introduction de retards élevés est requise pour assurer une protection significative, et que son implémentation sera une épreuve sérieuse. Il n'est cependant pas actuellement certain que nous solliciterons ces méthodes de retardement.
En théorie, des routeurs situés sur le chemin du message pourraient injecter un nombre arbitraire de sauts supplémentaires avant de transférer le message au pairs suivant. L'implémentation actuelle ne le fait pas.
La conception d'I2P a commencé en 2003, juste après l'apparition de l' [Onion Routing], de [Freenet], et de [Tor]. Notre conception tire de substantiels bénéfices des recherches publiées à cette époque. I2P utilise plusieurs des techniques du routage en oignon, et continue de bénéficier de l'intérêt que Tor suscite dans la recherche théorique.
Inspirée des attaques et analyses mises en avant dans littérature (particulièrement Traffic Analysis: Protocols, Attacks, Design Issues and Open Problems), la suite décrit brièvement un large éventail d'attaques et plusieurs des contre-mesures prises par I2P. Nous tenons à jour cette liste pour y ajouter les nouvelles attaques au fur et à mesure de leurs découvertes.
Nous y adjoignons quelques attaques spécifiques à I2P. Nous n'avons pas de réponse adaptée à chacune d'elles, mais nous poursuivons nos recherches et fourbissons nos défenses.
De plus, plusieurs de ces attaques sont d'autant plus potentiellement réalisables que la taille du réseau est actuellement modeste. Bien que nous soyons au courant de quelques limitations qui restent à résoudre, I2P est conçu pour accueillir des centaines de millier et même des millions de participants. Au fur et à mesure de la croissance du réseau, ces attaques deviendront de plus en plus difficiles à monter.
Les pages sur la comparaison des réseaux et la terminologie des "gousses d'ail" apportent aussi un éclairage complémentaire.
Une attaque en force brute peut être montée par un adversaire global passif ou actif qui surveillerait tous les transferts de messages entre tous le nœuds et tenterait d'établir une corrélation entre les messages et les chemins qu'ils empruntent. Le montage d'une attaque de ce type contre I2P ne serait pas une mince affaire car tous les pairs du réseau envoient souvent des messages (tant de bout en bout que d'entretien du réseau), sans compter les changements de taille et de données des messages tout au long de leur transit d'un bout à l'autre. de plus, l'attaquant externe n'a pas accès au messages, car la communication inter-router est à la fois cryptée et envoyée comme un flux (ce qui rend deux messages de 1024 bits indiscernables d'un message de 2048 bits).
Cependant, un attaquant puissant peut utiliser la force brute pour détecter des tendances - s'il peut envoyer 5 Go à une destination I2P et surveiller toutes les connexions du réseau, il peut éliminer les pairs qui n'ont pas reçu 5 Go. Il existe des techniques pour déjouer cette attaque, mais elle serait prohibitive (voir : Tarzan et sa simulation de trafic à taux constant). La plupart des utilisateurs ne craignent pas cette attaque à cause de son extrême coût de montage (et du fait qu'elle nécessiterait à coup sûr un comportement légalement répréhensible). Elle est malgré tout envisageable au niveau d'un gros FAI ou d'un point d'échange Internet. Ceux qui veulent y parer devraient prendre des mesure conservatoires, telles que régler de faibles limites de bande passante et l'utilisation de jeux de baux cryptés ou non publiés pour les sites eep. D'autre contre-mesures comme les retards volontaires et les routes privées ne sont pas implémentées actuellement.
En tant que protection partielle envers un seul routeur ou un groupe de routeurs qui tenteraient de router tout le trafic du réseau, le routeur contient des limites quand au nombre de tunnels pouvant être routés par un seul pair. As the network grows, these limits are subject to further adjustment. D'autres mécanismes d'évaluation, de sélection et d'évitement des pairs sont approfondis la page sélection des pairs.
I2P's messages are unidirectional and do not necessarily imply that a reply will be sent. However, applications on top of I2P will most likely have recognizable patterns within the frequency of their messages - for instance, an HTTP request will be a small message with a large sequence of reply messages containing the HTTP response. Using this data as well as a broad view of the network topology, an attacker may be able to disqualify some links as being too slow to have passed the message along.
This sort of attack is powerful, but its applicability to I2P is non obvious, as the variation on message delays due to queuing, message processing, and throttling will often meet or exceed the time of passing a message along a single link - even when the attacker knows that a reply will be sent as soon as the message is received. There are some scenarios which will expose fairly automatic replies though - the streaming library does (with the SYN+ACK) as does the message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).
Without protocol scrubbing or higher latency, global active adversaries can gain substantial information. As such, people concerned with these attacks could increase the latency (using nontrivial delays or batching strategies), include protocol scrubbing, or other advanced tunnel routing techniques, but these are unimplemented in I2P.
References: Low-Resource Routing Attacks Against Anonymous Systems
Intersection attacks against low latency systems are extremely powerful - periodically make contact with the target and keep track of what peers are on the network. Over time, as node churn occurs the attacker will gain significant information about the target by simply intersecting the sets of peers that are online when a message successfully goes through. The cost of this attack is significant as the network grows, but may be feasible in some scenarios.
In summary, if an attacker is at both ends of your tunnel at the same time, he may be successful. I2P does not have a full defense to this for low latency communication. This is an inherent weakness of low-latency onion routing. Tor provides a similar disclaimer.
Partial defenses implemented in I2P:
In the future, it could for peers who can afford significant delays (per nontrivial delays and batching strategies). In addition, this is only relevant for destinations that other people know about - a private group whose destination is only known to trusted peers does not have to worry, as an adversary can't "ping" them to mount the attack.
Reference: One Cell Enough
There are a whole slew of denial of service attacks available against I2P, each with different costs and consequences:
Tagging attacks - modifying a message so that it can later be identified further along the path - are by themselves impossible in I2P, as messages passed through tunnels are signed. However, if an attacker is the inbound tunnel gateway as well as a participant further along in that tunnel, with collusion they can identify the fact that they are in the same tunnel (and prior to adding unique hop ids and other updates, colluding peers within the same tunnel can recognize that fact without any effort). An attacker in an outbound tunnel and any part of an inbound tunnel cannot collude however, as the tunnel encryption pads and modifies the data separately for the inbound and outbound tunnels. External attackers cannot do anything, as the links are encrypted and messages signed.
Partitioning attacks - finding ways to segregate (technically or analytically) the peers in a network - are important to keep in mind when dealing with a powerful adversary, since the size of the network plays a key role in determining your anonymity. Technical partitioning by cutting links between peers to create fragmented networks is addressed by I2P's built in network database, which maintains statistics about various peers so as to allow any existing connections to other fragmented sections to be exploited so as to heal the network. However, if the attacker does disconnect all links to uncontrolled peers, essentially isolating the target, no amount of network database healing will fix it. At that point, the only thing the router can hope to do is notice that a significant number of previously reliable peers have become unavailable and alert the client that it is temporarily disconnected (this detection code is not implemented at the moment).
Partitioning the network analytically by looking for differences in how routers and destinations behave and grouping them accordingly is also a very powerful attack. For instance, an attacker harvesting the network database will know when a particular destination has 5 inbound tunnels in their LeaseSet while others have only 2 or 3, allowing the adversary to potentially partition clients by the number of tunnels selected. Another partition is possible when dealing with the nontrivial delays and batching strategies, as the tunnel gateways and the particular hops with non-zero delays will likely stand out. However, this data is only exposed to those specific hops, so to partition effectively on that matter, the attacker would need to control a significant portion of the network (and still that would only be a probabilistic partition, as they wouldn't know which other tunnels or messages have those delays).
Also discussed on the network database page (bootstrap attack).
The predecessor attack is passively gathering statistics in an attempt to see what peers are 'close' to the destination by participating in their tunnels and keeping track of the previous or next hop (for outbound or inbound tunnels, respectively). Over time, using a perfectly random sample of peers and random ordering, an attacker would be able to see which peer shows up as 'closer' statistically more than the rest, and that peer would in turn be where the target is located.
I2P avoids this in four ways: first, the peers selected to participate in tunnels are not randomly sampled throughout the network - they are derived from the peer selection algorithm which breaks them into tiers. Second, with strict ordering of peers in a tunnel, the fact that a peer shows up more frequently does not mean they're the source. Third, with permuted tunnel length (not enabled by default) even 0 hop tunnels can provide plausible deniability as the occasional variation of the gateway will look like normal tunnels. Fourth, with restricted routes (unimplemented), only the peer with a restricted connection to the target will ever contact the target, while attackers will merely run into that gateway.
The current tunnel build method was specifically designed to combat the predecessor attack. See also the intersection attack.
References: http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf which is an update to the 2004 predecessor attack paper http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf.
"Harvesting" means compiling a list of users running I2P. It can be used for legal attacks and to help other attacks by simply running a peer, seeing who it connects to, and harvesting whatever references to other peers it can find.
I2P itself is not designed with effective defenses against this attack, since there is the distributed network database containing just this information. The following factors make the attack somewhat harder in practice:
In the future, routers could use GeoIP to identify if they are in a particular country where identification as an I2P node would be risky. In that case, the router could automatically enable hidden mode, or enact other restricted route methods.
By inspecting the traffic into and out of a router, a malicious ISP or state-level firewall could identify that a computer is running I2P. As discussed above, I2P is not specifically designed to hide that a computer is running I2P. However, several design decisions made in the design of the transport layer and protocols make it somewhat difficult to identify I2P traffic:
Reference: Breaking and Improving Protocol Obfuscation
Sybil describes a category of attacks where the adversary creates arbitrarily large numbers of colluding nodes and uses the increased numbers to help mounting other attacks. For instance, if an attacker is in a network where peers are selected randomly and they want an 80% chance to be one of those peers, they simply create five times the number of nodes that are in the network and roll the dice. When identity is free, Sybil can be a very potent technique for a powerful adversary. The primary technique to address this is simply to make identity 'non free' - Tarzan (among others) uses the fact that IP addresses are limited, while IIP used HashCash to 'charge' for creating a new identity. We currently have not implemented any particular technique to address Sybil, but do include placeholder certificates in the router's and destination's data structures which can contain a HashCash certificate of appropriate value when necessary (or some other certificate proving scarcity).
Requiring HashCash Certificates in various places has two major problems:
Various limitations on the number of routers in a given IP range restrict the vulnerability to attackers that don't have the ability to put machines in several IP blocks. However, this is not a meaningful defense against a powerful adversary.
See the network database page for more Sybil discussion.
(Reference: In Search of an Anonymouns and Secure Lookup Section 5.2)
By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure that a tunnel is formed wholly from its set of colluding routers. The chances of success are enhanced if there is a large number of colluding routers, i.e. a Sybil attack. This is somewhat mitigated by our peer profiling methods used to monitor the performance of peers. However, this is a powerful attack as the number of routers approaches f = 0.2, or 20% malicious nodes, as specifed in the paper. The malicous routers could also maintain connections to the target router and provide excellent forwarding bandwidth for traffic over those connections, in an attempt to manipulate the profiles managed by the target and appear attractive. Further research and defenses may be necessary.
We use strong cryptography with long keys, and we assume the security of the industry-standard cryptographic primitives used in I2P, as documented on the low-level cryptography page. Security features include the immediate detection of altered messages along the path, the inability to decrypt messages not addressed to you, and defense against man-in-the-middle attacks. The key sizes chosen in 2003 were quite conservative at the time, and are still longer than those used in other anonymity networks. We don't think the current key lengths are our biggest weakness, especially for traditional, non-state-level adversaries; bugs and the small size of the network are much more worrisome. Of course, all cryptographic algorithms eventually become obsolete due to the advent of faster processors, cryptographic research, and advancements in methods such as rainbow tables, clusters of video game hardware, etc. Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change shared secret values while maintaining backward compatibility.
Upgrading the various data structures and protocols to support longer keys will have to be tackled eventually, and this will be a major undertaking, just as it will be for others. Hopefully, through careful planning, we can minimize the disruption, and implement mechanisms to make it easier for future transitions.
In the future, several I2P protocols and data structures support securely padding messages to arbitrary sizes, so messages could be made constant size or garlic messages could be modified randomly so that some cloves appear to contain more subcloves than they actually do. At the moment, however, garlic, tunnel, and end to end messages include simple random padding.
In addition to the floodfill DOS attacks described above, floodfill routers are uniquely positioned to learn about network participants, due to their role in the netDb, and the high frequency of communication with those participants. This is somewhat mitigated because floodfill routers only manage a portion of the total keyspace, and the keyspace rotates daily, as explained. on the network database page. The specific mechanisms by which routers communicate with floodfills have been carefully designed. However, these threats should be studied further. The specific potential threats and corresponding defenses are a topic for future research.
A hostile user may attempt to harm the network by creating one or more floodfill routers and crafting them to offer bad, slow, or no responses. Several scenarios are discussed on the network database page.
There are a few centralized or limited resources (some inside I2P, some not) that could be attacked or used as a vector for attacks. The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008, highlighted numerous centralized resources in the development and operation of the I2P network, most of which are now distributed. Attacks on externally-reachable resources mainly affect the ability of new users to find us, not the operation of the network itself.
These attacks aren't directly on the network, but instead go after its development team by either introducing legal hurdles on anyone contributing to the development of the software, or by using whatever means are available to get the developers to subvert the software. Traditional technical measures cannot defeat these attacks, and if someone threatened the life or livelihood of a developer (or even just issuing a court order along with a gag order, under threat of prison), we would have a big problem.
However, two techniques help defend against these attacks:
Try as we might, most nontrivial applications include errors in the design or implementation, and I2P is no exception. There may be bugs that could be exploited to attack the anonymity or security of the communication running over I2P in unexpected ways. To help withstand attacks against the design or protocols in use, we publish all designs and documentation and solicit review and criticism with the hope that many eyes will improve the system. We do not believe in security through obscurity.
In addition, the code is being treated the same way, with little aversion towards reworking or throwing out something that isn't meeting the needs of the software system (including ease of modification). Documentation for the design and implementation of the network and the software components are an essential part of security, as without them it is unlikely that developers would be willing to spend the time to learn the software enough to identify shortcomings and bugs.
Our software is likely, in particular, to contain bugs related to denial of service through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues in the router console, and other vulnerabilities to non-standard inputs via the various protocols.
I2P is still a small network with a small development community and almost no interest from academic or research groups. Therefore we lack the analysis that other anonymity networks may have received. We continue to recruit people to get involved and help.
To some extent, I2P could be enhanced to avoid peers operating at IP addresses listed in a blocklist. Several blocklists are commonly available in standard formats, listing anti-P2P organizations, potential state-level adversaries, and others.
To the extent that active peers actually do show up in the actual blocklist, blocking by only a subset of peers would tend to segment the network, exacerbate reachability problems, and decrease overall reliability. Therefore we would want to agree on a particular blocklist and enable it by default.
Blocklists are only a part (perhaps a small part) of an array of defenses against maliciousness. In large part the profiling system does a good job of measuring router behavior so that we don't need to trust anything in netDb. However there is more that can be done. For each of the areas in the list above there are improvements we can make in detecting badness.
If a blocklist is hosted at a central location with automatic updates the network is vulnerable to a central resource attack. Automatic subscription to a list gives the list provider the power to shut the i2p network down. Completely.
Currently, a default blocklist is distributed with our software, listing only the IPs of past DOS sources. There is no automatic update mechanism. Should a particular IP range implement serious attacks on the I2P network, we would have to ask people to update their blocklist manually through out-of-band mechanisms such as forums, blogs, etc.
{% endblock %}