This was always intended. If you don't want Microsoft keys sitting at the root of the trust chain, you can also enroll your own keys (with UEFI access). And Microsoft literally forced vendors to allow this by making it a requirement to be able to call a device Windows-ready or whatever it's called. Yes: MSFT explicitly wanted it to be possible to remove MSFT keys from your device.
There's many things that Microsoft deserves a lot of criticism for, but Secure Boot is not one of those things in my eyes.
What I do is seal the disk encryption key against PCR 7 (among others) so even if it secure boots up, unless it boots with grub verified with a specific key, it won’t be able to decrypt the disk.
PCR 7 tends to get changed with firmware updates, for example when Microsoft rotated its secure boot certificate (which is still a work in progress, depending on if you've installed a certain Windows Update or not).
Not a huge problem if you keep your recovery key ready when doing firmware updates (which you probably should be doing anyway) so you can re-enroll the key afterwards, but I believe this is the reason default configurations tend not to include PCR 7.
But indeed: the article describes secure boot working as intended and PCR 7 is one of the ways you prevent providing access to a drive in these circumstances.
Secure Boot’s MOK enrollment lets you enroll arbitrary keys without a BIOS password. By borrowing a Microsoft-signed shim from a package like ubuntu’s shim-signed, you can boot any OS on a corporate machine that has 3rd party certificates installed — which most do.
This allows you to boot a different OS, but will still not allow you to hack the existing one, the PCR registers will be different if you try chain-loading it.
Also, if you store part of the full disk encryption key in the TPM, you are also safe, the TPM will not release it. But there is a risk of the user entering their password (if they have one) in a fake login screen. But the OS will fail booting after that screen, so you need some plausible story to trick the user into not reporting the incident to IT.
If you have a laptop where you can install Ubuntu on it, this attack allows you to install a modified (unsigned) Ubuntu on it. So not much has changed.
"If you can mess around in the BIOS you can just enroll your own keys"
... and if your corporation has locked down the UEFI controls to prevent this, you can't. Forex: corporate Microsoft Surface, locked down with Intune (and Autopilot), you won't be getting far enough to do that.
This was always intended. If you don't want Microsoft keys sitting at the root of the trust chain, you can also enroll your own keys (with UEFI access). And Microsoft literally forced vendors to allow this by making it a requirement to be able to call a device Windows-ready or whatever it's called. Yes: MSFT explicitly wanted it to be possible to remove MSFT keys from your device.
There's many things that Microsoft deserves a lot of criticism for, but Secure Boot is not one of those things in my eyes.
What I do is seal the disk encryption key against PCR 7 (among others) so even if it secure boots up, unless it boots with grub verified with a specific key, it won’t be able to decrypt the disk.
PCR 7 tends to get changed with firmware updates, for example when Microsoft rotated its secure boot certificate (which is still a work in progress, depending on if you've installed a certain Windows Update or not).
Not a huge problem if you keep your recovery key ready when doing firmware updates (which you probably should be doing anyway) so you can re-enroll the key afterwards, but I believe this is the reason default configurations tend not to include PCR 7.
But indeed: the article describes secure boot working as intended and PCR 7 is one of the ways you prevent providing access to a drive in these circumstances.
This is not a hack. It's working as designed.
Secure Boot’s MOK enrollment lets you enroll arbitrary keys without a BIOS password. By borrowing a Microsoft-signed shim from a package like ubuntu’s shim-signed, you can boot any OS on a corporate machine that has 3rd party certificates installed — which most do.
This allows you to boot a different OS, but will still not allow you to hack the existing one, the PCR registers will be different if you try chain-loading it.
Also, if you store part of the full disk encryption key in the TPM, you are also safe, the TPM will not release it. But there is a risk of the user entering their password (if they have one) in a fake login screen. But the OS will fail booting after that screen, so you need some plausible story to trick the user into not reporting the incident to IT.
If you have a laptop where you can install Ubuntu on it, this attack allows you to install a modified (unsigned) Ubuntu on it. So not much has changed.
> so you need some plausible story to trick the user into not reporting the incident to IT.
Give them an authentic-looking "updating windows" screen after login, and reboot. 95% of users will bitch about Microsoft, instead of calling IT.
"If you can mess around in the BIOS you can just enroll your own keys"
... and if your corporation has locked down the UEFI controls to prevent this, you can't. Forex: corporate Microsoft Surface, locked down with Intune (and Autopilot), you won't be getting far enough to do that.