Steganography

Stephen Oliver edited this page Aug 13, 2016 · 2 revisions
Clone this wiki locally

Long term, we need Freenet to be usable in [hostile environments](Hostile Environments "wikilink") where it may be actively attacked.

This means using Darknet, but it also means that Freenet traffic must be hard to identify through traffic monitoring.

Background

Session bytes

China blocked Freenet 0.5 at the session bytes level in 2005. Freenet 0.7 is not susceptible to this kind of blocking because it does not have any predictable session bytes.

Darknet

Freenet 0.5 can also be identified quickly by [node harvesting](Node Harvesting "wikilink"). An attacker can run a hacked node and quickly identify every node, because Freenet 0.5 is strictly an Opennet.

Freenet 0.7 supports both Darknet and Opennet functionality, and will warn users when running Opennet that they should get some Darknet peers, or their node will be not only harvestable, but also much easier to attack.

Simple steganography

Although Freenet 0.7 does not have fixed session bytes, it can still be identified relatively easily, by its packet size, and by the fact that it isn't any other known protocol (obviously this has a significant cost of potentially blocking other traffic).

So, once we have [transport plugins](Transport Plugins "wikilink"), we can have plugins that impersonate specific other traffic types.

We can also have "trap-door" transports on TCP. Freenet can for example proxy an HTTP port; normally it goes through to the local webserver, but when the magic word is sent, it turns into a TCP-based FNP connection.

Suggestions

At this point, the big threat is [traffic flow analysis](traffic flow analysis "wikilink").

How do we beat it?

Well, maybe we can't. Some people say it's impossible. Generally it comes down to whether the steganographer or the steganalyst has the better model of the underlying process which is being faked: hence it is an eternal arms race. So, you get things like nodes pretending to place voice calls, in order to transfer data, and trying to fake the timing, while the attacker tries to model it better to identify the nodes. Note that most of the below require support for very high latency transports; obviously this implies very high latency requests. IMHO it is possible with a good user interface and with the right request semantics (something close to passive requests perhaps?) to build a useful system in such conditions.

However I'm not going to take no for an answer. Here are some possibilities:

  • Some computer games still operate in an everyone-to-everyone manner, such as Company of Heroes. This makes for some interesting stego options, although of course strong enough traffic analysis could see that that is not the topology which is operating ...

  • Impersonating usage as well as form. So, for example, a private games server which is used regularly by a group of friends. This is closest to what is normally understood by steganography as described above.

  • Parasitic transports. Using the video stream from a call, but only connecting when a call is actually made, for example.

Physical rendezvous, aka Freenet over Sneakernet. Either you carry a which wirelessly exchanges with your peers' PDA when you are in the same room (see Pocket Switched Networking here and here, for example), or you exchange boxes of disks - in person, periodically transporting a whole bunch of boxes, sticking a DVD in a dead letter box, sending them through the mail etc. Flash memory cards have become small, cheap, high capacity, and fast - see Sneakernet.

WiFi, optical, laser links etc. Possible to detect of course, but a lot harder to analyse than the commercial internet. Can be highly directional while still being hidden from obvious view. The downside is that even with wifi these things must be highly directional and probably rooftop mounted for good range/performance. And long range is very difficult (possible with high power 802.11a for example, but only because it's licensed!).

A list of existing Steganography Tools: http://steganography.daniellerch.me/p/software.html

A better alternative

Using Freenet traffic himself as steganographic basis. At present, Freenet users are a conspicuous group of people, who have one problem or another with the locally valid laws. Freenet needs a legal main use. [integration into operating systems](OS Integration "wikilink") may create this legal main use. By increasing data security, Freenet has the opportunity to become a wildly accepted computer technology.

Possible transports

Bunnycams

A possible steganographic transport for Freenet.

From a Frost message:

----- tCA@YPwrSbAJjj8297lo5bdELe08se0 ----- 2008.01.15 - 12:02:42GMT -----
I just had a cute thought, assume freenet has been banned and ISPs shut down anyone with unexplained traffic.
What's a legitimage high-bandwidth 24/7 connection between two home users? It's a webcam feed!
So, every survivor installs a webcam, points it at something inconspicous, a bunny in a cage for example,
and encodes freenet traffic in the noise of the (naturally noisy) webcam video. And there you have an innocent
social network of bunny admirers, where every member has several webcam feeds in the web browser 24/7.

It might be best to use a relatively old and low quality compression method for this like MPEG-1. One of the ways to hide data would be to add the data as coefficients to the DCT block after quantization.

Random number generator

The only steganographic transport with 0% overhead. Pretend you are serving random numbers like http://random.org

Encrypted backup

There are lots of automated encrypted backup solutions around. While an oppressive government would be suspicious of strong encryption offsite encrypted backups are common. This transport has also the advantage of low overhead.

Photo-sharing community

...or any other cloud activity. If you can exchange some data, you can exchange any data. Due to missing encryption, this would have high overhead - similar to bunnycams.

Portscan

Could have low overhead but is suspicous in itself.

Ajax site

Lots of XMLHttpRequests and responses are not that weird anymore these days.

Inefficient compression

Losless and lossy compression methods often have different ways to describe the final data. This difference can be used to hide information. The information will be hidden in the larger than optimal size of the compressed archive. After the data is extracted the hidden information is lost and can be easily overlooked.

Spam

Dear E-Commerce professional ; This letter was specially  selected to be sent to you . This is a one time mailing  there is no need to request removal if you won't want  any more . This mail is being sent in compliance with  Senate bill 1620 , Title 2 , Section 309 . This is  not multi-level marketing ! Why work for somebody else  when you can become rich in 32 days . Have you ever  noticed more people than ever are surfing the web plus  most everyone has a cellphone . Well, now is your chance  to capitalize on this ! We will help you process your  orders within seconds and turn your business into an  E-BUSINESS ! You are guaranteed to succeed because  we take all the risk . But don't believe us ! Mr Anderson  of Colorado tried us and says "Now I'm rich, Rich,  RICH" ! We are licensed to operate in all states .  If not for you then for your LOVED ONES - act now !  Sign up a friend and you'll get a discount of 80% !  Best regards ! 

Decode this message at: http://www.spammimic.com/decode.shtml

External links