People often ask about the relationship of something like Intel (R) Boot Guard and its "Verified Boot" versus UEFI Secure Boot, as defined in chapter 26 of the UEFI 2.4 specification. We talked a little about this earlier, too, at http://uefidk.intel.com/sites/default/files/resources/Platform_Security_Review_Intel_Cisco_White_Paper.pdf,
page 16. The “Reset Time Verified Launch” in Figure 5 logically maps to something like Intel(R) Boot Guard. The verification happens 'before' UEFI PI code and vets the provenance of that code, typically if the code was created and updated under the authority of the system board manufacturer. UEFI, on the other hand, is on the right hand side of that flow.

In other words, the underlying PI-code update key, say for validating a capsule update (install time verification) or the embedded signature of the PI code (load time verification) should not be the PK but some other system board vendor-managed key store. Recall that on certain x86 systems the end user could even edit the PK via a physically-present setup page. In that latter case, having the end user control the PI update key (and associated system firmware updates) is often not desired. In the PI specification there are definitions of signed firmware files and volumes, but there is no defined policy store and trust anchors for 'Secure Boot' of PEI and DXE elements.

In the end, users want end-to-end integrity, though, so both protection of the underlying firmware and the run time are important. This was discussed a bit in the Intel Developer Forum presentation earlier in the month with the system architecture picture updated to the revised below.

Note in this picture above that Intel (R) Device Protection Technology with Boot Guard surfaces from the system hardware and precedes execution of the PI SEC/PEI/DXE codes.

UEFI Secure Boot, on the other hand, is intended for 3rd
party UEFI content, such as UEFI drivers or applications on the UEFI system
partition. Intel(R) Boot Guard and PI code verification keys should have their own manifest and storage structure. For the 3rd party trust anchors, the place where this enrollment would happen is with the UEFI Secure
Boot key hierarchy. The hierarchy for UEFI Secure boot includes the PK, KEK, DB,
DBX. The factory-default configuration typically entails a PK that is owned by the OEM, and the PK authorizes updates to the KEK.
The KEK is OS Vendor1 + OEM + other OS vendors, and the KEK entries authorize updates to the
DB/DBX. DB is the ‘allowed’ list of code that can execute, and for a Microsoft (R) Windows8 machine contains a Microsoft OS certificate, the Microsoft UEFI CA cert, and possibly
other OSV/ISV entries.

Now for going from theory-to-practice-

Given a population of UEFI
Secure Boot capable machines in the field, how is a pre-OS Independent Software Vendor (ISV) able to deploy content (i.e., the action item from above)? The
short answer is that the ISV has 2 options:

-1. Sign up w/
Winqual and get the UEFI driver/application signed by the UEFI CA

and/or

-2. Create own
verification certificate and

oHave end user enroll
manually

and/or

oHave OEM preinstall (or update in field via firmware update)

An ISV can do 1+2 above since
UEFI Authenticode-based executables support ‘multisigning’ so that they can be
signed by BOTH the UEFI CA and the ISV’s own key (see more on the final links
below w/ SUSE example).

For the first option 1. above,
the ISV can sign up w/ Microsoft Winqual and submit their content to be
signed by the Microsoft UEFI CA. Most ISV's, IHV's, and non-MSFT OSV's already has a
Winqual account if they deliver signed Windows drivers today since Microsoft
has been doing kernel mode driver signing since Vista SP1. In addition, most IA
machines that support UEFI2.3.1 Secure Boot carry a Microsoft UEFI CA DB
certificate, so getting signed by the MSFT UEFI CA will mean that the ISV's .efi UEFI driver or application will simply work on a large class of PCs.
More info on the process can be found at:

If you have a machine at home, you can use some of the flows described in the white paper above on running dmpstore and other commands at the UEFI shell to discover the configuration of UEFI Secure boot. A more user friendly way is to run the Secure Boot Checkup Utility

The interesting thing about this machine is that there is both a ASUSTeK KEK and Canonical KEK, along with the Microsoft KEK. So this set of KEK entries includes one for the OEM and two alternative operating system vendors, namely Microsoft for Windows and Canonical for Ubuntu

Within that deck, one of the slides I enjoyed the most was the quote on slide 21 from SUSE that read:

"UEFI Secure Boot no longer an issue to
the Linux*World"

Regarding IDF, it was great having the opportunity to meet with people from all across the industry. I found the perspective of what I do from the different companies refreshing and helpful in informing customer and business-focused activities with my colleagues going forward. Translation: I learned about a lot of things I need to get done quickly.

This IDF talk marked ten years since my first IDF presentation in San Francisco. I shuffled a bit less than the first talk, but I have to admit that I haven't evolved to the aplomb and sophistication of a Ted Talk http://www.ted.com. The irony is that one of those talks I delivered in 2003 read on porting the Intel Framework (PEI/DXE) for different platforms, factoring silicon initialization code, etc. Since 2003 Framework 0.9x specifications became PI1.3, the EFI Developer Kit (EDK) became EDK2, and the preceding UEFI track talk at IDF 2013 discussed factoring all of the silicon initialization PEI modules as this new Firmware Support Package (FSP) http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html. Oh yeah, Windows 8 shipped with UEFI as the default boot loader option recently, too. Quite the decade indeed.

Speaking of getting things done, I had better end today's entry and get back to work.