I don’t think I follow a lot of what people are saying on installing LUKS with a detached header. Yes, if my header lives on a USB there’s effectively no way to figure out much about the partition (I believe dmcrypt has some metadata leakage but that can be dealt with).
What I want is a Veracrypt-esque FDE setup: a LUKS encrypted disk with the header file on disk (which doesn’t look very suspicious), and then a hidden partition/container (in which I either run an entirely different OS or just keep to run disp VMs on), with the header for the second partition/container on a USB which I won’t carry with me when crossing borders.
Obviously, this means that the hidden partition must not be visible with forensic tools. I do not think that the guides talking about LUKS encrypted headers on a different drive take this into account. Unfortunately I’m too much of a Linux noob to do this myself so I’m asking the community for help. How do I keep a hidden partition on a LUKS encrypted drive?
I thought it could be done with LVM, i.e. a hidden volume using LVM on top of LUKS (so when someone takes an image of the drive, all they see is gibberish without the password), and when looking inside they cannot see any trace of the “hidden LVM”,
My threat model doesn’t include preserving the material in that hidden partition against duress - if they want to wipe my drive they can feel free to do so.
What do you think I should do?
I might have to go through a situation similar to what I describe here at some point.
You can use offset LUKS option for this.
Install the “dummy” OS using the first N GB of the disk without detached header.
Then install the “hidden” OS using the remaining space after N GB with a detached header and boot partitions on a USB.
So when you boot without USB connected you’ll boot into the “dummy” OS and when you connect USB and boot from it you’ll boot from the “hidden” OS.
--offset, -o <number of 512 byte sectors>
Start offset in the backend device in 512-byte sectors.
The --offset option sets the data offset (payload) of data
device and must be aligned to 4096-byte sectors (must be
multiple of 8). This option cannot be combined with
--align-payload option.
It’s the same for VeraCrypt.
You can also create the outer volume like in VeraCrypt e.g.:
partition 1 - 64 GB - decoy OS
partition 2 - the rest of the free space - unencrypted FAT32 volume with up to 10 GB of some non-sensitive files. Don’t write more than 10 GB of data on it.
Create the LUKS partition with 74 GB offset on the disk.
Maybe you can find a better way to create an outer volume if you search for it.
With Veracrypt Hidden Volumes or your method you can still see the disk size. i.e 500GB and then see only 200GB on the decoy, so what about the rest? The advantage of detached LUKS Header (without trim) is it all still looks like random noise, so its easier to say it has nothing on it, and then boot from a usb live os or something similar. Its also simpler. AFAIK there is no way to get around the missing space connundrum. Atleast with detached header you can say the partition was just wiped which would look more realistic than a mystery missing xGB.
I would also add that you can encypt and put the header in the cloud or something, therefore its not linked to a password (rubber hose) and could be out of your person even, which would be better deniability.
I tried Shufflecake actually, from the codeberg. It kinda worked. It looks like a good idea.
You have layered hidden volumes from least to most secret. Each password unlocks a deeper layer.
I went back to a detached header for the same reasons I mentioned.
I would like to know how a real forensic expert sees these various approaches, what do they look for, what are the flags, methods and analysis techniques.
It is a big subject, deniable encryption and without knowing those intricacies I worry that a lot of this could be just security theater.
