You know there are great things that have been discussed/mentioned in the other thread called “BusKill” which shreds the LUKS header. Which leads to the data being useless due to it being no different then random data forensically.
Instead of that it would be better if Kicksecure developed the feature and option when selecting Full Disk Encryption via LUKS at installation. To have the option to detach the LUKS header and store it on another device whether that be a USB, SD Card, Smart Card, Yubikey, Nitrokey, etc.
The main development would be the integration into Grub as it would have to ask for device or detect a saved device that has the luks header aswell as ask for the passphrase. The other integration would be into the graphical installer (e.g. Calamares) for selecting such a option.
Currently there is no option to set up a Linux install with FDE and a detached header. However this implementation would greatly servers and personal computers alike.
Enhanced Security: – By separating the header from the encrypted data, users can reduce the risk of unauthorized access to their encrypted storage.
Flexibility: – Users can choose to store the header in a more secure location, such as a different device or a secure cloud storage solution.
Improved Usability: – This feature would cater to advanced users who require additional security measures for their sensitive data.
Plausible Denial: – By using a detached header, users can claim that the encrypted storage contains random data, as the absence of the header makes it impossible to decrypt the contents without the correct key. This provides a layer of plausible deniability, as users can assert that they do not possess the means to access the data.
This is probably feasible, though I can’t say if it’s something that I’ll definitely work on or not. Some notes:
Kicksecure doesn’t use GRUB to unlock encrypted disks. This is because we use Debian’s GRUB, and Debian’s GRUB only has very bad LUKS support (only supports LUKS1, can’t handle non-US keyboard layouts, ugly, slow, only gives you one shot to unlock the drive, and then the Linux kernel has to unlock the drive again once it boots). Instead, we use an unencrypted /boot partition and let the initramfs handle decrypt. This lets us use more secure encryption, provides a better user interface for decryption, works with multiple keyboard layouts, and works faster.
Plausible deniability should not be relied upon unless you know exactly what you’re doing. It’s well known that such a thing exists, and it’s pretty uncommon for people to have a random block of “unallocated” (or allocated-but-unformatted) space on their disk. If you’re in enough danger to consider needing plausible deniability, you’re in enough danger for even random data to look suspicious if it’s at all unusual.
Yeah but even if you have the passphrase, without having the luks header its useless and close to impossible to get the data.
It might make more sense, at least easier for this to be a implementation for a encrypted $HOME folder or another partition rather then the full disk and file-system.
It is highly unlikely that the Kicksecure project will work on this. It’s not on the roadmap (such as Kicksecure Security Roadmap) which we’ll have our hands full with for the next years. Wiki chapter Community Feedback applies.
If you want to see this feature materialize, I recommend to request this feature from other projects and/or working on it yourself.
The openSUSE package for this boot loader contains more than 200 patches. Some of those patches are there for the last 5, 6 … 10 years. That is both an indication of the talent of the maintainers, but also can signal an issue in how slow the upstream contribution process can be.
Yeah but how is detached header any different then shredding the LUKS header? The only difference I see is there is no need to shred the LUKS header as long as you fully shutdown your computer.
Although in a emergency situation shredding the LUKS header would work better since you would have no way to ditch device that had the header on it in time. Unless it was a SD Card you could eat it lol.
The detached header with LUKS seems like a good way to secure a machine that is stored away.
Would it even be possible to store the header on a Yubikey or Nitrokey?
I’m not sure but those two I believe you can set up to unlock LUKS with already. Someone correct me if I’m wrong?
The issue I do see with those two is that you can only order them online and for some threat models that may not be feasible or worth the risk to take.
en.wikipedia. org/wiki/Equation_Group#Firmware
However SD Cards, USB drives, and CD’s are readily available in most stores that sell computer electronics. Supply chain attacks are another factor to take in mind also.
I found a forum post where a user claims they achieved something that looks like this proposition.
[SOLVED] GRUB Boot LUKS Partition Using Detached Header
Thanks that looks like it might be good starting point for me to look into.
It is highly unlikely that the Kicksecure project will work on this. It’s not on the roadmap (such as Kicksecure Security Roadmap) which we’ll have our hands full with for the next years
Ok no worries very understandable I get that. This is just something that has been on my mind for awhile now and thought I would share here since BusKill was mentioned.
Yeah its a shame about the GRUB upstream development being slow, another reason kinda why I wanted to share this idea here.
