Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Authenticated Boot and Disk Encryption on Linux

0pointer.net

Post reply on HN
Print view View original

21–30 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#21

Post by snassar »

BiteCode_dev wrote: post #14

Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.

The better solution to these kind of problems is having a backup concept with an implementation and regular testing of backups.

The encryption exposed a problem with your disks or system in general. Depending on what the problem was, the problem is still there but you are not seeing it. Now you have a possible problem and unencrypted files.

Re: Authenticated Boot and Disk Encryption on Linux

#22

Post by nsajko »

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 destroyed if necessary.

The main part is having the initrd on an external, small, device. The secret can be either a regular passphrase, or stored somewhere on the small device.

Works fine on my Archlinux. I mount the initrd file system to /boot when I need to update it.

Re: Authenticated Boot and Disk Encryption on Linux

#23

Post by kevincox »

bloopernova wrote: post #15

Is it possible to set up an encrypted+authenticated boot that relies on a hardware token being present? In other words, only boot this OS if the Yubikey is inserted?

It definitely is. The easiest way is to set up the token in challenge-response mode (supported by yubikey). The disk has a key which is sent to the token and the response is used to decrypt the disk.

Re: Authenticated Boot and Disk Encryption on Linux

#24

Post by maverwa »

bloopernova wrote: post #15

Is it possible to set up an encrypted+authenticated boot that relies on a hardware token being present? In other words, only boot this OS if the Yubikey is inserted?

According to the docs ([0], [1]) systemd-cryptenroll and crypttab support FIDO2 and PKCS#11, both should be supported by the yubikey as well.

So without having tested it: I think yes, it should generally be possible, at least for encryption.

[0]: https://www.freedesktop.org/software/systemd/man/crypttab.ht... [1]: https://www.freedesktop.org/software/systemd/man/systemd-cry...

Re: Authenticated Boot and Disk Encryption on Linux

#25

Post by nsajko »

bloopernova wrote: post #15

Is it possible to set up an encrypted+authenticated boot that relies on a hardware token being present? In other words, only boot this OS if the Yubikey is inserted?

See my top-level comment. Just put the initrd and secret on the external device.

Re: Authenticated Boot and Disk Encryption on Linux

#27

Post by fmajid »

sam_lowry_ wrote: post #8

After taking over the process #1, Lennart Poettering decided to go deeper and take over kernel, initrd and bootloader. I sometimes wonder whether he is on the NSA payroll. Lennart Poettering and Moxie Marlinspike are two people NSA should really strive to buy and/or intimidate.

Signal is partly funded by the US government:

https://www.opentech.fund/results/supported-projects/open-wh...

Re: Authenticated Boot and Disk Encryption on Linux

#29

Post by egberts1 »

I only wish that package maintainers (outside of OS distro) installed directly directly into /usr/local/bin but instead they wanted “in” on the /usr/bin placement. So, We lost there as this would have facilitated secondary signing of non-OS packages by OS distro.

Doesn’t help when Fedora started muddling (merging) /bin and /usr/bin. So, secondary signing for non-OS vendors just went out the window. https://freedesktop.org/wiki/Software/systemd/separate-usr-i...

Even systemd is just now complaining about that during boot up (if the /usr partition somehow got invalidated during bootup).

This multi-tiered */bin is that hallmark of Unix (and continuously the (Linux Filesystem Standard https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf ).

— Althou, systemd designer seems to disagree with this LFS approach. (IMHO, he needs to look deeper into the overall aspects of package signing architecture by OS-distros, and not just for Fedora) https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

Now if Debian would just arrest the slide into a singular binary directory, all would be good.

Linux Distros are about to be ignoring this future need of multi-island/multi-signing of encryption/immutability.

No embedded Linux distro should want to be Windowized, much less the desktop Linux, unless they too seek this single island approach for immutably-verified/encrypted binaries of OS, vendors, and customers.

Re: Authenticated Boot and Disk Encryption on Linux

#30

Post by kevincox »

Nextgrid wrote: post #18
cesarb wrote: post #12

On a quick skim, I could see three issues with this proposal: 1. While each home directory is individually encrypted, since /home itself is not encrypted (unlike with current uses of full disk encryption), the user login names can be found unencrypted on the disk. 2. Since each home directory is individually encrypted, backup systems like borgbackup running as root can no longer easily backup everything. 3. As far as…

> backup systems like borgbackup running as root can no longer easily backup everything If you’re using LUKS-encrypted volumes for home directories nothing prevents you from enrolling an extra key file entrusted to the backup program, or to the TPM (which the backup program can be allowed to access).

But that defeats the whole point as now decrypting the system is enough to access all of the home directories. You are basically back to a FDE home partition with extra complexity.
Post reply on HN