4 ms·

This document is aimed at OEMs, but they specifically say that high-security environments can generate Secure Boot keys and use them on their devices in conjunc

This document is aimed at OEMs, but they specifically say that high-security environments can generate Secure Boot keys and use them on their devices in conjunction with their own Windows image. (I’d imagine that you need the Windows SDK and some know how/MS consulting to get it working, though) https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#2-key-management-solutions https://docs.microsoft.com/en-us/windows-hardware/manufactur...

shawnz 7y ago
This document is about generating the platform key, but changing the platform key alone doesn't allow you to do what I'm suggesting. Even after setting your own platform key you would still need to trust the key for Microsoft's bootloader. See section 1.4.1: > The Microsoft Windows Production PCA 2011 with a SHA-1 Cert Hash of 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d must be included in db in order to allow the Windows OS Loader to load.
- p_l 7y ago
  For OEM to allow reinstall done "normally", yes. But DB entries can also contain SHA-256 hashes of the image to load (with the image stripped of the signature, which btw allows you to also resign it). https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ https://blog.hansenpartnership.com/the-meaning-of-all-the-ue... https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf https://www.nsa.gov/Portals/70/documents/what-we-do/cybersec...
  - shawnz 7y ago
    > which btw allows you to also resign it Are you sure? I havent tried, but this disagrees: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/dn747883(v=win.10)?redirectedfrom=MSDN https://docs.microsoft.com/en-us/previous-versions/windows/i... "Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows boot components verify the signature on each component. Any non-trusted components will not be loaded and instead will trigger Secure Boot remediation. " > DB entries can also contain SHA-256 hashes OK, fair enough, but it still doesn't really solve the problem because an attacker could just copy your modified bootmgr to be able to steal and use your workstation. In order for this to work you'd also have to add some kind of additional checks which we can now do with an open source version of the bootloader.
    - p_l 7y ago
      The signatures are, IIRC, checked in order, so a resigned BootMgr won't impact verification of WinLoad, etc. As for abusing signed bootloader, the full process depends on verifying that the signed bootloader appropriately handles TPM, which is then also coupled with an encrypted disk, which in turn works to prevent loading unsanctioned code. Of course, it's possible to defeat this, but the idea is to frustrate the efforts and raise the cost of an attack, as well as give you a longer timeframe to deal with an attack.
      - shawnz 7y ago
        Those mechanisms only prevent an attacker from decrypting the disk. The scenario I'm envisioning is where the attacker steals your workstation, wipes the disk and reinstalls Windows.
        p_l 7y ago
        That's not part of the threat model - the encrypted data is lost, the point of the defences are to prevent damage to things accessible from that specific machine, not to prevent stealing the machine.
        shawnz 7y ago
        That's not part of Microsoft's threat model. Which is exactly the problem! It could be done, if only Microsoft supported that use case. But with an open source bootloader, we could make the necessary changes ourselves.
        p_l 7y ago
        No, that's the threat model that most clients that require high security have (the machine is often nigh-infinitely cheaper than the data and access rights), and MS, surprise, explicitly insists (in difference to secure boot spec) that owner of the physical machine is, well, it's owner and can reinstall, resell, etc.

shawnz 7y ago

This document is about generating the platform key, but changing the platform key alone doesn't allow you to do what I'm suggesting. Even after setting your own platform key you would still need to trust the key for Microsoft's bootloader. See section 1.4.1: > The Microsoft Windows Production PCA 2011 with a SHA-1 Cert Hash of 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d must be included in db in order to allow the Windows OS Loader to load.

p_l 7y ago
For OEM to allow reinstall done "normally", yes. But DB entries can also contain SHA-256 hashes of the image to load (with the image stripped of the signature, which btw allows you to also resign it). https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/ https://blog.hansenpartnership.com/the-meaning-of-all-the-ue... https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf https://www.nsa.gov/Portals/70/documents/what-we-do/cybersec...
- shawnz 7y ago
  > which btw allows you to also resign it Are you sure? I havent tried, but this disagrees: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-8.1-and-8/dn747883(v=win.10)?redirectedfrom=MSDN https://docs.microsoft.com/en-us/previous-versions/windows/i... "Windows boot components: BootMgr, WinLoad, Windows Kernel Startup. Windows boot components verify the signature on each component. Any non-trusted components will not be loaded and instead will trigger Secure Boot remediation. " > DB entries can also contain SHA-256 hashes OK, fair enough, but it still doesn't really solve the problem because an attacker could just copy your modified bootmgr to be able to steal and use your workstation. In order for this to work you'd also have to add some kind of additional checks which we can now do with an open source version of the bootloader.
  - p_l 7y ago
    The signatures are, IIRC, checked in order, so a resigned BootMgr won't impact verification of WinLoad, etc. As for abusing signed bootloader, the full process depends on verifying that the signed bootloader appropriately handles TPM, which is then also coupled with an encrypted disk, which in turn works to prevent loading unsanctioned code. Of course, it's possible to defeat this, but the idea is to frustrate the efforts and raise the cost of an attack, as well as give you a longer timeframe to deal with an attack.
    - shawnz 7y ago
      Those mechanisms only prevent an attacker from decrypting the disk. The scenario I'm envisioning is where the attacker steals your workstation, wipes the disk and reinstalls Windows.
      - p_l 7y ago
        That's not part of the threat model - the encrypted data is lost, the point of the defences are to prevent damage to things accessible from that specific machine, not to prevent stealing the machine.
        shawnz 7y ago
        That's not part of Microsoft's threat model. Which is exactly the problem! It could be done, if only Microsoft supported that use case. But with an open source bootloader, we could make the necessary changes ourselves.
        p_l 7y ago
        No, that's the threat model that most clients that require high security have (the machine is often nigh-infinitely cheaper than the data and access rights), and MS, surprise, explicitly insists (in difference to secure boot spec) that owner of the physical machine is, well, it's owner and can reinstall, resell, etc.