4 ms·

What's the difference in security here?

by mjg59 4y ago

simiones 4y ago
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.
- Avamander 4y ago
  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"
- zinekeller 4y ago
  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.
- mjg59 4y ago
  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)
yesbut 4y ago
That's easy. It securely sends the users data to Microsoft.
mjg59 4y ago
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.
- zinekeller 4y ago
  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).

What's the difference in security here?

by mjg59 4y ago

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.

Avamander 4y ago
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"
zinekeller 4y ago
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.
mjg59 4y ago
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)

yesbut 4y ago

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

mjg59 4y ago

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.

zinekeller 4y ago
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).