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

Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

pulsesecurity.co.nz

Post reply on HN
Print view View original

21–30 of 135 posts

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#21

Post by phoronixrly »

rlpb wrote: post #14
Guvante wrote: post #10

Earlier quoted context omitted.

Technically, but really the fault lies in the OS for providing an exploitable prompt that doesn't break the chain of custody of the boot process on failure.

Ubuntu developer here. I don't think that's fair. The OS, as shipped today, isn't designed with this threat model in mind. It's correct to say that for TPM-based LUKS unlock to be safe, the initramfs must not allow the user to take control of it. But that's a new requirement introduced when the user modified their system to configure TPM-based LUKS unlock. This isn't the responsibility of an OS that doesn't ship with…

Sorry but Clevis (similarly to bitlocker without PIN) is security theatre.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#22

Post by alexvitkov »

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel.

If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#23

Post by SomeoneOnTheWeb »

alexvitkov wrote: post #22

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

I used to have a custom NAS with full disk encryption, whose bootloader would spin up a tiny SSH server with very few features, mainly only access to an unlock function that would allow to transmit the encryption passphrase over the said SSH tunnel. Then the SSH connection would be closed by the server and it would startup with the decryption key.

That way, it was impossible to access the data physically, but I was still able to reboot the box whenever I wanted without any problem.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#24

Post by webstrand »

alexvitkov wrote: post #22

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

My experience with kexec has been poor. Every time I kexec, I have to load and unload a bunch of drivers to restore the system to a functional state. Critically i915 sometimes needs to be reloaded after boot to get the display to actually work. And on a VM I had issues with the `cirrus` display driver failing to unload correctly leaving the system unable to boot. Its random and totally unreliable for desktop use.

Aside, this is a nice script that prompts for the LUKS password _before_ kexec: https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981... it does assume you're using opensuse's naming convention of calling the root partition cr_root. I used this because my bootloader was also encrypted, so rebooting into an initramfs with ssh was impossible.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#25

Post by xoa »

michaelt wrote: post #11
jeroenhd wrote: post #7

Earlier quoted context omitted.

The system that should only unlock the drive after the appropriate remote command has been provided, unlocks the drive without the remote command being provided. That's the problem. I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. You'd still be at risk because of this flaw, because the root shell would allo…

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted" If your organisation is large enough to start losing track…

In addition to sibling replies, I'll add that a common important use for encryption (and reason to have it be completely standard 100% of the time, even in fully transparent mode) is storage EOL procedures. It's much easier/cheaper/safer to get rid of an HDD or SSD and feel confident everything is gone if it was all fully encrypted from the beginning and you just need to trash the key.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#26

Post by 13of40 »

michaelt wrote: post #11
jeroenhd wrote: post #7

Earlier quoted context omitted.

The system that should only unlock the drive after the appropriate remote command has been provided, unlocks the drive without the remote command being provided. That's the problem. I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. You'd still be at risk because of this flaw, because the root shell would allo…

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted" If your organisation is large enough to start losing track…

It's not a totally meaningless check box. If the key for decrypting the disk is in the TPM, this fixes the case where the drive gets pulled and thrown in a recycle bin, then someone recovers data from it later.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#27

Post by tomatocracy »

betaby wrote: post #17
michaelt wrote: post #11

Earlier quoted context omitted.

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted" If your organisation is large enough to start losing track…

Looks like so. From https://rogueai.github.io/posts/arch-luks-tpm/#unlock-the-lu... 'From a security point of view, passwordless LUKS unclocking might look like we’re giving up some security, as booting will go straight to login without asking any password whatsoever. We’re indeed trading a bit of security in favour of convenience, it’s important to note though that binding the LUKS to the TPM ensures the volume will…

Another potential use is encrypted root with home directories subsequently requiring login password to decrypt (using pam_ecryptfs, pam_mount, etc). Less secure than root fe needing a PIN/password but can still defend against some threat models.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#28

Post by AshamedCaptain »

formerly_proven wrote: post #13
Guvante wrote: post #10

Earlier quoted context omitted.

Technically, but really the fault lies in the OS for providing an exploitable prompt that doesn't break the chain of custody of the boot process on failure.

This is one of those designs where you skim a description and already know it’s going to break in a million different ways.

I still don't understand why people believe that you can have any expectation in these ludicrous scenarios.

Like, you are dropping a general purpose computer into the middle of Russia, expect to be able to command it remotely to do anything, even remotely update it and reboot it; and at the same time never bother to come check it up in person or even have minimum chassis intrussion detection. Do people really expect this to work just by adding some TPM craziness?

The article is just connecting a keyboard sniffer/simulator but it would have been as easy to do anything to the network traffic, SSD, motherboard/CPU JTAGs, RTC, etc.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#29

Post by alexvitkov »

SomeoneOnTheWeb wrote: post #23
alexvitkov wrote: post #22

There's no viable reason to reboot a Linux box. Even for kernel upgrades you have kexec, and there are ways (hacks) to hand over the LUKS keys to the new kernel. If you need to reboot an encrypted box remotely AND have it automatically decrypt without you knowing the key, you've already lost the game.

I used to have a custom NAS with full disk encryption, whose bootloader would spin up a tiny SSH server with very few features, mainly only access to an unlock function that would allow to transmit the encryption passphrase over the said SSH tunnel. Then the SSH connection would be closed by the server and it would startup with the decryption key. That way, it was impossible to access the data physically, but I was s…

That's sensible, unlike trusting that TPM+GRUB+dracut+systemd+getty+logind+whatever all work fine and won't leak your key.

Rebooting a box is often the easiest way to get something done if you can't be bothered with exotic configs, I just don't believe that remotely rebooting a encrypted box for which you dont have the key is ever a reasonable thing to do, and that's the assumptuon this article is based on.

Re: Mashing Enter to bypass full disk encryption with TPM, Clevis dracut and systemd

#30

Post by SoftTalker »

13of40 wrote: post #26
michaelt wrote: post #11

Earlier quoted context omitted.

> I'm not sure why you would rely on just the TPM in this case, though. TPM only disk encryption is rather risky, you'd expect a TPM+PIN setup at the very least. I think the target market is "I have a server in a data centre, I need unattended boot, I don't really need a high grade of security I just need to tick a checkbox saying the hard disk is encrypted" If your organisation is large enough to start losing track…

It's not a totally meaningless check box. If the key for decrypting the disk is in the TPM, this fixes the case where the drive gets pulled and thrown in a recycle bin, then someone recovers data from it later.

> this fixes the case where the drive gets pulled and thrown in a recycle bin

Also allows you to do that when you retire a server or cluster. I've been in situations where we had to wipe hundreds of multi-TB hard drives. If you've never done it, that takes a good deal of time. You can get appliances that do it, or try to build your own DBAN rig, but it still takes days. Or you can just shred them, but hard drive shredders are not cheap either, and that's rather wasteful and may not be environmentally conscious.

Post reply on HN