Authenticated Boot and Disk Encryption on Linux • Hacker News Board

Re: Authenticated Boot and Disk Encryption on Linux

#71

Post by rcthompson » Thu, Sep 23, 2021, 1:33 PM UTC

markjenkinswpg wrote: post #56

phh wrote: post #32

Every time I read stuff about secure boot, "evil maid" attack scenarios come up. And every time, they fail to mention the easiest one. The attack described here involves dismantling the victim's hard drive. I have an attack that isn't defeated by secure boot, and doesn't even require dismantling anything. Steal the original laptop. Take another physically identical unit. Replace it. Copy the login screen of original…

The solution is to use an HSM such as the Nitrokey/Purism Librem Key (same thing) that has a LED that lights up if boot integrity is fine, including a TPM secret matching (maid can't clone that). https://www.youtube.com/watch?v=O_3Xf3gTzEE https://www.youtube.com/watch?v=K1O-33pi33M https://www.youtube.com/watch?v=SB82Ul_A1js

This is essentially the same solution, right? It boils down to having a single device that verifies the integrity of everything and never letting that device out of your sight. It's just marginally easier to do that when the device in question is an HSM rather than a laptop.

Re: Authenticated Boot and Disk Encryption on Linux

#72

Post by lifeisstillgood » Thu, Sep 23, 2021, 1:34 PM UTC

nsajko wrote: 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…

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

Re: Authenticated Boot and Disk Encryption on Linux

#73

Post by dbrgn » Thu, Sep 23, 2021, 1:36 PM UTC

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.

Instead of attacking the person (ad-hominem), how about discussing the technical merits and deficiencies of the proposed solution to a real problem that no Linux distro has tackled so far?

I'm sure the NSA is happy about unauthenticated initrds. I'd be very surprised if such manipulation was never used in practice.

Re: Authenticated Boot and Disk Encryption on Linux

#74

Post by lugged » Thu, Sep 23, 2021, 1:37 PM UTC

nsajko wrote: post #70

SkyMarshal wrote: post #68

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.

Does this matter?

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

Re: Authenticated Boot and Disk Encryption on Linux

#75

Post by lugged » Thu, Sep 23, 2021, 1:38 PM UTC

lifeisstillgood wrote: post #72

nsajko wrote: 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…

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.

Re: Authenticated Boot and Disk Encryption on Linux

#76

Post by mkj » Thu, Sep 23, 2021, 1:42 PM UTC

lifeisstillgood wrote: post #72

nsajko wrote: 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…

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?

Re: Authenticated Boot and Disk Encryption on Linux

#77

Post by phh » Thu, Sep 23, 2021, 1:44 PM UTC

Foxboron wrote: post #58

phh wrote: post #47

Earlier quoted context omitted.

You know the scratches on the chassis of your laptop? I definitely don't. If someone replaces my laptop with a brand new one, I'll notice something is off, but I wouldn't be surprised I'd notice /after/ typing my password. If rather than brand new, it's replaced another laptop with approximately same age/usage, I would most definitely not notice. > I assume you don't know about the nail-polish with glitter based prot…

>But okay, you may extend my attack by saying that you exchange the motherboard between the victim and the attacker laptop, so that you don't need to replicate the chassis. Modern computers has tamper detection and if you open them you'll need to type the BIOS password. However, replacing the motherboard is going to replace the TPM. This is easily detectable with something like tpm2_totp in the bootchain. https://git…

Now we're talking proper security, thanks.

> Modern computers has tamper detection and if you open them you'll need to type the BIOS password.

Is that somehow configurable from Linux distribution's setup, or it will require user to manually set a BIOS password? (and it requires the user to set a different bios password. if the user sets the same password for fde and for bios, then back to square 1)

> However, replacing the motherboard is going to replace the TPM. This is easily detectable with something like tpm2_totp in the bootchain.

That sounds interesting. Though it still sounds totally impossible for the vast majority of users.

At that point, I don't really know what's the goal of TFA. If it's for extreme power users who want best security, it is missing the various counter-measures mentioned in this thread. If it's about pushing distributions to have better defaults, then I think it's quite moot, because secure boot won't improve security much to average users.

Re: Authenticated Boot and Disk Encryption on Linux

#78

Post by nsajko » Thu, Sep 23, 2021, 1:50 PM UTC

lifeisstillgood wrote: post #72

nsajko wrote: 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…

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

Firstly, you'd probably want to make backups of the USB device with the initrd, in case one of them fails.

To mount the decrypted disk during boot, it's necessary to make the kernel aware of the fact that it's something that should be mounted. There are several ways to do this, two of which are:

1. The most preferable way, I think, would be to use something like kpartx from multipath-tools. Kpartx is a very simple C program, and device mapper is used directly in that case. You could also use partprobe. So the command is something like `kpartx -a disk` or `partprobe disk`.

2. Another option is to use LVM, like described here: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti... (there are also other encryption options described there). Using LVM is a solution that works more out-of-the-box, but, of course, then you always depends on LVM, which may not be something you want.

Re: Authenticated Boot and Disk Encryption on Linux

#79

Post by guipsp » Thu, Sep 23, 2021, 1:50 PM UTC

lugged wrote: post #74

nsajko wrote: 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. Whether this matters for you or not depends on your use case.

Re: Authenticated Boot and Disk Encryption on Linux

#80

Post by Foxboron » Thu, Sep 23, 2021, 1:51 PM UTC

phh wrote: post #77

Foxboron wrote: post #58

Earlier quoted context omitted.

>But okay, you may extend my attack by saying that you exchange the motherboard between the victim and the attacker laptop, so that you don't need to replicate the chassis. Modern computers has tamper detection and if you open them you'll need to type the BIOS password. However, replacing the motherboard is going to replace the TPM. This is easily detectable with something like tpm2_totp in the bootchain. https://git…

Now we're talking proper security, thanks. > Modern computers has tamper detection and if you open them you'll need to type the BIOS password. Is that somehow configurable from Linux distribution's setup, or it will require user to manually set a BIOS password? (and it requires the user to set a different bios password. if the user sets the same password for fde and for bios, then back to square 1) > However, replaci…

>Is that somehow configurable from Linux distribution's setup, or it will require user to manually set a BIOS password? (and it requires the user to set a different bios password. if the user sets the same password for fde and for bios, then back to square 1)

Not yet? And when I said "modern computers" i should probably clarify I'm thinking about more enterprise grade computers. Such as Thinkpads.

Thinkpads also recently got the feature to set the password from Linux userspace. But I forget where I read that, and where the patch is located :)

>That sounds interesting. Though it still sounds totally impossible for the vast majority of users.

It is. But this is why threat modelling is important. If a realistic threat scenario is someone replacing your motherboard, then tpm2_totp should be something you setup.

Listing all possible attack scenarios and assuming any generic distribution protect fully against them is a pipe dream. There needs to be some compromise between usability and security.