Live data from Hacker News

Authenticated Boot and Disk Encryption on Linux

0pointer.net

81–90 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#81
post #76

Earlier quoted context omitted.

do you have any more details. My first thought is "how simple" then "what am I missing"?

Have to lug a usb stick around with you and guard it 24/7 for equivalent security?

Not necessarily. If this is for a desktop computer you can just leave the USB plugged in and the computer running, as normal. The threat model isn’t too different between that and a normal home/office computer - in both cases you have to trust the physical security of your home/office.

For a laptop, you’re already lugging it around anyway, just remove the USB drive whenever you shut it down.

Re: Authenticated Boot and Disk Encryption on Linux

#82
post #22

An option that wasn't at all considered in the article is to have the initrd and (optionally) the secret key used for decrypting the disk on a separate device (or devices), for example on an 1 GB USB drive. This way the big disk can have full, real FDE (not LUKS). To an attacker not in possesion of the USB drive the big disk just looks like random data. And the USB drive can be kept on one's own person and easily des…

Clevis/Tang ("network-bound disk encryption") is likely better: https://www.redhat.com/en/blog/easier-way-manage-disk-decryp...

Re: Authenticated Boot and Disk Encryption on Linux

#83
post #75

Earlier quoted context omitted.

do you have any more details. My first thought is "how simple" then "what am I missing"?

(slightly) slower boot time. Risk of data loss if your USB fails, more complicated backup procedures.

Yes, you should use a higher quality USB drive for this, or possibly an SLC NAND one with high write endurance. And make a backup copy or two and store them in faraday bags in a safe.

Re: Authenticated Boot and Disk Encryption on Linux

#85
post #79
post #74

Earlier quoted context omitted.

Does this matter? I once went through the waste of time of getting /boot encrypted. Would rather avoid needless pain.

It matters for deniability. Whether this matters for you or not depends on your use case.

What does a laptop with a bunch of random data on its disk and a lot of evidence of use (grime, worn keys, etc.) let you deny that the same laptop with a generic Linux boot partition followed by random data does not let you deny?

Re: Authenticated Boot and Disk Encryption on Linux

#86
post #74
post #70

Earlier quoted context omitted.

LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.

Does this matter? I once went through the waste of time of getting /boot encrypted. Would rather avoid needless pain.

It matters for deniability and for reliability. If you have LUKS, you really don't want to corrupt the header.

Re: Authenticated Boot and Disk Encryption on Linux

#87
post #76

Earlier quoted context omitted.

do you have any more details. My first thought is "how simple" then "what am I missing"?

Have to lug a usb stick around with you and guard it 24/7 for equivalent security?

I use a datatraveler 2000 to store my kernel+initrd, only inconvenience is having to unlock and insert it whenever I boot my laptop.

If I use the keyfile feature, the dt2000 boot will automatically unlock my FDE, making the inconvenience a bit of a wash with arguably improved overall security. It's also nice that I can unlock the dt2000 in private or otherwise independently from the laptop, since it has a battery. Think bathroom break to unlock, insert to boot on return kind of thing. It also supports a read-only mode, requiring switching to writable whenever updating the kernel/initrd.

Re: Authenticated Boot and Disk Encryption on Linux

#88
post #75

Earlier quoted context omitted.

do you have any more details. My first thought is "how simple" then "what am I missing"?

(slightly) slower boot time. Risk of data loss if your USB fails, more complicated backup procedures.

There's nothing hard to replace in a kernel or initrd, it's just a matter of going back to the trusted source you originally used.

Re: Authenticated Boot and Disk Encryption on Linux

#89
post #85
post #79

Earlier quoted context omitted.

It matters for deniability. Whether this matters for you or not depends on your use case.

What does a laptop with a bunch of random data on its disk and a lot of evidence of use (grime, worn keys, etc.) let you deny that the same laptop with a generic Linux boot partition followed by random data does not let you deny?

Let's put it this way: say you want to prevent somebody from getting the data on a disk. Wouldn't writing random data over the entire disk be a good idea?

Re: Authenticated Boot and Disk Encryption on Linux

#90
post #70

Earlier quoted context omitted.

> This way the big disk can have full, real FDE (not LUKS). I thought LUKS was the only way to do FDE in Linux. What other options for FDE are there? But yes, putting /boot on an external USB drive is the only way I know of get FDE on your hard drives. Possible with UEFI, not BIOS/MBR.

LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.

Huh, I thought BIOS/MBR required /boot to be on a partition at the beginning of the MBR and nowhere else, whereas UEFI allows it to be anywhere on the disk as long as its labeled with ESP.

So with UEFI, you just label /boot on USB as ESP. How does it work with BIOS/MBR?

Post reply on HN