Hacker News Reader

Comment by mjg59 | Hacker News Reader

Where do you put the password? If you're just protecting the firmware setup, then I can just rewrite the secure boot key database without using the firmware setup. If you're using it for disk encryption, I just buy one myself, dump the disk image after it's decrypted, modify it so it'll boot whatever password you type in, intercept your device while it's being shipped or spend some time alone in a room with it, and drop my backdoored image on there.

Please don't get me wrong - I would love a solution to this problem that wasn't isomorphic to a solution that can be used to lock out users. But I've spent the last 8 years or so of my life trying to do so and haven't succeeded yet, because the hardware we have available to us simply doesn't seem to give us that option.

View on HN

Is it really that easy just to overwrite the secure boot key database? I set up recently secure boot on a Lenovo laptop according to these instructions https://nwildner.com/posts/2020-07-04-secure-your-boot-proce...

...and deploying the keys involves setting UEFI in the Setup mode, which is protected by the firmware setup password.

Granted, I didn't verify where the keys are stored and in which format once deployed. But it would be pretty disappointing if they were just copied to another place without any encryption or signing authorized by the password.

The UEFI variable store is typically just a region of the flash chip that stores the firmware. It's not impossible that some systems perform some sort of integrity validation, but I haven't seen that in the wild.

Isn't Intel Bios Guard supposed to protect against this very attack ?

Well, you're comparing hashes to ones online, can't you put the password hash online? (sorry, I am very ignorant of the situation here and am asking stupid simple questions)

I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead?

> ... the hardware we have available to us simply doesn't seem to give us that option.

Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?

> Well, you're comparing hashes to ones online, can't you put the password hash online? (sorry, I am very ignorant of the situation here and am asking stupid simple questions)

If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth.

> I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead?

Various bits of TPM functionality can be tied to requiring a password, but it's hard to actually turn that into something that's more freedom preserving while still preserving the verifiability. What you want is the ability to re-seal a secret to new values only as long as you have the password available, and I don't /think/ you can construct a system that does that with the features the spec gives you.

> Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?

Unclear. There's little commercial incentive for people to come up with elegant solutions to this, and I can't immediately think of a model that would be significantly better than the status quo.

> If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth.

I think the GP's point is that you assume the system can't tell the truth so you do the validation server side rather than client side. Sure, the system could send a different password hash, but as long as you don't publish the correct hashes it's not going to matter if the client sends alternative hashes since that validation happens server side and thus the client wouldn't know what hashes are valid.

Thanks for the clear answers and info :) It's an interesting subject!

Reply on news.ycombinator.com