Event details
MicrosoftHi Mihi, I noticed that you have been very active answering questions. Thank you for all of your efforts.
Hi Mihi, I’ve noticed how active you’ve been in answering questions. Thank you for all your efforts — it’s been very helpful.
- I don't know of a way to do this in Windows. As far as I know it's not possible.
- As far as I know, there isn’t a way to do this in Windows. The boot managers that enforce the Secure Version Number (SVN) are designed to avoid running if they don’t meet the minimum SVN defined in the DBX. Blocking older boot managers, whether they’re on the internal disk or on external media, is intentional because it prevents rollback attacks. Unfortunately, this also affects some external bootable media scenarios.
You’ll see a new Get‑SecureBootSVN PowerShell command coming in March that should make it easier to check the SVN on a device. - Yes, it is possible to add the new third‑party certificates to the DB if you have administrative or physical access. For devices where this is a concern, we recommend using BitLocker with a PCR7 and PCR11 binding policy. PCR7 measures the Secure Boot state, so adding third‑party certificates to firmware would change the PCR7 measurement and trigger BitLocker recovery.
Thanks again for all your help in the discussion threads — it’s very much appreciated.
Arden
Hello Arden,
thank you for the feedback.
About the answer to the third question:
- To protect against physical access, BitLocker will certainly help. But I don't think it matters whether it binds against PCR7 or PCR4 (among others). As the boot binary signed by Third-Party CA will certainly not be identical to the one used by Microsoft
- To protect against malware having administrator/SYSTEM access, Bitlocker won't help. Attacker can just suspend (or disable) bitlocker before carring on with their attack.
- Arden_White
You’ve been bringing a lot of great points to these discussions, and I appreciate the work you’ve been putting in. It is making a real difference.
You are right. BitLocker will not protect against an attacker who already has administrative access, since BitLocker is designed to protect data at rest - meaning when the device is powered off.
PCR4 has a disadvantage in that some devices will run small firmware applications under certain conditions, and those executions are measured into PCR4. That can lead to unexpected measurement changes. For example, we have seen this when a battery is low and a firmware power application starts running. The device will then go into BitLocker recovery.
PCR7 behaves differently. It protects against Secure Boot configuration changes, and it can help protect against a boot manager swap if the replacement boot manager is signed by a different publisher than the original. I am doing this from memory, but that is the general behavior.
Thanks again