4 ms·
> The only piece of information we're missing, and which having the docs become public would reveal It has been documented for a while really: https://docs.mi
by Avamander 4y ago
> The only piece of information we're missing, and which having the docs become public would reveal
It has been documented for a while really:
https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-requirements#2016-additional-security-qualifications-starting-with-windows-10-version-1607-and-windows-server-2016 https://docs.microsoft.com/en-us/windows/security/identity-p...
- jsiepkes 4y agoThat document does not specify the requirements Microsoft imposes on consumer PC OEM'ers such as Lenovo, HP, etc.
- Avamander 4y agoIf you want to call your model Device Guard compatible or even Secured Core compatible (which requires Device Guard), then it does.
- Arnavion 4y agoSearching for that phrase "Microsoft UEFI CA must be removed from Secure Boot DB" returns a link to a Microsoft presentation at UEFI Plugfest 2016 [1] It doesn't directly say why that requirement was introduced, though one could gather from the context that it's being done for security. But perhaps more interesting is that both this presentation and the MSDN page you linked also talk about enterprises being able to control what runs on the hardware themselves. Your MSDN page has: >Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. ... and the presentation has: >Security Certificates added to my device are documented and justified, with a pre-defined security response plan. So I wonder if the reason is just "We wanted to make it convenient for enterprises to not have to do a pre-provision step to remove the UEFI CA, so instead we mandated OEMs to not enable it in the first place." It would be extremely silly if that turned out to be the reason... [1]: https://uefi.org/sites/default/files/resources/UEFI_Plugfest_March2016.pdf https://uefi.org/sites/default/files/resources/UEFI_Plugfest...
- Avamander 4y agoThere are vulnerable bootloaders signed with the UEFI CA. Disabling less heavily vetted CA on devices that are being sold as basically hardened, makes sense. But yeah, one aspect of it might be making it easier for enterprises, that's a large focus.
- Arnavion 4y agoWell that's what the revocation list is for, but yes I can imagine choosing the nuclear option of just dropping the CA is attractive because it's less work for everyone involved.
- AshamedCaptain 4y agoThere are also vulnerable bootloaders signed with the MS production CA. The DBX set is not just shim hashes, you know. If MS's distrusts its own ability to vet other people's code, why trust their ability to vet their own code?
- Avamander 4y ago> If MS's distrusts its own ability to vet other people's code, why trust their ability to vet their own code? If you want to do the legwork yourself, feel free to roll your own PKI and sign things you trust yourself.
- AshamedCaptain 4y agoThis fails to answer the question.
- Avamander 4y agoIt was a leading question, answer to which only you can know based on your threat model. I did however say what you can do if you don't trust Microsoft, which also makes the question quite irrelevant.