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

51–60 of 214 posts

Re: Authenticated Boot and Disk Encryption on Linux

#51

Post by egberts1 »

amarshall wrote: post #42
egberts1 wrote: post #29

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://freedeskto…

The problem is: where is the line drawn? Everything (and I mean everything) in many Linux distros (including Fedora) is just a package. There’s no base system, unlike in most BSDs. Further, each of those packages can (and often are) updated independently of each other, confounding somewhat attempts at signing the root of that hierarchy. macOS signs the whole base system, but that also means that updating a single bit…

Yes, initd is essentially a clone of /bin, et al.

Initd’s /bin probably is going to be needing to be signed differently from main root mount point.

Re: Authenticated Boot and Disk Encryption on Linux

#53

Post by Foxboron »

g_p wrote: post #36
Foxboron wrote: post #9

Earlier quoted context omitted.

In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware. All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't…

An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs? If so, you should be able to whitelist their sha256 hashes in your DB database, since the DB can contain an allow-list of hashes, as well as an allow-list of public keys. I'm not familiar with how to view relevant Option ROMs, but if you can "dump" them in the format they will be verified in, you shou…

sysfs doesn't like some optionroms, so using the rom files from there wont work in some cases. Apparently they can be stored in an ACPI table.. but I haven't looked at it.

Another alternative is to read the TPM2 eventlog. It should record OptionROM checksums found during boot.

    $ tpm2_eventlog ./t14_eventlog | grep "BOOT_SERVICES_DRIVER" | wc -l
    7
This is essentially what me and Trammell Hudson has been thinking about. But I don't have any available machines to test this with, and I haven't gotten around to setting up a QEMU vm to test out this theory.

https://github.com/Foxboron/sbctl/issues/85#issuecomment-886...

Re: Authenticated Boot and Disk Encryption on Linux

#54

Post by egberts1 »

LeifCarrotson wrote: post #43
remuskaos wrote: post #38

Earlier quoted context omitted.

That's what those countless convention stickers are for, they're basically a cryptographic hash of all the leet stuff you've attended.

This or the 'glitter nail-polish' pseudo-holographic identifiers both ignore that if you have a physically identical laptop save cosmetics, you can swap in the motherboard and hard disk from the replacement unit. Externally, it's identical, internally it's all compromised.

We haven’t found a l33t who can swap an macOS motherboard in 15 minutes.

Re: Authenticated Boot and Disk Encryption on Linux

#55

Post by uuidgen »

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…

> Copy the login screen of original laptop on a brand new laptop, and have it log the password when the victim types it to you over wifi.

This is why you need mutual authentication. The easiest is with 2 passwords. You enter a password, this authenticates you to the system. Now system presents you some secret. It may be a passphrase, something not obvious like a password prompt with a typo, or a splash screen with some pixels a bit off that are visible at the right angle. Something that a casual shoulder-surfing won't gather. Only when the system is authenticated to you then you enter the 2nd password o actually unlock the filesystem.

As for "identical replacement" of a system - good luck. A bit of glitter and nail polish on screws and it will cost a fortune to do so. If you have those capabilities you probably have the capabilities to "nicely ask me for the password".

Re: Authenticated Boot and Disk Encryption on Linux

#56

Post by markjenkinswpg »

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

Re: Authenticated Boot and Disk Encryption on Linux

#57

Post by amarshall »

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.

> take over kernel, initrd and bootloader

Huh? There are not really any Kernel or bootloader changes proposed here, just signing them and using existing functionality within them. (Okay, I guess he proposes adjusting the Kernel to optionally have a way to authenticate parameters, but is that really “taking over”?)

As for initrd, he’s just talking about adjusting the way their generated to be more static and modular to simplify signing. Yes, there’s some tooling to do this proposed as part of the systemd organizational umbrella, but systemd isn’t a monolithic thing.

Regardless, and just like systemd, you don’t have to use any of this if you don’t want to.

Re: Authenticated Boot and Disk Encryption on Linux

#58

Post by Foxboron »

phh wrote: post #47
nsajko wrote: post #35

Earlier quoted context omitted.

Replicating the chassis (including the scratches, etc.) and other laptop parts is the hardest part of your attack. I assume you don't know about the nail-polish with glitter based protection? Even "copying the login screen" is not necessarily easy.

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://github.com/tpm2-software/tpm2-totp

Re: Authenticated Boot and Disk Encryption on Linux

#60

Post by amarshall »

supperburg wrote: post #50

“With LUKS, the encryption is as good as your password is strong.” Well that was anticlimactic. I thought my entire setup would have to be overhauled.

Did you read the whole thing? LUKS (or FDE in general) is not enough for the attacks presented. Partly because FDE is rarely ever the “full” disk.
Post reply on HN