Skip to main content

Plausible Denial

Every quarter of a year, worried postings appear about governments and law enforcement on the hard disk encryption mailing list I'm subscribed to. The solutions are different every time but the problem stays the same: "Rubberhose attacks". This term is an elegant description of the attack path that works without ever touching cryptography: torture.

Torture involving a rubberhose is unlikely to occour in modern socities. Nonetheless, there are equally effective measures if needed. This fear gives rise to ideas like this: "The data should be destroyed when I type a special panic passphrase" or "store the hard disk encryption key on CD and break the CD when in trouble" or "stripe the partition of any sign of encryption header". They have the same goal: remove intention to torture the key owner.

To save a bit of your time I take this shortcut: THEY ARE ALL BROKEN and to figure out why is left as an exercise to the reader.

Instead, you need three things to avoid rubberhosing.

  1. Avoid any metadata that hints the existence of data.
  2. Use steganography.
  3. Provide a plausible explanation for using steganography software.
Let me elaborate these points.


Don't store a shell history, don't use "Recent Document"-like features, don't use programs that create things like thumbnail caches. Make sure your disk access pattern is uniform.


"Steganography" can also be read as "hide data within other data". Files are the most uniform and convenient way of storing data. Unfortunately you can't hide arbitrary files in arbitrary other files, as the format will vary. But you can hide file systems in the free space of other file systems. In fact, if you store something in the free space, it won't be free space anymore. But without the right access token (password), thinking of this space as anything but free space is big no-no.

Think again of rule number #1 "don't let any metadata hint the existence of the data you want to keep secret". Hence in any such layered file system implementation, the outer file system must known nothing about the inner file system and it's management algorithms must regard space occupied by the inner file system as free space.

Potemkin Cities

This concept must be stackable. The file system layering must be able to grow infinitely deep. Again this is because of rule number #1 - the metadata rule. Do you think that the man with the stick believes that you don't have anything to hide if you use software that is made for hiding data? No, of course not. The installed software is metadata itself and as its existence can't be removed from the system obviously, you need to provide a plausible explanation.

Now, here is the point where your creativity comes in. You need to build Potemkin Cities. You need to build a fake data repository that is private enough that others would buy that you have a strong interest in keeping these fake data private. If you are a spy that poses the launch codes of intercontinental nuclear missiles, it would be wise to put pornographic pictures on the middle layers that depict you cheating on your wife (that is surely part of your cover-marriage).

Facing torture, you reveal access to these Potemkin cities and therefore provide an explanation for using encryption software. As the same principal "don't hint metadata about the more inner layers" applies to the middle layer, the attacker has no way of knowing how much layers are left in the free space he seeing. He only sees this space shrinking with every key you reveal (I strongly suggest that you only reveal a single key, because this looks most innocent -- at least to me).

You can't do that

There is no such system -- at least none that I know of. You need to implement these things at file system level, as the free space must "flow" between the layers dynamically. Whenever you write to this file system, you must provide the keys to all file system layers, otherwise new files might be written into locations that are marked as free (remember the requirement that the outer layers must know nothing about the inner layers) but in fact contain data.

The most hardest thing to conceal -- in my opinion -- is the hardware usage pattern. Every write request to the disk leaves magnetic traces that might be analysable. The steganography file system software must schedule disk writes in a way that will yield a uniform disk writing pattern. That's a tasty requirement, right?

Update: There seems to be such a file system for Linux. Unfortunately, outdated.


Popular posts from this blog

Liskell standalone

Some time has passed since I last blogged about Liskell. It is not dead nor have I changed my mind that Haskell needs a proper meta-programming facility not to mention a better syntax.Liskell was a branch of GHC once. Now it sits on top of the GHC API, or I should rather say sneaks behind its back as it creates its own API as the original one is not suitable for the stunts I'm interested in. If Liskell sticks with GHC as its soil, I will definitely send patches upstream to refine the GHC API in the areas where it needs more flexibility for Liskell. However for the moment, my main target was to get something out that compiles with a stable version of GHC.You can grab it with the usual: darcs get This version has been tested with ghc 6.10.1 and should install like: ./Setup.lhs configure ./Setup.lhs build ./Setup.lhs install cd LskPrelude make install-inplace Optionally you can run make tests in the testsuite subdirectory. Thanks to community.haskell…

XMonad GridSelect

Personally, I not just need a window manager, I need a focus manager. I tend to think of windows as TODO items, and as there are many TODOs in life there are many windows on my workspaces. Usually a fraction of that can't be closed or worked on immediately, so they linger around on my desktop, cluttering my workspace.I used to use the Tabbed layout. But Tabbed isn't the answer when you are a guy who reports bugs such as "XMonad 0.6 with Tabbed dies when firefox-session-restore slams 40 windows at once on the desktop". In other words, I use a lot of windows. The workspaces concept isn't particularly useful to me either. My mind just doesn't work with mental boxes. So the result is, that I have too few workspaces with too much windows on them, so that Tabbed has trouble displaying useful window titles, and navigating through them is slow and cumbersome (mostly because tab switching generates a lot of useless X Expose events).GridSelect is my answer to that. It…

Removing CHS based access from windows boot loaders

Recently, I had troubles to migrate my Windows installation from VMWare to VirtualBox. When booting the vmware created partition in virtualbox, I got "NTLDR not found". So I sharpened the knives and got down to business with vmware's gdb interface and virtualbox's internal debugger. Tracing the execution showed that the BIOSes of the two products reported different geometries on the INT 13h interface. The generic method contained in the boot loader to read a sector from disk is "clever" as it checks whether the sector is below the maximum sector index that is reachable with the CHS geometry reported by the BIOS. If not, it uses the LBA interface of the BIOS. If yes, the cleverness of the boot loader suddenly vanishes. Instead of using the BIOS reported geometry to break the absolute sector down into its CHS components, the boot loader uses a geometry stored in the so called BIOS parameter block. That's a section of the first sector embedded into the boo…