In my last post [here] I briefly mentioned looking for alternative mechanisms for attesting the state of my Novacustom NS51’s firmware and OS. A comment I recieved on neocities which im greatful for mentioned a common method of physical security specifically of the bootloader. Here is that comment.
“Have you considered an external bootloader w/ Qubes for your NovaCustom NS51? Chuck the bootloader on a flash drive (or CD-R if you have an external drive). FDE the rest, carry the bootloader around with you at all times. IIRC the bootloader needs to be left plugged in for dom0 updates, but otherwise only needs to be present during boot.”
A setup similar to this [archive] is something i’ve replicated in the past and had planned to attempt on QubesOS but I’ve since taken issue with this approach for a few reasons.
The reason I steered clear of an external bootloader was due to the complexities of usb devices. A [feature] the dasharo firmware comes with is the ability to complete disable the UEFI usb driver, this includes the ability to disable mass storage usb devices specifically or the entire usb stack altogether. Malicious firmware can exist on many mediums but I feel usb devices can be particularly harmful given they can behave as other devices. NVME and thunderbolt devices can also be especially dangerous due to DMA attacks but these vectors have protections like IOMMU though they are [imperfect]. I attempted to boot from an sdcard but unfortunately this machine can’t boot from sdcards in the micro-sd card slot, however the concern of malicious firmware still persists with micro-sd cards even if they are potentially less harmful.
This solution puts my host OS at risk of partitions hidden by malicious usb firmware that may contain malware (to name one example). It also requires I re-enable the USB stack at boot, which allows any usb to be booted from without authentication. Not forgetting to mention the added complexity of initial install of QubesOS and added fragility during system upgrades. I can’t see good reason to ignore the glaring faults in this method for minimal benefit.
Now onto the detached luks header portition of this post.
Luks with a detached header lacks the robustness of a dedicated deniable encryption system, online I see people opting to use this setup to achieve just that. This approach achieves plausible deniability by stripping the volume of identifiable metadata, making the encrypted data indistinguishable from random noise. This is unlike Veracrypt volumes which use decoy filesystems, multi-layered encryption and a header which is indistinguishable from random noise to mislead anyone snooping around. Luks as a plausibly deniable encryption system is inferior to Veracrypt, ShuffleCake and others like them.
Here is a section from the FAQ on ShuffleCakes website that aligns with my opinion and highlights the issue. Link to ShuffleCake [here].
Maybe you don’t know that LUKS already offers plausible deniability?
Depends how you define “plausible”, but nope. With LUKS you can do some… workaround. You can fill the disc with random data, make a bootable USB drive with your bootloader on it, make a LUKS header only file on that USB drive, and then create an encrypted filesystem on the disc using that detached header file. You’ll want to backup that header file, and possibly hide it with another encrypted volume using a headerless encryption on the USB drive. It’s guaranteed to work as long as both the USB drive and the disc stay inside the pentacle you just painted on the floor with black chicken blood. Kidding apart, we believe that this technique is just a placebo, something that can defend you against the lazy security guard who asks you to turn on your laptop at the airport (and there is better and simpler solutions for that), but will not have a chance to stand in court or under interrogation, since you are now basing your security on the assumptions that 1) the adversary will not find the physical USB dongle that you are suspiciously hiding in your underwear, 2) the adverary will not ask questions about a potentially large and unused partition in your laptop filled with random data, and 3) if suspicious, the adversary will only ask you one password and will be happy with it. This is a “poor man’s plausible deniability”, actually more similar to steganography than plausible deniability proper.
I find the initial idea of this configuration to be interesting, but it’s important to consider all aspects, to verify the configuration works, to properly understand all adjacent topics, and to not blindly fall into the trap of official sounding, complicated looking configurations that claim to achieve a goal. Veracrypt is far from perfect but unlike luks is designed with plausble deniability in mind.
If you decide to use a detached header make sure to use cryptsetup reencrypt /dev/[device] –new if you ever change your passphrase, using luksChangeKey wont generate a new master key in the key slot of your header, this means a bad actor with a copy of your old header which you’ve given swifter access to would be able to unlock your luks partition with your old passphrase.
If you find fault in anything in this post or any post I’ve made or ever will make, please let me know. If I can have my entire understanding of a topic meaningfully improved by someones wisdom I’d consider the post to be a success, and a rewrite would be put into the queue.
>> Home