linuxboot
Plausible deniability of encryption
Is this something that’s possible? I’m not sure if Heads requires attached LUKS headers but I think this would be a good feature that some individuals would benefit from.
@ZooWooHoo @rafaelreis-r can you give more info on what you would want?
Example. Heads boots. No /boot content/OS found? Then what?
FDE support? (duplicate issue).
Heads would do what?
Ask for a USB storage Luks header to load?
You would want the LUKS header to be completely stored under TPM? TPM 1.2? TPM 2?
Hidden partition?
Plausible deniability is a concept. With many many possibilities. But at the end of the day, an empty disk is hard to justify. So what would you want Heads to do to offer plausible deniability outside of offering a way to unlock LUKS with FDE, through TPM header release or through loading it from USB? But then not so plausible denied encryption where forensic would show data scrambled with high entropy on disk.
So let's go to basics. What plausible deniability of encryption means to you guys?
Thanks!
Plausible deniability in my mind means you can say you haven’t got around to installing an os.
I was under the impression an encrypted drive without LUKS headers would look like a blank drive (maybe freshly wiped) with random data (unpartitioned) to forensics.
I guess heads would ask for a USB with LUKS headers in the case the drive isn’t bootable on its own. That doesn’t help the plausible deniability but it also doesn’t prove the existence of hidden data as it would be normal heads behavior.
Basically, this feature would depend on Heads supporting full FDE (/boot inside of the LUKS container) which would need a bit of work.
Heads checks for valid /boot content on boot. Heads prompt when no OS is found is currently to install an OS by booting from USB. Once Full FDE is supported, that prompt would simply need to propose to the user to load an external LUKS header from a USB thumb drive, prior of validating the HOTP counter under /boot (to validate firmware integrity) or doing anything else, unlocking LUKS and then mounting /boot as normal and propose boot options. There should also be a menu option permitting to export that header on USB storage and then wipe it.
Note that the OEM factory reset menu/Re-Ownership stores the boot device name inside of the config.user overlay injected in ROM. That device name would probably need to be switched to UUID there, or the boot detection script modified to detect LUKS container mapped partitions and select it dynamically.
But yeah, first task here would be to support full FDE under Heads.
And then discuss the details of how this plausible encryption deniability feature should be seen for encryption deniability. But in my head, this is more additional data security than plausible encryption deniability as proposed in this issue.
A full forensic on the drive would most probably show discrepancies in entropy across regions of the disk, proving to the forensic analyser that the content of the drive was not wiped but that there is actually encrypted content there. And then by adding a prompt in the menus for loading a detached LUKS header would clearly show that possibility and the most plausible case here: drive contains encrypted material.
An interrogator would still request the release of that LUKS header and its passphrase. I understand the dream, the desire for such feature, but the truth here is that it won't really provide it if easy to use and where Heads would offer, for usability reasons, to load an external LUKS header and where that hint would push the auditor to clone the drive even more and look for that LUKS header. All thread models being valid, why not store that content encrypted on the cloud (self-hosted if needed) to download upon arrival, or again, travel without data that would prevent you to type your decryption passphrase if requested. The basic opsecs principles still prevails: if you think you will be asked to type a passphrase to decrypt your drive, you should minimize the content that can be extracted if under threat with a hammer. Encryption here provides privacy, added security and authentication. But plausible deniability with encryption normally requires hidden volumes and such, which would then happen on top of a booted OS. I think not having any OS installed is a big trigger at security screening. Having your disk shipped to destination might be a better idea. Or having the tools and data in the cloud might be a way better option then trying to hide a whole installation on top of Heads.
Thoughts/propositions?
Basically, this feature would depend on Heads supporting full FDE (/boot inside of the LUKS container) which would need a bit of work.
Heads checks for valid /boot content on boot. Heads prompt when no OS is found is currently to install an OS by booting from USB. Once Full FDE is supported, that prompt would simply need to propose to the user to load an external LUKS header from a USB thumb drive, prior of validating the HOTP counter under /boot (to validate firmware integrity) or doing anything else, unlocking LUKS and then mounting /boot as normal and propose boot options. There should also be a menu option permitting to export that header on USB storage and then wipe it.
Note that the OEM factory reset menu/Re-Ownership stores the boot device name inside of the config.user overlay injected in ROM. That device name would probably need to be switched to UUID there, or the boot detection script modified to detect LUKS container mapped partitions and select it dynamically.
But yeah, first task here would be to support full FDE under Heads.
And then discuss the details of how this plausible encryption deniability feature should be seen for encryption deniability. But in my head, this is more additional data security than plausible encryption deniability as proposed in this issue.
A full forensic on the drive would most probably show discrepancies in entropy across regions of the disk, proving to the forensic analyser that the content of the drive was not wiped but that there is actually encrypted content there. And then by adding a prompt in the menus for loading a detached LUKS header would clearly show that possibility and the most plausible case here: drive contains encrypted material.
An interrogator would still request the release of that LUKS header and its passphrase. I understand the dream, the desire for such feature, but the truth here is that it won't really provide it if easy to use and where Heads would offer, for usability reasons, to load an external LUKS header and where that hint would push the auditor to clone the drive even more and look for that LUKS header. All thread models being valid, why not store that content encrypted on the cloud (self-hosted if needed) to download upon arrival, or again, travel without data that would prevent you to type your decryption passphrase if requested. The basic opsecs principles still prevails: if you think you will be asked to type a passphrase to decrypt your drive, you should minimize the content that can be extracted if under threat with a hammer. Encryption here provides privacy, added security and authentication. But plausible deniability with encryption normally requires hidden volumes and such, which would then happen on top of a booted OS. I think not having any OS installed is a big trigger at security screening. Having your disk shipped to destination might be a better idea. Or having the tools and data in the cloud might be a way better option then trying to hide a whole installation on top of Heads.
Thoughts/propositions?
Unfortunately I'm very late to the discussion here, but veracrypt has a feature that allows someone to hide an encrypted partition inside another encrypted partition, thus hiding the entropy discrepancy. Is Heads only compatible with LUKS, or is there any support with VeraCrypt? I cannot find any mentions of veracrypt on the Wiki.
Basically, this feature would depend on Heads supporting full FDE (/boot inside of the LUKS container) which would need a bit of work. Heads checks for valid /boot content on boot. Heads prompt when no OS is found is currently to install an OS by booting from USB. Once Full FDE is supported, that prompt would simply need to propose to the user to load an external LUKS header from a USB thumb drive, prior of validating the HOTP counter under /boot (to validate firmware integrity) or doing anything else, unlocking LUKS and then mounting /boot as normal and propose boot options. There should also be a menu option permitting to export that header on USB storage and then wipe it. Note that the OEM factory reset menu/Re-Ownership stores the boot device name inside of the config.user overlay injected in ROM. That device name would probably need to be switched to UUID there, or the boot detection script modified to detect LUKS container mapped partitions and select it dynamically. But yeah, first task here would be to support full FDE under Heads. And then discuss the details of how this plausible encryption deniability feature should be seen for encryption deniability. But in my head, this is more additional data security than plausible encryption deniability as proposed in this issue. A full forensic on the drive would most probably show discrepancies in entropy across regions of the disk, proving to the forensic analyser that the content of the drive was not wiped but that there is actually encrypted content there. And then by adding a prompt in the menus for loading a detached LUKS header would clearly show that possibility and the most plausible case here: drive contains encrypted material. An interrogator would still request the release of that LUKS header and its passphrase. I understand the dream, the desire for such feature, but the truth here is that it won't really provide it if easy to use and where Heads would offer, for usability reasons, to load an external LUKS header and where that hint would push the auditor to clone the drive even more and look for that LUKS header. All thread models being valid, why not store that content encrypted on the cloud (self-hosted if needed) to download upon arrival, or again, travel without data that would prevent you to type your decryption passphrase if requested. The basic opsecs principles still prevails: if you think you will be asked to type a passphrase to decrypt your drive, you should minimize the content that can be extracted if under threat with a hammer. Encryption here provides privacy, added security and authentication. But plausible deniability with encryption normally requires hidden volumes and such, which would then happen on top of a booted OS. I think not having any OS installed is a big trigger at security screening. Having your disk shipped to destination might be a better idea. Or having the tools and data in the cloud might be a way better option then trying to hide a whole installation on top of Heads. Thoughts/propositions?
Unfortunately I'm very late to the discussion here, but veracrypt has a feature that allows someone to hide an encrypted partition inside another encrypted partition, thus hiding the entropy discrepancy. Is Heads only compatible with LUKS, or is there any support with VeraCrypt? I cannot find any mentions of veracrypt on the Wiki.
no veracrypt is not supported
Nobody is saying what it would/should look like to them since the opening of this issue.
Random data on drive would tilt forensic.
Praxtically: What heads should be doing when no partitions found on drives, outside of what it's doing now and prompts user to boot from usb?
Please help me help you. This issue is stalling without useful input.
What would you want heads to do? What would it change that it supports veracrypt? Why would it help to have random data on disk and why would that be plausible deny ability of encryption? Where is that thought coming from?
Nothing will happen here without a clear use case. Need. Desire. Goal.
@ZooWooHoo @rafaelreis-r can you give more info on what you would want?
Example. Heads boots. No /boot content/OS found? Then what?
FDE support? (duplicate issue).
Heads would do what?
Ask for a USB storage Luks header to load?
You would want the LUKS header to be completely stored under TPM? TPM 1.2? TPM 2?
Hidden partition?
Plausible deniability is a concept. With many many possibilities. But at the end of the day, an empty disk is hard to justify. So what would you want Heads to do to offer plausible deniability outside of offering a way to unlock LUKS with FDE, through TPM header release or through loading it from USB? But then not so plausible denied encryption where forensic would show data scrambled with high entropy on disk.
So let's go to basics. What plausible deniability of encryption means to you guys?
Thanks!
i think maybe heads could prompt to insert a media containg the boot partition if no such partition is found i dont know about supporting veracrypt or encrypted boot but maybe allowing detached luks headers that could also be prompted for insertion could be a thing
sure there is a hugh blob of probably encrypted data but it does not have to be encrypted data is this not plasuable denability until they find the external media with the boot partition and or luks headers?
making forensic investigators raise an eye brow is probably not enough to disprove the supposed statement that there is no encrypted data cause provably there is not provably there is only data that looks encrypted but without any headers it would be impossible to prove this data is not just the output for dd if=/dev/urandom of=/dev/sdx