Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What's the difference in security here?


Some additional context: when the system boots, the secure boot key that was used is recorded into PCR 7[1] in the TPM. This means that booting an OS signed with the Windows signing key will result in a different PCR 7 value to booting an OS signed with the 3rd party signing key. If you care about which signing key was used, you can provide a secret to the TPM and ask the TPM to only release (or make use of) that secret if PCR 7 has a specific value. This means it's possible to configure an OS such that it will only be able to access its secrets if PCR 7 has the expected value. An attacker who intercepted the laptop before it was delivered to its owner could obviously subvert this by sealing the secret to the incorrect PCR 7 value, but such an attacker could also just reconfigure the firmware to trust the 3rd party CA before the owner received it. There isn't a clear description of what threat model this design is intended to protect against, or why alternative approaches weren't used to achieve the same goal.

[1] Modern TPMs have 24 PCRs that can be used to measure different parts of the boot process, but the general expectation is that only 0-7 will be used by the firmware. On UEFI systems, PCR 7 contains information about what the platform's secure boot policy is, and which keys were used to verify the boot process. Booting something signed with a different key will result in PCR 7 having a different value, which is something that can be detected by tying encryption keys to specific PCR values.


No contest, but if you are actually a person who is paranoid about this but still requires to have access to Windows software (in an enterprise setting), you would actually check the UEFI and reinstall Windows. If you're actually being attacked by state-sponsored actors the risk management is so different that I don't think it can be discussed here fairly (mainly because it's a case-by-case matter).


Secure Boot ensures that it's impossible to run a rootkit, even if the user accidentally installs one. Instead of booting into corrupted Windows, the system would fail to boot.


The switch doesn't disable secure boot, it merely allows files signed using the Microsoft 3rd Party UEFI CA to boot.

(Context: I wrote a significant portion of the infrastructure used to support Linux booting on systems with UEFI Secure Boot)


It's definitely harder, but not impossible. The Realtek signing driver was stolen multiple times already, and I personally know that certificate management practices (in Asia in general) is abysmal.


This current scenario is very likely Device Guard that limits the CA's that may be used, that it's not Secure Boot with its defaults.

So the security benefit would be avoiding 3rd party and signed, but potentially vulnerable "bootloaders"


That's easy. It securely sends the users data to Microsoft.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: