Plausible Deniability / Unallocated space

Support
1

Installed kicksecure ISO with full disk encryption on virtual box, but Gparted shows a small unallocated space at the end of the drive .

What is the purpose of unallocated space .
How to prevent the installer from creating it.
Historical data might be left in it .

2

What is the purpose of unallocated space .

None, that I am aware of.

How to prevent the installer from creating it.

Users cannot do this. Unsupported.

Would require a developer contributing to calamares (and maybe by extension to partitioning tools and whatnot). This might be difficult digging into partitioning stuff. Might even not be calamares issue but general partitioning issues.

Unless you do it or pay someone (not me) to do it the chance of this ever changing is extremely small.

Historical data might be left in it .

Even overwriting might not delete it. Forensics is a difficult topic. See:
Advice for Solid-state Drives and USB Storage

How to avoid this issue? Never store data unencrypted. Always use:

3

Thanks,

I’ve comprehensible read the whole documentation about FDE.

Full means the whole drive should be used without exception .

Maybe even FDE data could be leak into unallocated space

For example,

Debian Luks on LVM results in non creation of free space luks2.

Debian live calamares installer also won’t create free space luks1 if i remember.

I will test another install options on debian without lvm and see how it works.

4

I don’t know the exact reason for this unallocated space currently, however I highly suspect it’s because of how the GUID Partition Table (GPT) disk structure works. Disks that are GPT-partitioned have two partition tables, a primary one at the start of the drive, and a backup one at the very end of the drive. The GPT table is about 16 kilobytes in size.

It’s also possible this is related to partition alignment - disks perform faster if you make sure that partitions start and end at particular locations on the disk, and sometimes a little bit of free space has to be left in order to make that happen.

It is extremely unlikely any unencrypted data would leak into the unallocated portions of the disk. There’s no reason for the LUKS code to write unencrypted data anywhere except volatile memory (i.e. RAM), and it would be a fatal security flaw for it to do so. There are also all sorts of problems that would occur with code that wrote data into unallocated disk space by design (i.e. what would the code do if there wasn’t unallocated space to use, or what about disks where the unallocated space actually is used, for instance by the system bootloader?), so it would be pointless, insecure, and a usability nightmare for LUKS to do that.

2 Likes
5

Unlike veracrypt hiden system

In case of luks detached header, might these spaces defeat the prupose of plausible deniability to prove that the disk is an encrypted disk

Could be used to measure file randomness.

Otherwise lvm with luks seems better in partitioning

Otherwise i dont know how to propely achieve plausible deniabilty with linux system compared to filesystem.

Think of journalists living in non democratic countries,where human rights abuses.torture etc.

6

Me neither. Also unlikely to materialize. See Plausible Deniability - Deniable Encryption, which has been updated just now.

7

According to google search its very debatable
Still confused about meaning of plausible deniabilty
Why its hard to achieve
Are luks encrypted system drive with external boot and header suspicious ?

I hope for clear easy explanation with sample scenario insteed of high academic language used in doc and cryptsetup faq 5.2 ,5.8 that could lead to false understanding.

8

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.

9

Also, some worthwhile reading: FAQ.md · main · cryptsetup / cryptsetup · GitLab See the section “What about Plausible Deniability?”

10

First, why should “I do not have a hidden partition” be any more plausible than “I forgot my crypto key” or “I wiped that partition with random data, nothing in there”? I do not see any reason.

Because if someone is traveling with 1 notebook (or only owns 1 notebook) then “I wiped that partition with random data, nothing in there” is less credible than “I do not have a hidden partition”. This is because people usually don’t like traveling with broken notebooks.

To illustrate this point further, consider a traveling group of 5 attendants to an IT conference. They all traveling with unbootable notebooks which they just wiped with random data while keeping their bootloader (and /boot partition) intact? Possible but incredible.

Unfortunately “plausible deniability” also means you cannot prove there
is no hidden data.

That’s why plausible deniability is a scary feature to implement. Because then those not using it cannot prove they don’t have one except by creating an empty/skeleton way.

Unfortunately that is also glaringly obvious, as you then cannot write
to the filesystem without a high risk of destroying data in the hidden
container.

TrueCrypt solved that with a “protect hidden volume” feature, where the user needed during normal operation to always enter both passwords, one for the normal/decoy volume and one for the hidden volume.

Have not written anything to the encrypted filesystem in a
while?

That’s why the concept of a decoy volume is flawed. It would need to be frequently enough used to leave enough of a usage pattern to be credible later that it is an actively used operating system or volume.

A better concept would be frequently using the “normal” volume. And then only place high risk files in the “hidden” volume.

To be fair, if you prepare option b) carefully and directly before going
into danger, it may work. But then, the mere presence of encrypted data
may already be enough to get you into trouble in those places were they
can demand encryption keys.

Yes.

  • A) Those not using hidden volume: indefinite torture because there is no hidden volume to physical abuse.
  • B) Those using hidden volume: given up both normal and hidden volume due to physical abuse.

Here is an additional reference for some problems with plausible
deniability:
https://www.schneier.com/academic/paperfiles/paper-truecrypt-dfs.pdf
I strongly suggest you read it.

In summary, there are a lot conceptual challenges, let alone technical implementation challenges.

11

Excellent, I’ll get back to you soon.
Thanks for helping.