I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Added modified DREAD rating support to threat model

Browse Source 
TODO: The ratings are all currently set to low, and MUST be discussed and set
properly before site launch.
This commit is contained in:
str4d
2013-09-30 00:48:08 +00:00
parent 3d9e74220f
commit 2d17699e04
2 changed files with 134 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

136
i2p2www/pages/site/docs/how/threat-model.html
View File

@@ -2,6 +2,45 @@
{% block title %}{% trans %}I2P's Threat Model{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}November 2010{% endtrans %}{% endblock %}
{% block accuratefor %}0.8.1{% endblock %}
{% macro get_level(num) %}
{%- if num == 1 %}{{ _('low') }}
{%- elif num == 2 %}{{ _('medium') }}
{%- elif num == 3 %}{{ _('high') }}
{%- else %}ERR_INVALID
{%- endif %}
{%- endmacro %}
{% macro calculate_severity(Da, R, A) %}
{%- if R + A > 4 %}{{ caller(Da + 2) }}
{%- elif R + A > 3 %}{{ caller(Da + 1) }}
{%- else %}{{ caller(Da) }}
{%- endif %}
{%- endmacro %}
{% macro calculate_priority(Da, R, E, A, Di) %}
{%- call(severity) calculate_severity(Da, R, A) %}
{%- if E == 3 and Di == 3 %}{{ severity + 4 }}
{%- elif (E == 3 and Di == 2) or ( E == 2 and Di == 3) %}{{ severity + 3}}
{%- elif (E == 3 and Di == 1) or ( E == 1 and Di == 3) %}{{ severity + 2}}
{%- elif E == 2 and Di == 2 %}{{ severity + 1}}
{%- else %}{{ severity }}
{%- endif %}
{%- endcall %}
{%- endmacro %}
{% macro DREAD_score(Da, R, E, A, Di) %}
<ul class="DREAD" >
<li><strong>{{ _('Damage Potential') }}</strong>: <em>{{ get_level(Da) }}</em></li>
<li><strong>{{ _('Reliability') }}</strong>: <em>{{ get_level(R) }}</em></li>
<li><strong>{{ _('Exploitability') }}</strong>: <em>{{ get_level(E) }}</em></li>
<li><strong>{{ _('Affected Users') }}</strong>: <em>{{ get_level(A) }}</em></li>
<li><strong>{{ _('Discoverability') }}</strong>: <em>{{ get_level(Di) }}</em></li>
<li><strong>{{ _('Severity') }}</strong>: <em>{% call(S) calculate_severity(Da, R, A) %}{{ S }}{% endcall %}/5</em></li>
<li><strong>{{ _('Priority') }}</strong>: <em>{{ calculate_priority(Da, R, E, A, Di) }}/10</em></li>
</ul>
{% endmacro %}
{% block content %}
<h2>{% trans %}What do we mean by "anonymous"?{% endtrans %}</h2>
@@ -75,7 +114,7 @@ the current implementation does not.
{%- endtrans %}</p>
<h2>{% trans %}The Threat Model (Attacks){% endtrans %}</h2>
<h2>{% trans %}The Threat Model{% endtrans %}</h2>
<p>{% trans -%}
I2P design started in 2003, not long after the advent of
<a href="http://www.onion-router.net">[Onion Routing]</a>,
@@ -118,7 +157,25 @@ The
to review.
{%- endtrans %}</p>
<h3 id="index">{% trans %}Index{% endtrans %}</h3>
<p>{% trans DREAD='https://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx' -%}
Attacks are judged using the <a href="{{ DREAD }}">modified <strong>DREAD</strong> model</a>:
{%- endtrans %}</p>
<ul>
<li><strong>{{ _('Damage Potential') }}</strong>: {% trans %}If a threat exploit occurs, how much damage will be caused?{% endtrans %}</li>
<li><strong>{{ _('Reliability') }}</strong>: {% trans %}How reliable is the attack?{% endtrans %}</li>
<li><strong>{{ _('Exploitability') }}</strong>: {% trans %}What is needed to exploit this threat?{% endtrans %}</li>
<li><strong>{{ _('Affected Users') }}</strong>: {% trans %}How many users will be affected?{% endtrans %}</li>
<li><strong>{{ _('Discoverability') }}</strong>: {% trans %}How easy is it to discover this threat?{% endtrans %}</li>
</ul>
<p>{% trans DREAD='https://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dreadful.aspx' -%}
Each category is given a rating of low, medium or high. The severity
and priority scores are calculated using the equations outlined
<a href="{{ DREAD }}">here</a>.
{%- endtrans %}</p>
<h3 id="index">{% trans %}Index of Attacks{% endtrans %}</h3>
<ul>
<li><a href="#bruteforce">{% trans %}Brute force attacks{% endtrans %}</a></li>
<li><a href="#timing">{% trans %}Timing attacks{% endtrans %}</a></li>
@@ -142,6 +199,8 @@ to review.
<h3 id="bruteforce">{% trans %}Brute force attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 3) }}
<p>{% trans -%}
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
@@ -184,6 +243,8 @@ are discussed on the
<h3 id="timing">{% trans %}Timing attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
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
@@ -219,6 +280,8 @@ References: <a href="{{ pdf }}">Low-Resource Routing Attacks Against Anonymous S
<h3 id="intersection">{% trans %}Intersection attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
Intersection attacks against low latency systems are extremely powerful -
periodically make contact with the target and keep track of what peers are on
@@ -301,12 +364,13 @@ Reference: <a href="{{ oce }}">One Cell Enough</a>
There are a whole slew of denial of service attacks available against I2P,
each with different costs and consequences:
{%- endtrans %}</p>
<ul>
<li>{% trans -%}
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
<b>Greedy user attack:</b> This is simply
people trying to consume significantly more resources than they are
willing to contribute. The defense against this is:
{%- endtrans %}
{%- endtrans %}</p>
<ul>
<li>{% trans comparisons=site_url('comparison') -%}
Set defaults so that most users provide resources to the network.
@@ -323,8 +387,10 @@ metrics such as "share ratio" so that users may see what they are contributing.
Maintain a strong community with blogs, forums, IRC, and other means of communication.
{%- endtrans %}</li>
</ul>
</li>
<li>{% trans peerselection=site_url('docs/how/peer-selection') -%}
<div style="clear:both"></div>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans peerselection=site_url('docs/how/peer-selection') -%}
<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
@@ -340,8 +406,11 @@ them, or using them rarely.
We have significantly enhanced the
ability to recognize and avoid troublesome peers; however there are still
significant efforts required in this area.
{%- endtrans %}</li>
<li>{% trans todo=site_url('get-involved/todo') -%}
{%- endtrans %}</p>
<div style="clear:both"></div>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans todo=site_url('get-involved/todo') -%}
<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
@@ -356,8 +425,11 @@ 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).
{%- endtrans %}</li>
<li>{% trans -%}
{%- endtrans %}</p>
<div style="clear:both"></div>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
<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
@@ -366,8 +438,11 @@ 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.
{%- endtrans %}</li>
<li id="ffdos">{% trans peerselection=site_url('docs/how/peer-selection'),
{%- endtrans %}</p>
<div style="clear:both"></div>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p id="ffdos">{% trans peerselection=site_url('docs/how/peer-selection'),
netdb=site_url('docs/how/network-database') -%}
<b>Floodfill DOS attack:</b> A hostile user may attempt to harm the network by
becoming a floodfill router. The current defenses against unreliable,
@@ -379,10 +454,13 @@ Some defenses and
however there is much more to do.
For more information see the
<a href="{{ netdb }}#threat">network database page</a>.
{%- endtrans %}</li>
</ul>
{%- endtrans %}</p>
<div style="clear:both"></div>
<h3 id="tagging">{% trans %}Tagging attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans todo=site_url('get-involved/todo') -%}
Tagging attacks - modifying a message so that it can later be identified
further along the path - are by themselves impossible in I2P, as messages
@@ -399,6 +477,8 @@ as the links are encrypted and messages signed.
<h3 id="partitioning">{% trans %}Partitioning attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
Partitioning attacks - finding ways to segregate (technically or analytically)
the peers in a network - are important to keep in mind when dealing with a
@@ -437,6 +517,8 @@ Also discussed on the <a href="{{ netdb }}#threat">network database page</a> (bo
<h3 id="predecessor">{% trans %}Predecessor attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
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
@@ -479,6 +561,9 @@ which is an update to the 2004 predecessor attack paper
<h3 id="harvesting">{% trans %}Harvesting attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
"Harvesting" means compiling a list of users running I2P.
It can be used for legal attacks and to help
@@ -523,6 +608,9 @@ enact other restricted route methods.
<h3 id="traffic">{% trans %}Identification Through Traffic Analysis{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans transport=site_url('docs/transport') -%}
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.
@@ -581,6 +669,8 @@ Reference: <a href="{{ pdf }}">Breaking and Improving Protocol Obfuscation</a>
<h3 id="sybil">{% trans %}Sybil attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
Sybil describes a category of attacks where the adversary creates arbitrarily
large numbers of colluding nodes and uses the increased numbers to help
@@ -627,6 +717,9 @@ for more Sybil discussion.
<h3 id="buddy">{% trans %}Buddy Exhaustion attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans pdf='http://www.eecs.berkeley.edu/~pmittal/publications/nisan-torsk-ccs10.pdf' -%}
(Reference: <a href="{{ pdf }}">In Search of an Anonymouns and Secure Lookup</a> Section 5.2)
{%- endtrans %}</p>
@@ -650,6 +743,8 @@ Further research and defenses may be necessary.
<h3 id="crypto">{% trans %}Cryptographic attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans cryptography=site_url('docs/how/cryptography') -%}
We use strong cryptography with long keys, and
we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
@@ -689,6 +784,9 @@ end to end messages include simple random padding.
<h3 id="floodfill">{% trans %}Floodfill Anonymity attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans netdb=site_url('docs/how/network-database') -%}
In addition to the floodfill DOS attacks described
<a href="#ffdos">above</a>, floodfill routers are uniquely positioned
@@ -716,6 +814,9 @@ Several scenarios are discussed on the
<h3 id="central">{% trans %}Central Resource Attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
There are a few centralized or limited resources (some inside I2P, some not)
that could be attacked or used as a vector for attacks.
@@ -769,6 +870,8 @@ and would shrink the network (in the short-to-medium term), just as the loss of
<h3 id="dev">{% trans %}Development attacks{% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
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
@@ -807,6 +910,9 @@ should any defense be necessary.
{%- endtrans %}</p>
<h3 id="impl">{% trans %}Implementation attacks (bugs){% endtrans %}</h3>
{{ DREAD_score(1, 1, 1, 1, 1) }}
<p>{% trans -%}
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

13
i2p2www/static/styles/duck/default.css
View File

@@ -175,6 +175,7 @@ div#content .inner h1, div#content .inner h2, div#content .inner h3, div#content
margin:1em 0 .5em;
border-bottom:1px solid white;
padding-bottom:.2em;
clear:both;
}
div#content .inner h1 {
@@ -247,6 +248,18 @@ div#content .inner td.blue {
padding: 5px;
}
/*
* Threat model
*/
div#content .inner ul.DREAD {
border: 2px solid red;
float: left;
list-style: none;
margin: 1em 1.5em 1em 0;
padding: 0.5em;
}
/*
* Additions to syntax.css
*/