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

71–80 of 135 posts

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

#71

Post by trelane »

buildbot wrote: post #50
ddtaylor wrote: post #43

Earlier quoted context omitted.

I came home one day and my cat was laying on my keyboard. Above her was a screen with a large amount of random control characters in a terminal with a kernel panic screen. So there's some series of buttons you can press that will crash a Linux desktop from a lock screen.

At least for my cat and sad surfacebook Windows machine, I figured it was the device literally cooking it’s ram into a bitflip that caused it to bsod. The cat loves how toasty it gets!

> I figured it was the device literally cooking it’s ram into a bitflip that caused it to bsod.

Funny, that's exactly how I push "control" in emacs.

Ref: https://xkcd.com/1172/

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

#72

Post by Groxx »

brenns10 wrote: post #70
Groxx wrote: post #65

So to double check my understanding of this article and the linked one that led to it[1], the issue is: 1. the TPM does not require a password to get the decryption keys 2. bootup decryption passwords are checked by code , before asking (using?) the TPM's data (passwordless, because the bootup code is trusted) 3. exhausting multiple layers of retries causes ^ part 2's code to accidentally get/use the decryption data…

TPMs typically won't give out a secret unless all of the software which has been loaded and executed was "measured" and found to be unmodified from when the secret was stored. So you couldn't simply stick your own hard disk or USB disk into the computer and then ask the TPM for the secret: the running software wouldn't match, and the TPM would refuse. This is a problem because the "approved" software has this strange…

Which wouldn't really be an issue if all the trust wasn't unnecessarily put on a single system, yes.

This is the equivalent of a rubber hose attack, where your OS vendor is being threatened and can give away your information retroactively. That's ridiculous to even consider allowing if you're selling something as "securely encrypted", just make it E2EE (derive the key rather than directly using the TPM's data).

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

#73

Post by tomatocracy »

gameoverhumans wrote: post #60
jsmith99 wrote: post #53

Earlier quoted context omitted.

That just defeats secure boot, it doesn't defeat TPM backed drive encryption, which only releases the key if the OS is unchanged, otherwise you could just defeat it by booting a different signed OS.

That depends on which PCRs you bind your TPM-backend encryption key to. See this list: https://uapi-group.org/specifications/specs/linux_tpm_pcr_re... As an example, Arch Wiki encourages you to bind to PCR 0+7: https://wiki.archlinux.org/title/Trusted_Platform_Module#sys... ... both of those are firmware-level PCRs, not OS ones.

PCRs 0+7 might not be sufficient if you don't have an up to date dbx (revocation list) - older versions of shim won't (I think) extend into PCR 7 enough information on what they chainload. This means a malicious bootloader could fake the correct PCR extensions.

Updating dbx to a version which revokes versions of shim with this issue would fix this I think, as would including PCR 4 in the list bound to, to make doubly sure that the version of shim is new enough not to present a risk.

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

#74

Post by chatmasta »

jiveturkey wrote: post #68
chatmasta wrote: post #39

Earlier quoted context omitted.

You raise a valid point, but this attack is particularly alarming because it circumvents a TPM, which is a hardware module that was specifically designed to protect against evil-maid class of attacks, e.g. every iPhone after the 5S uses its Secure Enclave (a TPM) to enforce time delays between passcode attempts [0], so that a physical attacker can't brute force the passcode. (Incidentally, the attack described in the…

In addition to the inaccuracies others have mentioned, the iPhone secure enclave is not a TPM. Saying it is isn't a simplification, it's muddying the waters.

Can you explain the difference a bit more, and why it's more than just splitting hairs? Is it because TPM is a specific standard for implementation of a secure co-processor, whereas Secure Enclave is part of a larger SoC (T2), which while it could be considered an implementation of a secure co-processor, is distinct from the TPM standard?

In researching this comment I learned that the T2 chip actually runs its own operating system (bridgeOS), so I can see why you'd call it an oversimplification (or muddying the waters) to equate it to a TPM.

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

#75

Post by [deleted] »

michaelt wrote: post #57
hollerith wrote: post #48

Earlier quoted context omitted.

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for. If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a…

[deleted]

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

#76

Post by [deleted] »

michaelt wrote: post #57
hollerith wrote: post #48

Earlier quoted context omitted.

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for. If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a…

[deleted]

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

#77

Post by malwrar »

hollerith wrote: post #48
gameoverhumans wrote: post #31

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses…

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

The thing that prompts for your password is necessarily unencrypted, the evil maid just needs to modify that to e.g. log the decryption key. On linux, this is usually just a shell script invoking cryptsetup somewhere in the initramfs image.

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

#78

Post by als0 »

chatmasta wrote: post #74
jiveturkey wrote: post #68

Earlier quoted context omitted.

In addition to the inaccuracies others have mentioned, the iPhone secure enclave is not a TPM. Saying it is isn't a simplification, it's muddying the waters.

Can you explain the difference a bit more, and why it's more than just splitting hairs? Is it because TPM is a specific standard for implementation of a secure co-processor, whereas Secure Enclave is part of a larger SoC (T2), which while it could be considered an implementation of a secure co-processor, is distinct from the TPM standard? In researching this comment I learned that the T2 chip actually runs its own op…

The TPM is an TCG standard (also ISO/IEC 11889), and specifies commands that support a lot of use cases. The Secure Enclave from Apple is something simpler and more restrictive, that is tailored only for Apple's use cases.

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

#79

Post by adrian_b »

gameoverhumans wrote: post #59
hollerith wrote: post #48

Earlier quoted context omitted.

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

In my view, a setup where you are forced to enter a decent-quality disk-unlock passphrase on every cold boot is a rather hardened setup. The problem is, this is awful UX. If something causes a lot of friction, folks tend to just avoid that thing. And that's why many people just bind the disk encryption key to their TPM and call it a day. Thus leading to the exploit detailed in the parent article. Once you have physic…

Because of things like those described by you, I have never trusted bootable encrypted SSDs/HDDs.

In my computers, I have only non-bootable and non-partitioned SSDs/HDDs, which are completely encrypted with a random 256-bit key, so as long as an attacker has only access to the computer, for instance to a stolen laptop, there is absolutely nothing that can be done to gain access to the stored data.

To boot the computers, I use a small and inconspicuous USB memory containing the boot loader and the kernel, from which the encrypted SSD is mounted and then pivot_root is executed to replace the USB memory with the encrypted SSD as the root device, and then the USB memory is removed and it is not used during normal operation.

The USB key contains an encrypted form of the SSD encryption key, requiring the entering of a passphrase after the kernel has booted, but before mounting the encrypted SSD.

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

#80

Post by alexvitkov »

jmetzmeier wrote: post #52
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.

What about libc updates? If you need to restart effectively every process on the system anyways, why not reboot?

static link musl
Post reply on HN