Hacker News Reader

Comment by throw1230 | Hacker News Reader

I think it's perfectly acceptable that a device ships with a secure default as long as it lets you override it

From TFA:

> [...] the firmware defaults to not trusting bootloaders or drivers signed with the Microsoft 3rd Party UEFI CA key.

The whole point of secure boot was that there is a known set of "good actors" who are trusted by default, so that you can boot 1. Windows 2. common Linux distros - without any fuss, and 3. Any other system - with a few extra steps to prove you know what you're doing.

They've de-ranked the set #2 and threw it in the bag with #3, which doesn't really do much at all to improve security, but it does inconvenience and disincentivise the users from using a Linux distro on this hardware.

It's most likely an honest mistake, a sign of incompetence, or a dick move. Write them an angry letter and carry on.

It's interesting as Thinkpads have always been a reliable laptop for linux users - I'm typing this on linux on a t470 (my previous t410 had given up the ghost), but I bought my first thinkpad back in 2000ish, with a pcmcia wireless card.

Reliable Linux laptops in spite of Lenovo.

not

> They've de-ranked the set #2 and threw it in the bag with #3, which doesn't really do much at all to improve security, but it does inconvenience and disincentivise the users from using a Linux distro on this hardware.

Well no, it's not Lenovo really, it's Microsoft and its Device Guard / Secured Core that has done so. You can disable that just as easily as you can boot from an USB stick.

What's the difference in security here?

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.

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"

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.

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)

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

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).

I generally agree with that, but I don't think that holds for Lenovo. Wasn't it Lenovo that compromised the security of Windows by installing a keys-included general purpose root certificate?

You could argue that Windows is the less secure default here.

Reply on news.ycombinator.com