i2p.www/www.i2p2/pages/how_threatmodel.html

{% extends "_layout.html" %}
{% block title %}I2P's Threat Model{% endblock %}
{% block content %}<h1>What do we mean by "anonymous"?</h1>

<p>Your level of anonymity can be described as how hard it is for someone
to find out information you don't want them to know - who you are, where
you are located, who you communicate with, or even when you communicate.  
"Perfect" anonymity is not a useful concept here - software will not make 
you indistinguisable from people that don't use computers or who are not on
the internet.  Instead, I2P is working to provide sufficient anonymity to meet the
real needs of whomever we can - from Joe Sixpack browsing porn to Tommy Trader
sharing files to Irene Insurgent organizing an upcoming action.</p>
  
<p>The question of whether I2P provides sufficient anonymity for your 
particular needs is a hard one, but this page will hopefully assist in 
answering that question by exploring how I2P operates under various attacks
so that you may decide whether it meets your needs.</p>

<p>We welcome further research and analysis on I2P's resistance to the threats described below.
Both review of existing literature (much of it focused on Tor) and original
work focused on I2P is needed.</p>

<h2>Mix summary</h2>
<p>I2P builds off the ideas of many <a href="how_networkcomparisons">other</a> 
<a href="links">systems</a>, but a few key points should be kept in mind when 
reviewing related literature:</p><ul>
<li><b>I2P is a free route mixnet</b> - the message creator explicitly defines the
    path that messages will be sent out (the outbound tunnel), and the message 
    recipient explicitly defines the path that messages will be received on (the
    inbound tunnel).  However, any of these hops along the path may inject an 
    arbitrary number of hops before forwarding the message to the next peer (though
    the current implementation does not).</li>
<li><b>I2P is variable latency</b> - each application (destination) determines its
    own tradeoff of latency, throughput, bandwidth, and anonymity by configuring 
    the number of hops in their tunnels, the number of tunnels to keep in parallel,
    and how frequently to rotate tunnels.  In addition, there are plans to implement
    <a href="todo#stop">nontrivial delays</a> and <a href="todo#batching">batching strategies</a> 
    whose existence is only known to the particular hop or tunnel gateway that 
    receives the message, allowing a mostly low latency mixnet to provide cover 
    traffic for higher latency communication (e.g. email).</li>
<li><b>I2P has no entry and exit points</b> - all peers fully participate in the 
    mix, and there are no network layer in- or out-proxies (however, at the 
    application layer, a few outbound HTTP proxies exist at the moment)</li>
<li><b>I2P is fully distributed</b> - there are no central controls or peers who
    take on uneven responsabilities (beyond load balancing due to resource constraints).
    One could modify some routers to operate mix cascades (building tunnels and giving
    out the keys necessary to control the forwarding at the tunnel endpoint) or directory 
    based profiling and selection, all without breaking compatability with the rest of 
    the network, but doing so is of course not necessary (and may even harm one's
    anonymity).</li>
</ul>

<h2>Attacks</h2>
<p>Taking from the attacks and analyses put forth in the 
<a href="http://freehaven.net/anonbib/topic.html">anonymity literature</a> (largely 
<a href="http://citeseer.ist.psu.edu/454354.html">Traffic Analysis: Protocols, Attacks, Design 
Issues and Open Problems</a>), the following briefly describes a wide variety 
of attacks as well as many of I2Ps defenses.  We will update
this list to include new attacks as they are identified.</p>

<ul>
<li><a href="#bruteforce">Brute force attacks</a></li>
<li><a href="#timing">Timing attacks</a></li>
<li><a href="#intersection">Intersection attacks</a></li>
<li><a href="#dos">Denial of service attacks</a></li>
<li><a href="#tagging">Tagging attacks</a></li>
<li><a href="#partitioning">Partitioning attacks</a></li>
<li><a href="#predecessor">Predecessor attacks</a></li>
<li><a href="#harvesting">Harvesting attacks</a></li>
<li><a href="#sybil">Sybil attacks</a></li>
<li><a href="#crypto">Cryptographic attacks</a></li>
<li><a href="#floodfill">Floodfill attacks</a></li>
<li><a href="#central">Attacks on centralized resources</a></li>
<li><a href="#dev">Development attacks</a></li>
<li><a href="#impl">Implementation attacks</a></li>
</ul>

<h3 id="bruteforce">Brute force attacks</h3>

<p>A brute force attack can be mounted by a global passive or active adversary, 
watching all the messages pass between all of the nodes and attempting to correlate
which message follows which path.  Mounting this attack against I2P should be 
nontrivial, as all peers in the network are frequently sending messages (both
end to end and network maintenance messages), plus an end to end message changes
size and data along its path.  In addition, the external adversary does not have
access to the messages either, as inter-router communication is both encrypted
and streamed (making two 1024 byte messages indistinguishable from one 2048 byte
message).</p>

<p>However, a powerful attacker can use brute force to detect trends - if they 
can send 5GB to an I2P destination and monitor everyone's network connection,
they can eliminate all peers who did not receive 5GB of data.  Techniques to 
defeat this attack exist, but may be prohibitively expensive (see: 
<a href="http://citeseer.ist.psu.edu/freedman02tarzan.html">Tarzan</a>'s mimics
or constant rate traffic).  Most users are not concerned with this attack, as 
the cost of mounting it are extreme (and often require illegal activity).  
However, the attack is still possible, and those who want to defend against it 
would want to make appropriate countermeasures, such as not communicating with 
unknown destinations, not publishing one's current leaseSet in the network 
database, actively rerouting the associated tunnels 'mid stream', throttling the
inbound tunnels themselves, and/or using restricted routes with trusted links 
to secure the local connection.</p>

<h3 id="timing">Timing attacks</h3>

<p>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.</p>

<p>This sort of attack is powerful, but its applicability to I2P is nonobvious,
as the variation on message delays due to queueing, 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).</p>

<p>Without protocol scrubbing or higher latency, global active adversaries can 
gain substantial information.  As such, people concerned with these attacks should
increase the latency (per <a href="todo#stop">nontrivial delays</a> or 
<a href="todo#batching">batching strategies</a>), include protocol scrubbing, or
other advanced tunnel routing <a href="todo#batching">techniques</a>.</p>

<p>References:
<a href="http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf">Low-Resource Routing Attacks Against Anonymous Systems</a>
</p>

<h3 id="intersection">Intersection attacks</h3>

<p>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.</p>
  
<p>I2P does not attempt to address this for low latency communication,
but does for peers who can afford delays (per <a href="todo#stop">nontrivial 
delays</a> and <a href="todo#batching">batching strategies</a>).  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.</p>

<h3 id="dos">Denial of service attacks</h3>

<p>There are a whole slew of denial of service attacks available against I2P,
each with different costs and consequences:</p><ul>
<li><b>Greedy user attack:</b> The most plausible attack against I2P will simply
    be people trying to consume significantly more resources than they are 
    willing to contribute.  The defense against this is twofold:<ul>
    <li>First, for people who do not need very strong anonymity, simply set the tunnel length
    to 0 hops (1 hop until <a href="todo#ordering">strict ordering</a> and 
    <a href="todo#tunnelLength">permuted lengths</a> is implemented).  This will
    provide optimal throughput while still providing a degree of anonymity via
    plausible deniability.  In addition, it will not consume significant network
    resources.</li>
    <li>Second, for people who do need stronger anonymity, educate them so they 
    understand that without routing other people's traffic, their own anonymity
    is weakened, so that if they want to consume significant network resources
    while still being anonymous, they need to provide significant network 
    resources.</li></ul>
<li><b>Starvation attack:</b> A hostile user may attempt to harm the network by
    creating a significant number of peers in the network who are not identified as
    being under control of the same entity (as with Sybil).  These nodes then 
    decide not to provide any resources to the network, causing existing peers 
    to search through a larger network database or request more tunnels than 
    should be necessary. 
    Alternatively, the nodes may provide intermittent service by periodically
    dropping selected traffic, or refusing connections to certain peers.
    This behavior may be indistinguishable from that of a heavily-loaded or failing node.
    I2P addresses these issues by maintaining <a href="how_peerselection.html">profiles</a> on the 
    peers, attempting to identify underperforming ones and simply ignoring 
    them, or using them rarely.
    In the process of fixing several problems and bugs with peer reachability
    in the 0.6.1.32 and 0.6.1.33 releases, we have significantly enhanced the
    ability to recognize and avoid troublesome peers. These efforts will
    continue in the 0.6.2.x release cycle.
</li>
<li><b>Flooding attack:</b> A hostile user may attempt to flood the network,
    a peer, a destination, or a tunnel.  Network and peer flooding is possible,
    and I2P does nothing to prevent standard IP layer flooding.  The flooding of
    a destination with messages by sending a large number to the target's various
    inbound tunnel gateways is possible, but the destination will know this both
    by the contents of the message and because the tunnel's tests will fail.  The
    same goes for flooding just a single tunnel.  I2P has no defenses for a network
    flooding attack.  For a destination and tunnel flooding attack, the target
    identifies which tunnels are unresponsive and builds new ones.  New code could
    also be written to add even more tunnels if the client wishes to handle the
    larger load.  If, on the other hand, the load is more than the client can
    deal with, they can instruct the tunnels to throttle the number of messages or
    bytes they should pass on (once the <a href="todo#batching">advanced tunnel
    operation</a> is implemented).</li>
<li><b>CPU load attack:</b> There are currently some methods for people to 
    remotely request that a peer perform some cryptographically expensive 
    operation, and a hostile attacker could use these to flood that peer with
    a large number of them in an attempt to overload the CPU.  Both using good 
    engineering practices and potentially requiring nontrivial certificates 
    (e.g. HashCash) to be attached to these expensive requests should mitigate
    the issue, though there may be room for an attacker to exploit various
    bugs in the implementation.</p>
<li id="ffdos"><b>Floodfill DOS attack:</b> A hostile user may attempt to harm the network by
    becoming a floodfill router. The current defenses against unreliable,
    intermittent, or malicious floodfill routers are poor.
    To fix problems with floodfill peer selection
    in the 0.6.1.32 and earlier releases, significantly enhancments in the
    ability to recognize and avoid troublesome floodfill peers
    were included in release 0.6.1.33.
    However, there is much more to do.
    A floodfill router may provide bad or no response to lookups, and
    it may also interfere with inter-floodfill communication.
    A brief summary of the issues is
    listed on <a href="http://zzz.i2p/#floodfill">zzz.i2p</a>.
    These efforts will continue in the 0.6.2.x release cycle.
</li>
</ul>

<h3 id="tagging">Tagging attacks</h3>
<p>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 <a href="todo#tunnelId">unique hop ids</a> 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.</p>

<h3 id="partitioning">Partitioning attacks</h3>

<p>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).</p>

<p>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 <a href="#harvesting">harvesting</a> 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 <a href="todo#stop">nontrivial delays</a> and 
<a href="todo#batching">batching strategies</a>, 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 probabalistic partition, as they wouldn't know
which other tunnels or messages have those delays).</p>

<h3 id="predecessor">Predecessor attacks</h3>

<p>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.  </p>

<p>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 <a href="how_peerselection">peer selection</a> algorithm which breaks them
into tiers.  Second, with <a href="todo#ordering">strict ordering</a> of peers
in a tunnel, the fact that a peer shows up more frequently does not mean they're
the source.  Third, with <a href="todo#tunnelLength">permuted tunnel length</a>
even 0 hop tunnels can provide plausible deniability as the occational 
variation of the gateway will look like normal tunnels.  Fourth, with 
<a href="todo#fullRestrictedRoutes">restricted routes</a>, only the peer with
a restricted connection to the target will ever contact the target, while 
attackers will merely run into that gateway.</p>

<p>References:
<a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf</a>
which is an update to the 2004 predecessor attack paper
<a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf</a>.
</p>

<h3 id="harvesting">Harvesting attacks</h3>

<p>The harvesting attack can be used for legal attacks and to help mounting
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 
built to optimize this attack, since there is the distributed network database 
containing just this information.  However, this by itself isn't a problem,
since there are ways to track down who is participating in the network with
essentially all public systems - I2P just makes it easier to do (and, in 
turn, gains the ability to combat partitioning and provide well bounded 
discovery time).  With <a href="todo#nat">basic</a> and 
<a href="todo#fullRestrictedRoutes">comprehensive</a> restricted routes, 
this attack loses much of its power, as the "hidden" peers do not publish their
contact addresses in the network database - only the tunnels through which 
they can be reached (as well as their public keys, etc).</p>

<h3 id="sybil">Sybil attacks</h3>

<p>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 'nonfree' - <a href="http://www.pdos.lcs.mit.edu/tarzan/">Tarzan</a>
(among others) uses the fact that IP addresses are limited, while 
IIP used 
<a href="http://www.hashcash.org/">HashCash</a> 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).</p>

<h3 id="crypto">Cryptographic attacks</h3>

<p>
We are still assuming the security of the cryptographic primitives explained 
<a href="how_cryptography">elsewhere</a>.  That includes 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 network protocol 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.</p>

<h3 id="floodfill">Floodfill Anonymity attacks</h3>
<p>
In addition to the floodfill DOS attacks described
<a href="#ffdos">above</a>, floodfill routers are uniquely positioned
to learn about network participants, due to their centralized role
in the netDb, and the high frequency of communication with those participants.
The specific potential threats and corresponding defenses are a topic for further research.
</li>

<h3 id="central">Central Resource Attacks</h3>
<p>
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.
<ul>
<li>The <a href="/">new website</a> is mirrored and uses DNS round-robin for external public access.
<li>Routers now support <a href="faq.html#reseed">multiple external reseed locations</a>,
    however more reseed hosts may be needed, and the handling of unreliable or malicious
    reseed hosts may need improvement.
<li>Routers now support multiple update file locations.
    A malicious update host could feed a huge file, need to limit the size.
<li>Routers now support multiple default trusted update signers.
<li>Routers now better handle <a href="#ffdos">multiple unreliable floodfill peers</a>.
    Malicious floodfills <a href="#ffdos">needs</a> <a href="#floodfill">more</a> study.
<li>The code is now stored in a <a href="monotone.html">distributed source control system</a>.
<li>Routers still rely on a single news host, update for this is TBD.
    A malicious news host could feed a huge file, need to limit the size.
<li><a href="naming.html">Naming system services</a>, including addressbook subscription providers, add-host services,
    and jump services, could be malicious. Substantial protections for subscriptions were implemented
    in release 0.6.1.31, with additional enhancements in subsequent releases.
    However, all naming services require some measure of trust, see
    <a href="naming.html">the naming page</a> for details.
<li>We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
    disruption in our ability to attract new users,
    and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
</ul>


<h3 id="dev">Development attacks</h3>

<p>
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 lives of a developer's loved ones (or even just issuing a 
court order along with a gag order, under threat of prison), everyone should expect that 
the code would be modified.  </p>

<p>
However, two techniques help defend against these attacks:
<ul>
<li> All components of the network must be open source to enable inspection, verification, 
     modification, and improvement.  If a developer is compromised, once it is noticed 
     the community should demand explanation and cease to accept that developer's work.</li>
<li> Development over the network itself, allowing developers to stay anonymous but still 
     secure the development process.  All I2P development can occur through I2P - the 
     CVS server (cvs.i2p), the public web server (www.i2p), the mailing list archives 
     (dev.i2p/pipermail/i2p), discussion forums (forum.i2p), and the software distribution 
     area (dev.i2p/i2p) are all online.</li>
</ul>
</p>

<h3 id="impl">Implementation attacks</h3>
<p>
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 in the open and asking for any and all criticism with 
the hope that many eyes will improve the system.  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.</p>


<h2>Other Defenses</h2>
<h3>Blocklists</h3>
<p>
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.
<p>
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.
<p>
Any blocking within i2p would have to be implemented at the following
places in the code to be fully effective.
Different places address the various possible malicious behaviors.
<ol>
<li>Outbound connections (bids)
<li>Inbound NTCP
<li>Inbound SSU
<li>Peer selection for inbound and outbound tunnels
<li>Other-end inbound gateway
<li>Netdb stores / shitlisting
<li>Floodfill stores
<li>Floodfill queries
<li>Inter-floodfill flooding
<li>SSU peer tests
<li>SSU address determination
</ol>

<p>
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.
<p>
If a blocklist is hosted at a central location with automatic updates
the network is vulnerable to a
<a href="#central">central resource attack</a>.
Automatic subscription to a list gives the list provider the power to shut
the i2p network down. Completely. So we probably won't be doing that.
Inclusion in i2pupdate files perhaps? Signed or unsigned?
In-I2P subscription?
<p>
Initial test results
show that the common splist.txt blocklist is overly broad for our use - at the least
we don't want to block Tor users that are in splist.
Level1 + bogon + (maybe) level2 is more reasonable?
But we don't want to block potential anonymity researchers at .edu locations.


{% endblock %}