Threat model

From Freenet Wiki
Jump to: navigation, search

This document is evolving. Obviously what threats we can protect against changes as Freenet changes.

Contents

Assumptions

  • The user follows documented best practice. They don't give out their home address on an anonymous forum. They don't reinsert stuff as a CHK. (Obviously the documented best practice will change with time too).
  • Uploaders of original content are much more valuable than downloaders, or volunteers running the Keepalive plugin to keep content retrievable.
  • The attacker is initially distant, and only knows that the target is on Freenet.
  • Social engineering to get a connection is relatively expensive because it involves human interaction.
  • Bribing people to run surveillance software to spy on their friends is relatively expensive.
  • Compromising computers via exploits is expensive because it is illegal, sometimes detected, and sometimes technically difficult.

Note that "expensive" here doesn't mean prohibitively expensive for a single instance. It means that it gets to be a significant expense when you have to do it to thousands of nodes/people. It may still be affordable for many attackers. But we assume that, for example, it is much more expensive to social engineer 1000 users (to get darknet connections) than to connect to their nodes on opennet.

Basics

If you are connected to a node, you can log what requests/inserts it does, and do some statistics ("correlation attacks") to figure out whether they are inserting (or downloading) a known (published) large file. The main task is to prevent the attacker from getting connected to the originator in the first place. It follows that almost all attacks are dramatically more expensive on darknet than on opennet.

In future we will provide protection against malicious direct peers by means of tunnels, but even this works far better on darknet than on opennet, see e.g. the PISCES paper.

Also, we care about blocking. It should be hard to block Freenet.

Major attacks

See Major attacks

Potential attackers

See Potential attackers

Procedures

Code review/analysis

All released code is manually reviewed.

TODO automated code review tools.

Unit tests: Limited coverage.

Release procedure

Documented elsewhere. All released code should have been reviewed by the person doing the release. Releases are signed and there is a revocation mechanism for the auto-updater.

Penetration testing (network level)

Not currently a priority for paid staff. Partly because on opennet there are some rather easy attacks. We want to fix them before we draw attention to them!

However, long term, the best way to quantify an attack is to try it out, and attackers will inevitably build their own tools.

IMHO long term a security bounty program would be a good idea too.

Penetration testing (infrastructure)

No current activity.

Personal tools