Got a Surface Pro 3 today and noticed in it's EFI that it's got

  • TPM enabled,
  • "Secure Boot" enabled (unsure what such an umbrella/catch all term actually covers)

And then in Windows 8.1, it's got

  • BitLocker turned on

I was a little surprised that the OS was able to bootup completely (to user login screen) without any input from the user; meaning all keying material is resident and available to the machine without user intervention. It also made me reflect a bit on the process so thought I'd post this here.

Question: Can someone enumerate the secure boot process (as implemented on modern PCs) and how the chain of trust is established and maintained?

Finally, how does this give the user any assurance that their machine hasn't been compromised behind them? (like Evil Maid etc)

  • This question is related to your final question.
    – alx9r
    Commented Nov 27, 2014 at 23:43

2 Answers 2


Boot Process

Secure Boot

There are quite a few steps to booting Windows 8. Now secure boot in general means that the boot loader is only run if its integrity can be checked. In this case, if enabled, the UEFI is started before anything else and checks that the boot loader is signed by a trusted Certificate Authority. For an operating system generally only the manufacturer is trusted, e.g. Microsoft. As long as the boot loader is signed by Microsoft, and verified by the UEFI then the boot loader is started. Even the UEFI drivers are verified[1].

The EUFI contains a database of registered trusted authorities. Users can add their own trusted authorities to this database in order to enable the loading of non-Microsoft operating systems.

This is where Trusted Platform Modules (TPMs) are used. TPMs can be used to store keys, or perform encryption/signing/verification routines. The TPM combined with the UEFI is what allows for the verification of the boot loader, and the loading of an operating system.

Trusted Boot
Now that's not the end of a secure boot process. Now that the OS is in a trusted boot state it begins loading the kernel, system drivers, etc. Secure boot also ensures that the system drivers are signed by a trusted certificate authority (e.g. Microsoft).

enter image description here

Full description of the image above


At each stage of the boot process certain pieces of code (drivers, system services, etc) are being registered with the operating system. The earlier in the boot process that malware can hook in the more likely they can:

  1. Persist: even on reboot, the malware is re-enabled
  2. Hide: put itself in a position to stealthily keep the operating system (and antivirus) from noticing its there.
  3. Privileged: continue to grant high permissions to itself

All of these boot processes are run at the highest privilege. Without a secure mechanism for trusting these loaders rootkits could install themselves with high privileges, and the system wouldn't even know they were there. Requiring signed boot loaders and system services/drivers decreases the chances that a rootkit can get a foothold into your system. This does not mean that it's 100% secure, it just makes it a lot harder at certain stages of booting.

Evil Maid

Evil Maid is based on the premise that a hacked boot loader can be installed on the system to do mischief, keylog the password used to decrypt the volume, etc. This is exactly the type of attack this process is meant to prevent. A boot loader could not be flashed on here and successfully booted unless it was signed by Microsoft (or some other trusted authority IF the user decides to trust someone else). This seems fairly unlikely, and it would be unsafe to add a trusted 3rd party to the EUFI database.

Could a piece of hardware come with other trusted authorities installed from the distributor? Maybe, but that's a whole other level of paranoia. If you're worried at that level then you're probably doing something wrong in life.

Enabling User Authentication

The guide above can guide you through enabling a TPM on Windows 8, and setting a password for it. I'm unsure if this also applies to tablets.

  • A point worth noting is that by design, UEFI Secure Boot requires the existence of only one single trusted signing key, shared by all computers running Windows through SB, and currently owned by Microsoft.
    – Hadrien G.
    Commented Nov 10, 2014 at 8:36
  • OS politics aside (why should Microsoft be the only one in control of what is trusted on my computer?), this means that once this key will be compromised, and it will, the security of this mechanism will be irrevocably void for all computers sold before the date of the exploit.
    – Hadrien G.
    Commented Nov 10, 2014 at 8:40
  • To call this a horrifically insecure design would be an understatement. And it adds weight to the suspicions of many that Secure Boot is about platform control, not security. One has to wonder how this idea of having only one single Platform Key, that is enrolled by the first SB-compliant OS run by the machine and may subsequently only be changed in a standard way by the PK owner, made it past the UEFI review process.
    – Hadrien G.
    Commented Nov 10, 2014 at 8:43
  • 2
    Update the TPM certificate + sign the OS bootloader with a new certificate to fix your Doomsday situation. All of that can be pushed out via a Windows Update patch. Custom bootloaders (e.g. Linux) can add their own cert to TPM too. Not a big deal actually ... Commented Dec 2, 2014 at 23:37

Below blog has good intro to Windows' use of Secure Boot, Trusted Boot, and Measured Boot: Link As to 'horrificially insecure', None of these are fully-secure, for example Intel has created Boot Guard technology to help protect system at silicon/firmware level, before Secure Boot technology kicks in. Android and Chrome both have similar PKI-based boot loaders with Verified Boot. As to why why MS is in control of trust, they're one option as UEFI Forum's default CA. An OEM or BIOS vendor could choose to do their own CA, but also Windows OEM requirements add this: Microsoft wants to have some control over the user experience of a Windows-based system, and it's security. Bad for user customization and alternative OSes, but perhaps some minor security improvements in the process. HTH. Lee RSS: http://firmwaresecurity.com/feed

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .