This is an intellectual challenge: how to design a generic, many-to-many communication system that prohibits surveillance entities from proving that you (1) read some website or (2) contributed content to some website, even if they do (1) capture and analyze all traffic on the Internet and (2) can break all encryption that is used for many-to-many communication (practically mostly SSL, which might be broken in many cases by NSA using MITM attacks). The only capabilities that we assume here that the surveillance body does not have is (1) breaking encryption used for local-only storage, such as TrueCrypt and (2) breaking encryption used for one-on-one encrypted communication between parties who know each other personally (which is comparatively simple to achieve with PGP etc.). So we're only talking here about them treating you as part of the big mass of people (one of the many activists out there …), not being one of the select few for which they do "targeted access operations" to infect your computer by software or hardware …

Note that, as we assume that the surveillance body captures all Internet communication globally, Tor can no longer be considered secure as they can then do timig correlations on the whole Tor network at once and with that information (simplified by running some own Tor nodes …) de-anonymize its participants. (For that reason, we cannot use realtime two-way communication at all.)

So: here's my proposal from three hours of thinking on today's evening about this. I guess it's pretty wanky 🙂 Anyway, your feedback is welcome.

The basic idea is to hide reading the website steganographically in reading another unsuspicious website, and contributing to the website steganographically in a botnet infection (and by contributing from public wi-fi only). So the surveillance body would see you communicating, but you can plausibly deny reading and writing on that forbidden website; you just read a photo blog and had a spam virus infection … can happen, right? 😛

Part by part:

Deniable reading: steganographic site-in-a-site

This needs an unsuspicious "host website" with considerable data traffic for every user. For example a photography forum or even a porn site. Being used as a host site could be negotiated in secret with the operators (if you are an activist with a valid cause to which people tend to agree), or the site could also be hacked for that purpose, or a site can be "reused" which happens to be a customer website on a web server you operate. But that's quite evil … . In any case, the site should have a large existing community so that everybody can justifiably claim that they just used the host site and did not know anything about the payload data hidden in its traffic.

So to read the "secret website" you want to access, you do a daily round on this "host website", looking at new posts etc.. You will use a special browser (started from a steganographically hidden and encrypted partition on your computer) with a plugin that extracts the new steganographic payload data from this host website. So every new day of updates on the host website also contain the new day of updates for the payload website. The updates are very compact, compressed, git-style updates, probably just plain text. Also, to make connecting input to users even harder, normally every post in the payload site is anonymous (not even pseudonymous!), but users could identify themselves with transient handles for just a few posts to create necessary context in a thread.

Instead of starting the payload extraction and decryption software from a steganographically hidden area, another alternative is to get it to be part of the basic operating system installation for everyone. Which is then likewise unsuspicious because it provides an alibi.

The payload website would not be encrypted. So the surveillance body would find out about it quickly, and it would take some weeks or months to get the host website switched off or its "infection" with the payload site removed (by choosing a proper jurisdiction for the server location, and by using Tor to hide its location somewhat, it can definitely take that long). At which point the payload site would switch to a different host site. Even better, it would always use different host sites in parallel for redundancy, and switching from one to the other would not need any re-downloading of previous data. Just the new "git commits".

But maybe it is better to have the payload data encrypted – if it helps to keep the "infection" from being detected for a long time, it definitely is better. That however implies that every user has to get their own specialized payload, encrypted with a PGP public key. So the host site cannot be a broadcast type of site (like a forum), but has to provide content to every user (like a PTT voice messaging site for example, since PTT voice messages can well take steganographic payload). The payload site server would also encode slightly randomized payload for the different users, and of course not log the random elements, to prevent the connections between the public keys (on the server) and the user accounts (of the host site) to be made when the server is compromised. Which means that even then, nobody can tell which users got data with payload and which are just normal users. Only when finding the users and seizing their computers one could tell that … but no, not even then, since (1) the users usually cannot be found and (2) their private keys for decryption are steganographically hidden on their computer (see below).

Against breaking communication encryption: anonymity by free wi-fi

There is no issue with encryption being broken (or content not being encrypted at all!) if this still does not give them a hint to your real-world identity. The solution is to not give them any connection between the IP address and personal identities. How to achieve this?

  • Use a mobile device that looks for open wi-fi networks while you walk around in a big city. If it finds one, it will connect to it quickly, send its data, and disconnect again. The data is a git-style, very compact update to the shared content of the website / forum you contribute to. With this method, you can sync to that website 1-2 times a day, which should be enough for most purposes.
  • If your country does not allow anonymous Internet access at all (such as in China), send your data by encrypted e-mail to somebody abroad whom you trust and who will perform the above procedure for you. If you don't have somebody you trust, you are doomed anyway 😉

The security and safety of this procedure can be enhanced by:

  • using directional wi-fi antennae hidden below your clothing (for example in your arm – the system will guide you to point your arm in the right direction to get the best connection to a remote wifi 😉
  • more importantly, by using a new, spoofed MAC address for every connection. Which is important in case the wi-fi network logs the MAC addresses of connections
  • choosing only wi-fi networks open to the general public (in bars, airports etc.), to avoid raising suspicion of the surveillance body against individuals whose wi-fi you would else compromise
  • disguising your optical appearance against face recognition through surveillance cameras etc.
  • unsuspicious behavior, to prevent raising suspicion in surveillance videos etc.; this however is a pretty low-grade threat, as it involes a lot of manual coordination work ("targeted access operations"), which a surveillance body cannot do for its whole population
  • writing from a different device than you use for reading; you would use commands like "reply-to:post452798" for placing your content at the right spot of the website; you would never ever exchange data between the two devices (since then, also data coming from a trojan by which the surveillance body infected your reading computer, could be transferred to your writing computer and could prove that you participate in the website instead of just "unknowingly" getting its data in steganograophic form)

Deniable contributions: a botnet is controlling your device!

This is a pretty funny idea: claiming that your computer (that you use for sending) does stuff that you don't even want it to do is perfectly reasonable. So even if you are caught sending through a free wi-fi network, you still have an alibi. Because there will indeed be a virus on this device, that also has the habit of sending out e-mail spam, but it is special in that you can control it. You can also justifiably deny doing so, since all the programs and data to do so (including your website contributions before being sent) are in a TrueCrypt-style partition with a full filesystem that is steganographically embedded in your personal library of self-made photos. Because these are your own photos (and you did not publish them anywhere!), nobody can claim that you steganographically modify them since they did not see them before.

But we need some more stuff: as spambots usually do, yours will auto-generate the spam e-mails you will send out, including many spelling errors, random input for changes to embedded images etc., "to pass the spam filters". But instead, these changes also allow you to add the steganographic input, which also will look just like random changes, so just like the spambot behavior. In reality, it is encrypted with a public key of the server from the website you contribute to, and as long as that private key keeps private, your alibi is safe. This is actually P2P encryption which we allowed above to be not broken. But even if it gets broken, you're still not caught by any means since you always use the free wi-fi for Internet access 🙂

The e-mails will travel to the server hosting the secret website (or to a P2P encryption connected, befriended server), with the alibi that it is also an e-mail server. The server will however claim that these e-mails are spam, and not forward them to its users. But of course, internally evaluate them to extract the payload data. The private key for doing that, and the whole "secret website" software has to be protected in the server, of course, and has to have "deniable existence". This is possible by, again, using steganographic storage of a TrueCrypt style partition, maybe in the image data of the "host website". When the server is physically accessed, it will quickly unmount that logical partition, delete the access key from its memory, and be just another normal webserver 🙂

Simplifications and optimizations

  • It is not needed to hack or infect a host site to use it for embedding another site. Just select one that allows anonymous image or video uploads. If doing so, it should however be a site where all the steganographic content is downloaded by regular users, too, so the steganographic users have an alibi. For example, a meme collection site that allows anonymous submissions and publishes daily updates is a good choice. Or a site that hosts pirated content or porn. This is much better than "infecting" sites and running a separate server for the steganographics. Since this way, no own server and no infected site can be taken down. All own software runs on the clients (which would have a little configuration file that selects what URLs to download for steganographic content, and which for cover, and a decryption key to access the extracted steganographic information. Depening on how far this key is shared, it becomes any software between steganographic 1:1 communciation or many-to-many communication.)
  • The important point is to make steganographic communication comfortable. Not like e-mail, but like a full forum, even with special features like calendars etc.. Only then one can organize social change with it. The way NNTP (Newsnet) works is a good paradigm: a desktop client software collects message / data packages from somewhere, and provides the frontend locally.
  • For anonymous posting on public wi-fi networks, maybe one can even use little quadrocopter or blimp drones, operating at night. During the day they would hide in some place not at your home, and in passing on your way to work etc. you would transfer the next set of data to upload to them.

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>