Hacker News Reader

Comment by adrian_b | Hacker News Reader

Because of things like those described by you, I have never trusted bootable encrypted SSDs/HDDs.

In my computers, I have only non-bootable and non-partitioned SSDs/HDDs, which are completely encrypted with a random 256-bit key, so as long as an attacker has only access to the computer, for instance to a stolen laptop, there is absolutely nothing that can be done to gain access to the stored data.

To boot the computers, I use a small and inconspicuous USB memory containing the boot loader and the kernel, from which the encrypted SSD is mounted and then pivot_root is executed to replace the USB memory with the encrypted SSD as the root device, and then the USB memory is removed and it is not used during normal operation.

The USB key contains an encrypted form of the SSD encryption key, requiring the entering of a passphrase after the kernel has booted, but before mounting the encrypted SSD.

View on HN

While cool/interesting, i'm failing to understand the attack your protecting against here in the context of just prompting for an unlock PIN.

Particularly if that unlock pin is for a FIDO key or whatever which can also be removed.

I mean, if someone steals your backpack, or stops you at the border, breaks into your house, whatever, they are getting the boot image too, right?

Furthermore, are all your machines AMD Pro or equivilant (with the encrypted RAM enabled)? Because the disk encryption key is probably just sitting unencrypted in system RAM otherwise, and is susceptible to people freezing the ram and removing it to another machine to extract the keys.

The attacks "evil maid" described by a poster above are impossible.

Even with physical access, the computer does not have any boot loader or kernel or any other executable that could be altered.

The attack described in the thread title also does not work, because the computer cannot boot. Even after booting from their own device, attackers cannot do anything useful. Reading the encrypted SSD will not provide any information and writing it will be detected later. The SSD does not have any non-encrypted sector.

Obviously I do not keep the USB key with the computer, especially when the computer is not with me. It is never put in the computer backpack.

Of course, if someone would watch me to discover how I start the computer and then they would capture me with all my belongings and then they would do a thorough search they might find the key and they might torture me to get the passphrase.

Nevertheless, against this kind of threats, there are no computer solutions. The only thing that would work would be the use of armed guards.

On the other hand, my method is not vulnerable to trivial attacks that could be done without my knowledge, like the one described in the thread title.

Sounds like a great option. Would be nice if there was an install wizard that could configure that.

Ps I wonder what inconspicuous usb drive you use?

I use various Corsair or Kingston USB flash drives, with sturdy fully metallic cases, and which are just a little larger than a USB connector, i.e. they just have an ear that remains outside the connector when inserted, to allow for their extraction.

An example:

https://media.kingston.com/kingston/key-features/ktc-keyfeat...

I have also used MicroSD cards together with a very small USB adapter, which is also only a little greater than the USB connector.

Are you still using LUKS for these? How are you invoking decryption with the pass phrase protected key?

I am not using LUKS, I am using a custom kernel module that implements a block device that presents to the kernel the decrypted SSD. The kernel module receives the key when it is loaded, then it creates the block device that is eventually mounted as the new root device.

I do not know if LUKS could be used for this, I have not examined it. IIRC, LUKS stores the actual decryption key in the encrypted disk (protected by a passphrase) or in the TPM, like most commercial products for disk encryption, which are methods that I do not approve.

LUKS supports detached headers, maybe this would be useful for your setup? https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encryp...

Your approach sounds pretty cool, by the way. I've thought about such an approach in the past, and I've used it for some auxiliary computers under my control, but not for my daily driver. I have a Framework laptop and I could indeed use this approach in quite a stylish way, though: https://frame.work/de/en/products/storage-expansion-card?v=F...

Thanks for pointing to this LUKS feature.

The last time when I have looked at LUKS was some years ago, when this feature did not exist yet.

In my opinion, this is the only right way to do SSD/HDD encryption. The detached header allows plausible deniability and it avoids downgrading the strength of the encryption key to the strength of the passphrase.

By using the detached header option, LUKS could be used exactly like in my custom setup.

Reply on news.ycombinator.com