July 25th, 2014

eyes black and white

Plausible deniability for filesystem encryption

TrueCrypt is no more. Even when it was, relying on VFAT of itself was suspicious. Moreover, not being able to use the decoy partition is also suspicious. So your obviously used laptop has a partition with data that's 2 years old?

Here is a proposed method for plausibly deniable filesystem encryption, that doesn't require meddling too much with filesystem drivers:

  1. The encrypted partition driver randomly stores its master data in one of N blocks; other blocks are random data. Your key may or may not unlock each of the blocks. (This may or may not require modifying dm-crypt).
  2. The decoy password unlocks an encrypted partition with a decoy filesystem that covers the entire available space.
  3. The real system is created as a large "image" file in this decoy filesystem — but it will be completely purged when the decoy filesystem is "parked" (see below). Efficiently creating the large file without actually writing tons of useless data to disk may require some filesystem driver enhancements, but it's probably doable to convince regular kernel maintainers to add and maintain such a (privileged) system call. Otherwise, you may have to waste a few hours to write plenty of zeros for all the space you won't be using then more zeros for the space you will be using, to it's beyond the space normally used (otherwise the existence of a hidden file is apparent).
  4. A section of the inner file is a small secure bootstrap partition. It is either made of contiguous blocks, or at least has enough blocks to constitute the header of a VFAT filesystem that skips over the blocks it doesn't own.
  5. To initialize the system, mark the image file as immutable, and build a map of the blocks it occupies. Find enough contiguous blocks for the secure bootstrap (or for its FAT table), store the map of blocks in the secure bootstrap partition, add the bootstrap partition as a new entry to the set of N encrypted partition blocks, with a real key.
  6. To mount the encrypted system (as when securely booting), make a loopback block device based on the map (minus blocks used for the secure boot partition), and mount that as an encrypted device, using the same key as for the secure bootstrap partition.
  7. After unmounting the decoy, "park" it: remount in a mode that intercepts and records changes, thoroughly purge any trace of the partition file (which might require filesystem knowledge for certain effect), store the changes in the secure partition, unmount.
  8. Before mounting the decoy, "unpark" it: undo the changes recorded while parking.
  9. During regular use, mount the unparked decoy, and use it in a virtual machine or operating system container to do all your non-sensitive activities inside (family-oriented web browsing, etc.)
  10. When travelling, turn off the computer and park it. Keep off-disk backups in case the bad guys force you to turn on the system and that messes up the secure file.
  11. Problem: you only have plausible deniability while the decoy is parked, but if you actively use it, then you only get plausible deniability when you shut down the computer properly, and cannot just "pull the plug" on it. Solution: if you want more plausible deniability, keep your "live" decoy data on the encrypted partition, and once in a while, unpark the the decoy filesystem, rsync the decoy data onto it, and park it again, with a small, controlled window of vulnerability every so many days. Keep some porn in your decoy data to justify why you wanted to shut down your computer in a hurry.
  12. For extra bonus, the loopback block device records a tree of digests for the device, so you can detect that tampering happened from booting in unsecure mode, and reach for your backups.

Point 1. is the most important one. If you can selectively hide or show different partitions depending on the key, then you can just leave unallocated space and claim you intend to install another OS later, and have a live decoy without the need for parking.