I've been reading Cory Doctorow's book Little Brother. In it, our hero gets illegally detained and he wishes he had set up a second password for his phone which decrypted an empty partition, so he could give away that password instead of the real data password.

You can do this under Linux by creating two partitions, and setting up LVM on both, and hacking the cryptsetup code so that it tries to decrypt one partition, and if that fails tries the other. Then the boot could continue normally with scanning for an LVM, finding which ever one is active, and using that. However, you don't have to look very hard to see that this laptop with a 200GB drive only has 10GB of usable space on it.

So I started thinking about how you would create a partition that could have multiple data-sets on it, without it being obvious to someone with access to the hardware that it was there. Read on for my thoughts on it.

First of all, let me say that this is just an idea, it's not something that you can go out and make use of. I do think it's an interesting idea and am writing it down in case it helps someone implement something like (or perhaps even better :-).

With a file-system like ZFS, you have a fixed location super block (actually, two of them IIRC), which then points at the blocks for the rest of the file-system, including blocks containing information about what blocks are free on the file-system. Usually, this block is at a fixed location on the disc.

A 4GB file-system on a 40GB device has 36GB worth of "holes" that one or more other file-systems could hide in.

The basis of my idea is to store multiple superblocks at different locations randomly around the block device. Each of which would point to different maps of the used blocks. One superblock might point at a freshly installed OS image (or one that was artificially aged to look like it was used for -- whatever), and another could point at the superblock for your real root partition.

We could even have more than 2 superblocks, for things like two distinct users on the same system, multiple different OSes, even possibly different virtual OS images, running at the same time. For example, you might boot your "non-confidential" OS image periodically to run a program to make it look like it was recently used.

It could even be implemented like a snapshot, where the confidential file-system was sharing the data with the public partition. So they could share the same OS data, preventing duplication, but anything written to the confidential version would produce a distinct copy.

New blocks for the file-systems would be allocated by searching the free lists of all the different superblocks, and merging them. But then allocations would only be recorded against the file-system for which the block was actually used in.

LUKS works by putting a header in place that includes crypto information, allowing things like multiple pass-phrases that can be used to access different "slots" within the LUKS header, which is used to get access to the key and other information required to access the underlying block device, transparently encrypting/decrypting the data.

If we combine these ideas, putting LUKS together with the file-system (much like ZFS did with combining LVM and RAID and the file-system), we can get some other benefits.

There could be multiple slots (dozens, hundreds, possibly even thousands), and the slots would each include random data, or encrypted data storing one or more sets of the location of the super block, and the crypto key used to access the file-system.

So one passphrase would be used to unlock both the confidential and public file-systems (you need to unlock it so you can get access to it's list of free blocks) but the other one would only unlock the public file-system.

If you give out the key for the public FS, anyone looking at the data would not be able to prove that there were any other file-system on the device (as long as the device was initialized with randomish data). Because your confidential data would be hiding in the "holes" in the public file-system.

Now, this is part of the problem. If you boot the system with the other passphrase, decrypting only the public FS, it will know nothing about the confidential file-system. So if you start updating the file-system, you run the risk of overwriting the other file-systems.

My solution to this would be to write to disc a list of the next set of eligible blocks to use for the file-system. Kind of a cache of free blocks... If you did a partial mount (only mounting some of the superblocks) and then did allocations that could be entirely satisfied out of the free block cache (and any blocks returned to this cache that were freed during the session), then the other file-systems would remain uncorrupted.

That's my straw-man. Now someone just needs to build it. :-) Perhaps there are already designs like this out there, but I haven't heard of anything like this.
(Post Reply)