Doran: We're were trying to figure out a way to armor the platform against attack in that pre-OS space.
There have been a number of documented instances of people trying to introduce [code] that usurps control of the platform before the operating system gets in to run. The operating system thinks it is on a pristine platform, when in fact there is malware lurking between the platform and the operating system. It could be either persistent in the shape of a virtual machine living between the operating system and the hardware, or the malware could be a boot loader that introduces malware into the pre-OS space.
We wanted to figure out a way to make sure only code that can be trusted will run in that pre-OS space. With the motherboard ROM, you have to be careful about what gets updated there. And you have to make sure that any code that executes on the path between the reset vector and the entry point of the operating system loader is also trusted.
We're asking the add-in card [manufacturers] to sign the driver images with keys that the platform knows. So that when the operating system installer has indicated that it is using this card for a boot device, the platform can check the UEFI driver that lives on the card to see if it signed. You can have a reasonable amount of trust in that.
With UEFI, the platform stores a set of well-known public keys that it could use in a typical crypto signature check routine. So when an Option ROM [pre-OS code that can be called by the system's ROM to make an add-in card usable as a boot device] comes along, the platform can use the public key to compare against the signature that is on the driver.
In essence, the firmware carries the public key information for well-known keys. It is used to check an Option ROM each time the platform is run. Same thing for the loader. Once you get to the operating system, UEFI makes sure that control is being handed to the loader that the user intended, and not to a malware loader. Secure Boot gives you an assurance that the bag of bits you are about to run -- the Option ROM or the boot loader -- came from who it said it came from.
The idea is to have a platform that is more resistant to attack at all stages of its lifecycle. And that is what we are trying to achieve with Secure Boot. It gives the operating system a more solid foundation to start from.
IDGNS: If I'm an operating system provider, how do I get a signature to match one of the public keys in the firmware?
Doran: An operating system vendor can make a number of different choices as to how it wants to use the mechanism.
A platform could not do signature check at all, so it will not enable the Secure Boot feature. On the other end, it can only run trusted code between the operating system and the reset vector, making sure everything is installed by keys in the platform.