Plausibly deniable encryption is a full disk encryption scheme where the encrypted volume looks like pure random noise. There’s no way to distinguish the volume from random junk unless you have the decryption key. The only way to prove with absolute certainty that encryption is being used on the drive, is to have the encryption key and be able to successfully decrypt the data.
In order to achieve this, there has to be no plaintext volume or file metadat stored on the same disk as the encrypted volume. This disqualifies LUKS because there is a plaintext header containing metadata about the LUKS volume. This header doesn’t contain any info that could be used to decrypt the disk without the key, but it’s enough to establish that disk encryption is in use, which could potentially put one’s physical wellbeing in danger if under attack by a sufficiently ruthless and powerful attacker.
The idea behind plausibly deniable encryption is to make it so that a victim in such an attack could lie about their use of full disk encryption and be believed anyway. There’s no way to prove that encrypted data is on the disk, thus someone could claim there isn’t any and potentially be believed.
While it sounds powerful in theory, there are quite a few problems with this:
- If you store a plausibly deniable encrypted volume on the same disk with other data, you’re left with an (almost certainly very large) chunk of space on your disk that is either partitioned but shown as having no filesystem, or that is excluded from partitioning entirely. Almost no one uses their computer with a large block of unallocated or unformatted space on their disk, so this alone is suspicious.
- The data on the disk still looks like random noise. You can’t make it look like valid data. This means that the only lie you can plausibly tell is one that states or implies that the drive was wiped with random data at some point. This is potentially believable if you devote an entire drive to the encrypted volume (and I mean the whole drive, you can’t even use a partition table if you want this to be really believable), but if you have other partitions on the same drive, this raises even worse suspicions because now you’re claiming that you have a pointless block of unallocated or unformatted space on your disk. At this point your attacker can be virtually certain you’re using an encrypted volume, and that you’re trying to hide it.
- Even under ideal circumstances, the attacker can prove beyond a reasonable doubt that you’re using an encrypted volume if they can take multiple snapshots of the drive at different times, and you modify data on the encrypted volume after the first snapshot but before one or more subsequent snapshots. This is because the attacker see that the bits in the “pointless” unallocated space are changing. This indicates that you’re writing to that area of the drive, and therefore that you most likely are using it for some particular purpose. Could you lie to get around this? Maybe, perhaps you could claim that you’re using that area of the drive to store random data for some project of some sort and that you need to change the data in use every so often, but that’s a pretty flimsy excuse when at this point your drive is exhibiting behavior that 99.99% of the time is the result of someone using plausibly deniable encryption. You’d also have to use that excuse the first time you were confronted by the attacker and then stick to it, otherwise you’d end up changing stories which similarly proves that you’re hiding something.
Ultimately, plausibly deniable encryption is potentially useful when dealing with a ruthless attacker, but it’s a very weak defense unless used perfectly, and even then it’s flimsy. I imagine the best way to use it would be to encrypt an entire external USB drive (not even using a partition table on the drive), then prefill the drive with important data, and then never, EVER write any data to the drive after initially preparing it. Then only use the volume to refer to information as you need it. You can then tell an attacker that you bought a used drive to help you store extra data in case you needed more storage space, and that you made no modifications to the drive since you purchased it. They can then conclude that the original owner overwrote the drive with random data. If they take multiple snapshots of the drive over time, they will never see it change and can conclude that you haven’t reformatted the drive yet. You could potentially get away with writing data to the volume until the first time the attacker takes a snapshot, then use the volume read-only after that point. This requires that you know when the attacker takes the first snapshot though, which isn’t something you can guarantee if your attacker can gain unattended physical access to your machine.
(It’s also worth noting that “never write to the drive” is also tricky because some (most?) filesystems have metadata on them that gets changed just by mounting the filesystem. Even a read-only mount can result in data being written to the drive in some situations. It might be possible to use something like hdparm -r1 to set the drive itself into read-only mode, thus bypassing anything scary the filesystem could potentially do. But not all drives will necessarily work with that, and I imagine you might run into issues with some or even most USB drives since hdparm is designed to work with SATA and IDE drives. I wonder if Linux has a feature that allows you to set a device file itself into read-only mode irrespective of the underlying hardware…)
Plausible deniability of this kind isn’t really hard to achieve, it just requires careful implementation. I one time considered writing a tool that would allow you to store data on a USB drive in a plausibly deniable fashion, and made some good progress. I ended up abandoning it though for various reasons (one of them being that I was using Free Pascal to write the program, which turned out to be a bad choice given my lack of skill with Pascal.)
I’ve heard some people claim that if you use LUKS with a detached header and store the header on another drive, the drive containing the LUKS volume itself is now plausibly deniable. I have not verified this myself, and there’s an obvious problem with this, which you yourself mention:
Yes. To decrypt the LUKS volume, you have to have a copy of the header, which means you have to store the LUKS header for the drive somewhere. If someone abducts you and takes your laptop, they’re probably also going to take any removable media you have, and if they find your LUKS header file on one of those drives, they can now prove that you’re using drive encryption somewhere. If your internal drive looks like random noise, then they can be pretty sure that the LUKS header corresponds to that drive. If they find an entire boot partition on the same drive, they can be even more certain.