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

121–130 of 135 posts

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

#121

Post by adrian_b »

gameoverhumans wrote: post #118
adrian_b wrote: post #96

Earlier quoted context omitted.

I am not using LUKS, I am using a custom kernel module that implements a block device that presents to the kernel the decrypted SSD. The kernel module receives the key when it is loaded, then it creates the block device that is eventually mounted as the new root device. I do not know if LUKS could be used for this, I have not examined it. IIRC, LUKS stores the actual decryption key in the encrypted disk (protected by…

LUKS supports detached headers, maybe this would be useful for your setup? https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encryp... Your approach sounds pretty cool, by the way. I've thought about such an approach in the past, and I've used it for some auxiliary computers under my control, but not for my daily driver. I have a Framework laptop and I could indeed use this approach in quite a stylish way, though…

Thanks for pointing to this LUKS feature.

The last time when I have looked at LUKS was some years ago, when this feature did not exist yet.

In my opinion, this is the only right way to do SSD/HDD encryption. The detached header allows plausible deniability and it avoids downgrading the strength of the encryption key to the strength of the passphrase.

By using the detached header option, LUKS could be used exactly like in my custom setup.

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

#122

Post by adrian_b »

wkat4242 wrote: post #117
adrian_b wrote: post #99

Earlier quoted context omitted.

The attacks "evil maid" described by a poster above are impossible. Even with physical access, the computer does not have any boot loader or kernel or any other executable that could be altered. The attack described in the thread title also does not work, because the computer cannot boot. Even after booting from their own device, attackers cannot do anything useful. Reading the encrypted SSD will not provide any info…

Sounds like a great option. Would be nice if there was an install wizard that could configure that. Ps I wonder what inconspicuous usb drive you use?

I use various Corsair or Kingston USB flash drives, with sturdy fully metallic cases, and which are just a little larger than a USB connector, i.e. they just have an ear that remains outside the connector when inserted, to allow for their extraction.

An example:

https://media.kingston.com/kingston/key-features/ktc-keyfeat...

I have also used MicroSD cards together with a very small USB adapter, which is also only a little greater than the USB connector.

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

#123

Post by jcelerier »

privacyking wrote: post #114
patrakov wrote: post #89

Earlier quoted context omitted.

On my laptop I have custom Secure Boot keys. I know I did not sign any other OS (well, I did - but with a different key), so this attack won't work, unless the attacker can somehow trick the unmodified previous version of the kernel + initrd combo into asking my passphrase and saving it somewhere, which is highly unrealistic.

If they have physical access as per this scenario, they can just install a hardware keylogger and get access with your login credentials.

Or even just hit OP repeatedly until they tell the password which is likely how many of the cases end

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

#124

Post by ivlad »

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…

> it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!

It’s still looks perfectly reasonable, just PCR should be fed with some value before that, maybe a hash of initramfs file? It seems to be reasonable as at this moment the state of the operating system differs from the one properly booted, which seems to fit the idea of secure boot.

This way it would be possible to still unlock LUKS with a pass phrase but not access TPM keys locked for configuration when initramfs shell is not running.

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

#125

Post by spiffytech »

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?

Depends on the constraints of the scenario.

With "cold boot attacks", after you cut power to a machine the system's memory will still be readable for a brief moment. If you chill the RAM with compressed air you can stave off the electrical self-discharge even longer. Boot to a specialized OS or move the memory to alternate hardware and you can dump its contents.

These attacks specifically target disk encryption and other keys that are kept in memory.

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

#126

Post by hollerith »

Aurornis wrote: post #108
michaelt wrote: post #57

Earlier quoted context omitted.

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…

> If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. That's a weird dismissal. This attack is a big deal because it provides a workaround to full desk encryption. I have no idea why so many people in this thread are trying to pretend it's not a big deal. This is a big deal. Full disk encryption is supposed to make sure your data is safe if the laptop is stolen. Thi…

Linux's full disk encryption (FDE) is probably good at discouraging evil-maid attacks if used with a passphrase that the user enters every boot.

But you know how Linux is: anyone can add any feature, no matter how bad of an idea it is. What is probably going on is that Linux's secure-boot support is not good enough to allow secure TPM-based FDE, but someone implemented it anyway. (Or it is good enough if you use a unified kernel image, but most Linux installs do not do that: https://wiki.archlinux.org/title/Unified_kernel_image)

Fedora's installer offers me the chance to turn on full disk encryption, but it does not offer me the option of TPM-based FDE.

>This attack is a big deal because it provides a workaround to full desk encryption.

Security is complicated, and this statement simplifies the situation too much.

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

#127

Post by buildbot »

trelane wrote: post #71
buildbot wrote: post #50

Earlier quoted context omitted.

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/

Real programmers induce brainwaves into their cats telepathically so they sit just so to flip the required bit

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

#128

Post by als0 »

jiveturkey wrote: post #91
als0 wrote: post #78

Earlier quoted context omitted.

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.

simpler? hardly. high level overview: https://support.apple.com/guide/security/secure-enclave-sec5... low level overiew: https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De... AFAIK, and it's hard to find the info since I don't have it handy, so I don't want to devote the searching time, but bringing it back on-topic, all disk i/o has to go through the secure enclave for encryption and decryption. i believe…

Counterpoint: https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM...

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

#129

Post by CatWChainsaw »

Dalewyn wrote: post #112
Helmut10001 wrote: post #109

Earlier quoted context omitted.

I am on Chrome.

I'm using Chromium, uBO, and 8.8.8.8 with no issues regarding archive.is, so... ┐(￣ー￣)┌

I tried it in a pretty vanilla Edge and it worked. I guess that's two reasons to keep Edge around: download browser of choice, and use Archive.

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

#130

Post by temp_gnuser »

CoolCold wrote: post #113
temp_gnuser wrote: post #62

I have long advocated for disabling tpm in bios, uefi-boot raw dm-crypt to even get grub much less init. This is also how I have done encrypted disks in the cloud using dropbear ssh as an initram shim for key/pass entry. Bios boot pass is annoying but required. Watch your acess/auth logs. Run a HIDS. Isolate your procs and especially their network comms. Security is an onion, not that most c-suites have any idea thes…

What's your way of providing laptops to your employees? For simplicity, let's assume everyone is located in the same country.

Setup in house via imaging then control once vpn is established via cac tooling. I've run all linux laptop fleets this way before so it does work but I have some ideas on improvement. PXE is a weak protocol in the stack for example.
Post reply on HN