Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 2:52 UTC (Fri) by geofft (subscriber, #59789)
In reply to: Garrett: Secure Boot and Restricted Boot by hummassa
Parent article: Garrett: Secure Boot and Restricted Boot

I think the car analogy is breaking down here, but as far as Secure Boot goes, that is simply impossible. There is no way for an OS to reliably know whether it was booted in Secure Boot mode or what keys were available -- you can very easily write a bootloader shim that intercepts the EFI APIs for accessing variables, loads an actual bootloader (like Windows'), and falsely reports that Secure Boot was enabled and only the MS key was trusted.

Remember that Secure Boot is for the hardware deciding whether to trust (and go ahead and execute) the OS, not vice versa. If you want the reverse, you want a TPM, which lets an OS decide whether to trust the hardware (and again, not vice versa).

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 15:40 UTC (Fri) by ortalo (guest, #4654) [Link] (1 responses)

Also for the TPM: not vice versa? With a TPM you mean the hardware does not have a mean to decide if it can trust the OS?

Garrett: Secure Boot and Restricted Boot

Posted Mar 29, 2013 18:53 UTC (Fri) by geofft (subscriber, #59789) [Link]

Correct. The TPM is a little chip on the motherboard that can do cryptography. The usual way it's used is that it's configured to read in and hash every piece of code run in the boot process (starting with the TPM itself reading the BIOS code, then the BIOS passing option ROMs and the boot sector, then the boot sector passing on anything it loads). At this point the TPM has a "measurement" of the boot process; a salted hash of all code that runs with some secret burned into the TPM itself.

The TPM has the ability to "seal" or "unseal" an encryption key (just another level of encryption) based on the measurements. So you can use it for full-disk encryption, by sealing your encryption key against the measurement of the boot proess. If the boot process changes (e.g. there's a boot sector virus), or you move the disk to a machine with a different TPM, you can no longer unseal the key to the disk, because you don't have matching measuments any more. You can also use it for remote attestation, by having a network server send the OS a challenge that it gets the TPM to respond to, where the response can only be constructed if the measurements match.

One thing you'll note that the TPM does not have the ability to do is to _stop_ code from executing. It sits there quietly watching what code is executed. It can refuse to provide the encryption key, but it can't, for instance, prevent a malicious boot loader from playing a fake Windows boot animation, popping up a login screen, sending the password somewhere, removing itself, and bluescreening. User data is protected, but even so, it's a lot easier to mount attacks since the attacker has code running on your machine.

The other thing about Secure Boot is that it's possible to implement it just within the existing boot firmware, without requiring a separate processor for doing crypto. Yes, you could imagine the TPM having signature verification capabilities, but it's better to put it on the firmware that already ships with every machine, instead of requiring additional hardware on all machines.