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

Bypassing disk encryption on systems with automatic TPM2 unlock

oddlama.org

Post reply on HN
Print view View original

121–130 of 136 posts

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#121

Post by johnisgood »

cedilla wrote: post #38
johnisgood wrote: post #23

Earlier quoted context omitted.

USB pendrive with random key, no need to enter anything and is more secure and gives you plausible deniability through many different means.

Going around 10 servers with a USB drive sounds just as tedious, and what happens when you lose the key or the attacker gets it?

You generate a new one and replace it. Those what ifs apply to passwords as well.

It might sound tedious for 10 servers, but passwords are even more so.

For desktop, it is definitely the way.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#122

Post by tommiegannert »

michaelt wrote: post #42
tommiegannert wrote: post #31

Very nice exploit. So if you use this PCR state machine, the problem is that the step before initrd doesn't require the correct password to move the PCR forward? It accepts any password that decrypts the next stage, which didn't have its integrity verified here. Seems there are multiple ways of solving this, and adding integrity checks is only one. It could also let the TPM verify the disk decryption password (when i…

> It could also let the TPM verify the disk decryption password (when it's needed.) The design intent is basically: 1. The TPM is very sensitive, and errs on the side of not unlocking your disk. Booting into recovery mode to fix a driver? Reinstalled your distro? Added a MOK so you can install the nvidia drivers? Toggled certain options in your BIOS? The expected-computer-state checksums are wrong, better not unlock…

Right. The password verification would not be tied to the PCR states, or it wouldn't solve the problem at hand.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#123

Post by betaby »

surajrmal wrote: post #117
_lvbh wrote: post #2

I don't understand why anyone would use passwordless disk encryption. It just seems inherently vulnerable, especially with the threat model of physical compromise. Entering a password on boot isn't even that much work

Full disk encryption is just inherently a flawed approach compared to per file encryption. Androids approach of only protecting user data with behind the password and otherwise using a separate encryption key to allow the os to boot to the lock screen and some apps to run (eg alarms) is a more user friendly approach. Unfortunately we don't seem to have that sortve option available to us with desktop OS.

> Unfortunately we don't seem to have that sortve option available to us with desktop OS.

As I understand MacOS uses per file encryption on AFS.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#124

Post by seymon »

varispeed wrote: post #111

How do you deal with something like this in a NAS? There is no way to enter password during boot. If someone steals the NAS how easily can they get to the data? Assuming volumes are encrypted, but the are automatically mounted on boot? How to ensure the data is safe in case of theft.

Instead of the luks key in tpm you can use a fido2 compatible hardware security usb token. For booting/unlocking it has to be plugged in then you can remove it. This is pretty convenient and secure against many threats like stealing the nas in my opinion.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#125

Post by XorNot »

Vogtinator wrote: post #36
XorNot wrote: post #28

Earlier quoted context omitted.

It's ridiculous that there's no software implementation to do this, it's a huge problem. Auto update should be able to include the kernel, initrd and grub cmdline from the running system I have no idea what's holding this back since evidently code already exists somewhere to do exactly that.

That's the design with sdbootutil in openSUSE ( https://en.opensuse.org/Systemd-fde , https://github.com/openSUSE/sdbootutil ).

I don't see anything explicit on those pages about solving this problem though?

Like with my current clevis luks setup, which I somewhat random have to regen, I'm bound to PCR 0, 1, 2, 3, 4, 7, 8 and 9.

From https://uapi-group.org/specifications/specs/linux_tpm_pcr_re... that gives me:

0 - Core system firmware executable code

1 - Core system firmware data/host platform configuration; typically contains serial and model numbers

2 - Extended or pluggable executable code; includes option ROMs on pluggable hardware

3 - Extended or pluggable firmware data; includes information about pluggable hardware

4 - Boot loader and additional drivers; binaries and extensions loaded by the boot loader

7 - SecureBoot state

8 - Commands and kernel command line

9 - All files read (including kernel image)

Now the problem is, 8 and 9 I would argue are the most important (since technically 7 probably covers everything else in that list?), whereas my kernel and initrd are not encrypted and my command line can just be edited (but normally wouldn't need to be). But I can't find anyway to get grub, from a booted system, to simulate the output of those values so I can pre-seal the LUKS volume with the new values.

So in practice, I just always need to remember my password (bad) which means there's no way to make a reasonable assessment of system integrity on boot if I get prompted (I'd argue also the UI experience here isn't good: if I'm being prompted for a password, that clevis boot script should output what changed at what level - i.e. if secure boot got turned off, or my UEFI firmware changed on me when I'm staying in a hotel, maybe I shouldn't unlock that disk).

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#126

Post by kopirgan »

kopirgan wrote: post #49

Any idea how this works in the Windows world with bitlocker? I hope it's not same vulnerability I recently changed motherboard on my laptop, had the bitlocker key if not I was told I'll have to reinstall Windows all over again. Even with the key, one must decrypt and re-encrypt.

Lol within few days my question answered by this post

https://neodyme.io/en/blog/bitlocker_screwed_without_a_screw...

It's in HN

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#127

Post by JZerf »

JZerf wrote: post #115
blastrock wrote: post #97

Very clever! I am the author of one of the older guides https://blastrock.github.io/fde-tpm-sb.html . I was wondering about the solution you propose which seems a bit complicated to me. Here's my idea, please tell me if I'm completely wrong here. What if I put a file on the root filesystem with some random content (say 32 bytes), let's name it /prehash. I hash this file (sha256, blake2, whatever). Then, in the signed…

I was reading another web page (I don't have the link unfortunately) several days ago where another reader pointed out to the author the same type of attack mentioned in this article. To address that attack the author came up with the same solution you proposed and I do believe that is sufficient for preventing the type of attack mentioned in this article. There still are other types of attacks (cold boot attack, sni…

Found the page I had mentioned earlier: https://pawitp.medium.com/the-correct-way-to-use-secure-boot... . In the comments Aleksandar mentioned the possibility of using the attack mentioned in this article and the author replied back with the same solution of verifying a secret file on the root partition.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#128

Post by SoftTalker »

lukeschlather wrote: post #114
tommiegannert wrote: post #30

Earlier quoted context omitted.

I'd guess the most common scenario is for someone giving away the entire computer, not fiddle with components. Or theft of the full machine. This feels like one of those half-security measures that makes it feel like you're safe, but it's mostly marketing, making you believe *this* device can be both safe and easy to use.

It's pretty fast to destroy all the keys in a TPM. Should take a minute if you know the right place to go. Meanwhile securely deleting a normal drive requires overwriting every sector with random data, which could take hours. So it also helps if you're giving away the whole machine.

Smashing the disk with a hammer takes seconds. Or dropping it in a shredder.

Used disks are not worth hours of time to overwrite with random data. Just physically destroy them.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#129

Post by cookiengineer »

rollcat wrote: post #120
snailmailstare wrote: post #94

Earlier quoted context omitted.

>> we can confuse the initrd into executing a malicious init executable. This hash the next link method is always as flawed as the weakest link..

Of course. The typical Linux initrd is also too complicated. It should be doing this, and nothing else: - There's an executable called /init, link it statically with everything it needs to do. - Load kernel modules from a list (hardcoded at build time; optional if you include common modules in the generic kernel). - Mount the root filesystem (hardcoded at build time) and pivot. - execve("/sbin/init", ...) I've built…

Do you have that on github or gitlab?

I'd love to contribute, as I'm also working on something like this for the last couple weeks.

Re: Bypassing disk encryption on systems with automatic TPM2 unlock

#130

Post by akimbostrawman »

cyberax wrote: post #109
jvdvegt wrote: post #106

Earlier quoted context omitted.

They'll have your data if they just take the whole server...

And then what? They will be faced with a login prompt. Reading from disks is useless. My login password is strong.

Boot any Linux ISO and bypass any OS logins (secureboot would prevent this), connect devices over IO to otherwise exploit the login or just dump RAM content to potentially get data or even keys.

I would never trust OS login over FDE especially on desktop.

Post reply on HN