Authenticated Boot and Disk Encryption on Linux • Hacker News Board

Re: Authenticated Boot and Disk Encryption on Linux

#41

Post by g_p » Thu, Sep 23, 2021, 12:50 PM UTC

losingom wrote: post #7

>Authentication of boot loaders is done via cryptographic signatures [...] the cryptographic certificates that may be used to validate these signatures are then signed by Microsoft This is what concerns me. While Microsoft are indeed dominant, surely them signing these is a conflict of interest? Why can't there be an external body that signs these, including those for Microsoft?

The "default" boot chain is using a Microsoft CA key, but you can easily change it. In fact, the "root" for your system is the platform key, which is most probably signed by your OEM.

Pragmatically speaking, I'd be more worried about my OEM's platform key being compromised when someone leaks their UEFI firmware build tree through a ransomware attack or similar.

The biggest issue of the Microsoft "CA root", is that they sign everything - there was a good example [1] of them signing a Kaspersky rescue CD that could effectively break the secure boot chain.

The good news is you can load your own keys into your motherboard. It's only really a solution for enterprises or tech-savvy individuals, but it at least is a viable option and helps you to "own" your own platform.

[1] https://habr.com/en/post/446238/

Re: Authenticated Boot and Disk Encryption on Linux

#42

Post by amarshall » Thu, Sep 23, 2021, 12:52 PM UTC

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 in it is a big lift (not that that’s bad, but it’s certainly different).

Personally, I agree that have some signed base system is valuable, but I also struggle to find attack vectors it prevents that a signed initrd (in a sense, it’s a base system) doesn’t.

Re: Authenticated Boot and Disk Encryption on Linux

#43

Post by LeifCarrotson » Thu, Sep 23, 2021, 12:52 PM UTC

remuskaos wrote: post #38

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…

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.

Re: Authenticated Boot and Disk Encryption on Linux

#44

Post by sam_lowry_ » Thu, Sep 23, 2021, 12:52 PM UTC

kevincox wrote: post #23

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.

Does not LUKS already work with Yubikeys [1]?

[1] https://github.com/cornelinux/yubikey-luks

Re: Authenticated Boot and Disk Encryption on Linux

#45

Post by egberts1 » Thu, Sep 23, 2021, 12:55 PM UTC

wereHamster wrote: post #37

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…

Yeah, let's move to the complete opposite side: one /bin for each package. You can have that today, in NixOS.

We know that package containerization (a la Apple, or NixOS) didn’t expand well either for the vendors/maintainers who want to include their products into multiples of OS distros.

And currently this probably would be very difficult to implement a signed-immutable binaries with regard to multi-OS distros vs multi-vendors.

So, the nice sweet convergence is probably hovering around hardware/OS/vendor grouping somewhere.

Re: Authenticated Boot and Disk Encryption on Linux

#46

Post by amarshall » Thu, Sep 23, 2021, 12:56 PM UTC

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.

Don’t generalize your problems with a specific software (Veracrypt) to all drive encryption software. Plenty of drive encryption solutions are fast, reliable, and resilient. (You could also be having a hardware problem exacerbated by adding an abstraction layer.)

I’ve used LUKS, GELI, ZFS encryption, FileVault, and BitLocker across numerous drives over the past decade (albeit in different individual proportions and timelines) with no corruption problems.

Re: Authenticated Boot and Disk Encryption on Linux

#47

Post by phh » Thu, Sep 23, 2021, 12:57 PM UTC

nsajko wrote: post #35

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…

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 protection?

Nope, can you explain?

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.

> Even "copying the login screen" is not necessarily easy.

Personally my login screen is ubuntu's default FDE screen untouched, so there is literally no work involved to attack me there. I have absolutely no idea how to customize FDE screen. But even if I did, I'd expect that it would be pretty easy to plug in an HDMI capture to have a close-enough duplicate of the screen.

Re: Authenticated Boot and Disk Encryption on Linux

#48

Post by kevincox » Thu, Sep 23, 2021, 12:57 PM UTC

sam_lowry_ wrote: post #44

kevincox wrote: post #23

Earlier quoted context omitted.

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.

Does not LUKS already work with Yubikeys [1]? [1] https://github.com/cornelinux/yubikey-luks

Based on the description of that repo it does exactly what I suggested you can do.

Re: Authenticated Boot and Disk Encryption on Linux

#49

Post by egberts1 » Thu, Sep 23, 2021, 12:59 PM UTC

nsajko wrote: post #25

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.

Did you just assumed that /bin and initd are separate by the virtue of “cloning-by-initd” and thusly needing to be differently signed by necessity?

Re: Authenticated Boot and Disk Encryption on Linux

#50

Post by supperburg » Thu, Sep 23, 2021, 1:00 PM UTC

“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.