Where do I 'sign' up?

This post spends a little time discussing how to get pre-OS independent software vendor (ISV) content ‘signed’/’enrolled’ onto a UEFI Secure Boot protected platform.

As a quick background:

Intel (R) Boot Guard binds the OEM low level boot firmware (PI code as exemplified by SEC/PEI/DXE) with the hardware, so the Boot guard trust anchors would not directly interface with the trust anchors for 3^rd party UEFI content.  Details on Intel Boot Guard can be found on page 4 of http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/4th-gen-core-family-mobile-brief.pdf.  

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 3^rd 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

o   Have end user enroll manually

and/or

o   Have 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:

http://www.uefi.org/sites/default/files/resources/UEFI_Plugfest_2013_-_New_Orleans_-_Microsoft_UEFI_CA.PDF

http://msdn.microsoft.com/en-us/library/windows/hardware/gg463054.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/hh801894.aspx

For the second option 2. above, if the ISV wishes to generate its own roots and manually enroll in a PC (e.g., using PC setup screens) or distribute its keys for the OEM’s to pre-enroll, some details on the process can be found at http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=SecurityPkg

Beyond this information, some of the practices of a Security ISV like McAfee for their pre-OS UEFI content can be found at

http://intelstudios.edgesuite.net/idf/2012/sf/aep/EFIS003/EFIS003.html 

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 http://apps.insyde.com/sbutil.html from Insyde on your Microsoft (R) Windows 8 machine.  Thanks to Jeff Bobzin at Insyde for pointing this tool out to me.

This is the report from my Asus Windows 8 Intel (R) i3 touch laptop.  Well, my former laptop prior to my fourteen year old daughter commandeering it.  The output from the report proceeds below-

Secure Boot Status on this system:

System Status: MS Required KEK: MS Required OS Cert: 3rd Party (MS CA):

Secure Boot Enabled Present Present Present

UEFI Variables:

SetupMode: 
SecureBoot: 
OsIndicationsSupported: 

BootOrder Item List: 
BootCurrent: Boot00000 1 0000000000000001 0000 0000 Windows Boot Manager

Secure Boot Database Contents:

PK Variable Certificate (Platform Master Key):

X.509 Certificate:

CN=ASUSTeK Notebook PK Certificate

KEK Variable Certificates (Database Management):

X.509 Certificate: X.509 Certificate: X.509 Certificate:

CN=ASUSTeK Notebook KEK Certificate 
CN=Microsoft Corporation KEK CA 2011 
CN=Canonical Ltd. Master Certificate Authority

db Variable Certificates and Hashes (Allowed Signers):

X.509 Certificate: X.509 Certificate: X.509 Certificate: X.509 Certificate: X.509 Certificate:

CN=ASUSTeK Notebook SW Key Certificate 
CN=ASUSTeK MotherBoard SW Key Certificate 
CN=Microsoft Corporation UEFI CA 2011 
CN=Microsoft Windows Production PCA 2011 
CN=Canonical Ltd. Master Certificate Authority

dbx Variable Certificates and Hashes (Forbidden Signers):

X.509 Certificate:

CN=DO NOT TRUST - Lost Certificate

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 http://www.ubuntu.com/.

Below is a friendlier view of the tool in action.

Finally, back to closing thoughts on the Intel Developer Forum. 

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.

Cheers

2/15/2015 update -
My friend's book http://www.apress.com/9781430265719 has a good description of Boot Guard in chapter 6.  Take a look.

End of summer '13

The unusually warm summer proved a bit confusing to the psyche.  The return of the Pacific Northwest rain of late brings me back to normalcy.

I haven't blogged in a while, but I must recommend and continue to be impressed by he writing of Tim Lewis at http://uefi.blogspot.com/.  Really good stuff.  I have appreciated the opportunity to work with Tim over the last decade or so and I am in continual awe of his intelligence and prolific output.

Let's begin with something of a meta-blog as an introduction today.  I sometimes censor my content for fear of being read as an advocate of a specific technology, or detractor of another. Sometimes 'is' versus 'ought' gets confused in such writings, namely the difference between describing a technology and evangelizing the same.  I felt alone in this tension until listening to Violet Blue and her description of today's confusion around 'information' versus 'advocacy' with the tech culture. The talk 'Hackers As A High-Risk Population [29c3]' https://www.youtube.com/watch?v=zq-bloM4Cmo elaborates on this point, among others.  

Of course, I surely have subconscious confirmation bias based upon areas with which I'm more familiar, but information comprises the intent of the following.   

Enough of the caveats, let's talk about architecture versus implementation.   

In the world of central processing units and hardware, we often refer to the distinction as 'architecture' versus 'micro-architecture.' The former describes the public description of the instruction set architecture (ISA), memory model, protection modes, and other modalities of the hardware that provide the consistency against which compiler writers, application developers and system software engineers can base their software development.  For Intel, these details are codified in the Software Developer Manual (SDM) http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html.  The micro-architecture, on the other hand, provides details on 'how' the architecture is implemented given adherence to the architecture as an outward constraint, but compounded with additional constraints of design inventiveness, power envelopes, transistor budgets, design invention, and schedule constraints, among others. It is in the world of micro-architecture where techniques like in-order versus out-of-order, additional functional units, bus width, number of ports to the memory and register file, micro-coded versus hardwired, and other techniques come into play. 

That's for the world of CPU's and hardware.  Correspondingly, the world of software defines the demarcation as 'interface' versus 'implementation.'  The former include the POSX API's, Win32, the UEFI Boot Services, and to even stretch the metaphor a bit, network wire protocols.  For the latter, implements include the Linux kernel, Microsoft Windows, the edk2 development project, and the venerable BSD TCP/IP network stack.  The line is not always clear initially, and some implementations become a de facto implementation, such as the Microsoft DOS binary executable.  The same holds true for the original PC/AT, where the public description http://bitsavers.trailing-edge.com/pdf/ibm/pc/at/1502494_PC_AT_Technical_Reference_Mar84.pdf of the hardware and software 'implementation' became the 'architecture' foundation, now referred to nostalgically or disparagingly as 'legacy', of the PC ecosystem.

Let's get into some details on where the architecture and implementation come together with respect to host firmware.  From a most generic taxonomy, there are two phases of execution.  The first is a 'platform initialization' and the second is a 'boot loader' phase.  The former phase entails initialization of the system board hardware and passing control to the boot loader phase.

All of these processes of booting entail passing control from one domain of execution into another.  These can include system boards that need boot firmware to launch a shrink wrap OS or a vertically integrated embedded system wherein the firmware producer and the OS producer are the same entity.  There are often different instances in the market depending upon the requirements of the business entities.

For the first phase, here is a quick chart mapping two well-known boot firmware technologies found on Intel Architecture.

Platform Initilization     coreboot          UEFI PI

Reset vector               Boot block           SEC

Memory init                ROM stage          PEI

I/O init                        RAM stage          DXE

Boot loader phase       Payload               BDS

Of the boot loader phases using coreboot payloads, these can include U-Boot as an implementation with SeaBIOS and a direct kernel load as alternate 'hand-offs' of control. Those hand-offs of control can include the Advanced Configuration and Power Interface (ACPI) http://www.acpi.info or the flattened device tree (FDT) evolved from open firmware IEEE 1275 http://www.openfirmware.org/1275/.  For the boot loader phase of the UEFI PI, the most well known embodiment is the Unified Extensible Firmware Interface (UEFI) presently at revision 2.4 http://www.uefi.org.  

For an architecture to implementation mapping, SEC, PEI, DXE, and BDS can be found in the 5 volumes of the UEFI Platform Initialization (PI) specification, presently at revision 1.3, at http://www.uefi.org.  The architecture is represented by .h files in the https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdePkg/ and implementations of the platform portable elements in https://svn.code.sf.net/p/edk2/code/trunk/edk2/MdeModulePkg/.  For coreboot, an overview can be found at http://www.coreboot.org/Welcome_to_coreboot and representative implementation practice at http://review.coreboot.org/#/q/status:open,n,z.  

The story is not so straightforward, though.  Coreboot can have edk2-style firmware as a payload, such as found in the 'PIANO' project, or 'Payload using Tiano.'  Recall that "Tiano" was Intel's original code-name for what became the Intel (R) Framework and EFI, then UEFI PI and UEFI reference implementation.   You can still find reference to 'Tiano' on the edk2 project http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2, too.  Correspondingly, the Boot Device Selection (BDS) driver in a edk2-based PI implementation can do a direct Linux kernel load and publish a FDT, as found in ARM Ltd's (R) adaptation of edk2 in https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmbeddedPkg/.  

The point of FDT/ACPI is to expose non-discoverable resources to the operating system.   And the point of U-Boot/UEFI is to assist in loading the operating system kernel via the local NV store, disk, or network and passing control to the same.  We discuss some of the uses of UEFI/PI for embedded at http://linuxgizmos.com/using-uefi-in-embedded-and-mobile-devices/, too.

Recall my mention of Intel Architecture above.  In general, UEFI has processor bindings to 32-bit or IA32 and 64-bit Intel Architecture, or 'x64' as known in the UEFI spec.  The latter has been alternately called x86-64, AMD64, EM64T, and Intel64.  UEFI also supports Intel(R) Itanium and both 32-bit and 64-bit ARM ISA.  The latter 2 are Aarch32 and Aarch64, resp.  Beyond that, there have been ports to other architectures not covered by the UEFI specification, such as 32-bit MIPS http://sourceforge.net/projects/efi-mips/.

Correspondingly, the coreboot tip has IA32 support and recently has added 32-bit ARM.  In the past, PowerPC support was also found in this project.

U-Boot has an even broader CPU support set since for certain CPU and platform architecture, the hand-off to the "Boot Loader Phase" can be done by opaque firmware and hardware in the platform.  In other words, the "reset vector", "memory init," and "I/O init" happen in the 'hardware' and do not require UEFI PI or coreboot style processing.

So in the spirit of 'information' versus 'advocacy,' you can see that the different facets of the solutions above can map to alternate deployment needs.  For a shrink-wrap OS that wants a guarantee of system board behavior into the "boot loader phase," the industry standard ACPI+UEFI couplet has some merit. For defacto standards like the kernel load protocol of Linux, FDT+U-Boot or FDT+UEFI may suffice.  

And the distinction between architecture and implementation rears its head again with respect to security.  As noted as recently as Blackhat this year by Yuriy Bulygin, et al. http://www.blackhat.com/us-13/speakers/Yuriy-Bulygin.html in their presentation http://c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-Bazhniuk_BHUSA2013.pdf, any flaws in implementation of the architecture can allow for bypassing of the controls for which the architecture was intended to enforce. In this case, the policy objects and implementation of UEFI Secure Boot represented the implementation artifacts that failed to successfully refine the architecture to the code in the system board storage. This is an example of the classic assurance consideration and reads into the firmware design space.  Security is not alone.  Performance, manageability ease-of-use, size, and other metrics can be impacted by the refinement process of a high level architecture to code.

As a final thought, I will be at the Intel Developer Forum next week talking about "UEFI Secure Boot and Linux" https://intel.activeevents.com/sf13/connect/sessionDetail.ww?SESSION_ID=1064.  This talk reads on many of the themes treated in this blog around building an implementation of an architectural feature, specifically the administration of policy objects for features like UEFI Secure Boot. For this talk, the architecture of UEFI Secure Boot can be found in Chapter 26 of the UEFI 2.4 specification.  This has our familiar friends the Platform Key (PK), Key Exchange Key (KEK) and the allow/disallowed list of the db/dbx.  These authenticated variables and how they inform the policy-based load of 3rd party UEFI images is well defined in that document.  What is absent from the document is how a security administrator (e.g., security_admin_r) or end user manages the UEFI Secure Boot behavior.  This gap stems from the absence of manageability interfaces to a given platform in the UEFI Specification, among other things.

So in order to appreciate UEFI Secure Boot as an end user, the description and implementation of the feature in chapter 26 is necessary but not sufficient.  Even for assessing the overall integrity goals of the feature, you need to assess the end-to-end solution, such as shown below in one embodiment.

End-to-end platform integrity

As you can see from above, the underlying UEFI PI implementation must guarantee its provenance, such as through NIST 800-147 http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf specified updates.  Another means by which to effect the same would be a load-time verification of the UEFI PI code from the 'hardware' block that I will discuss at IDF.  Finally, SUSE will discuss some options to support the "OS Secure Boot."  Note that the UEFI specification only reads on the center of the diagram, and even for this portion, it does not describe how to manage the PK, KEK, and DB/DBX other than through cryptographically signed updates of the same by the private key owner.

For the latter key management, a end user who is a kernel hacker may manage the key store directly via physically present interaction with the firmware setup screens and load his/her own keys. A consumer, on the other hand, just wants it 'to work' with live CD's and other shrink-wrap binary images from different OS vendors without any administrative changes. In the former two cases, the 'owner' and 'user' are typically one in the same. A corporate IT, on the other hand, only wants the IT staff to manage and change these options since the 'user' or knowledge worker of a client machine is distinct from the 'owner', who is typically the knowledge worker's employer.  And the IT staff simple acts as an agent of the owner and the owner's elevated privileges.

On the subject of assurance, many people use UEFI variables for storing PI-specific content. The problem with that scheme is that after the signalling of EFI_END_OF_DXE_EVENT_GUID from volume 2 of the UEFI PI spec at www.uefi.org (aka "Exit PM_AUTH" from http://www.intel.com/content/dam/doc/white-paper/uefi-pi-tcg-firmware-white-paper.pdf or "Exit Mfgr Auth" from http://www.uefi.org/sites/default/files/resources/Intel-UEFI-ThreatModel.pdf) and/or when BDS does a connect on the driver load list and the UEFI boot variables, 3rd party UEFI content will run. Even in the case of UEFI Secure Boot, you know the provenance of code but not if the UEFI loader or OS runtime will attack the platform. Given that case, the PI-only variables should be prohibited from change by the 3rd party UEFI drivers, applications and operating system runtime.  One way to do this protection is to use the edk2 variable lock protocol (EDKII_VARIABLE_LOCK_PROTOCOL) http://permalink.gmane.org/gmane.comp.bios.tianocore.scm/842.  Note that this API is in the edk2 project but not prefixed with "PI" or "EFI" since it does not exist in the industry standard specification. This API allows for downgrading a variable to read-only (RO) from read-write (RW) prior to running third party code. It also covers a gap in the UEFI  and PI specifications wherein the SetVariable API in chapter 7 of the UEFI specification does not read on creation of RO variables; the main UEFI specification only describes the need for a set of RO variables to exist.  How the underlying PI-based code creates these RO UEFI variables was left as an exercise for implementations.  The EDKII_VARIABLE_LOCK_PROTOCOL provides one 'answer' to that exercise.

So what have we seen in this blog?

1) Explanation of technology without marketing for same

2) Many examples of architecture versus implementation

3) For boot firmware, there are many different architecture and implementation

4) Take due care in traversing from architecture to implementation

5) Take a systems view of a solution beyond a given technology's architecture and implementation