It has been a while since I have written about UEFI, Secure Boot and their impact on Full Disk Encryption (FDE) pre-boot authentication (PBA) so it’s time for an update on what is new in this area, but first here is a recap because this is a bit of an arcane technical subject. UEFI stands for “Unified Extensible Firmware Interface”. The UEFI specification defines a standard model for the interface between personal-computer operating systems and platform firmware.   It provides a standard environment for booting an operating system and running pre-boot applications such as the PBA for FDE.   It replaces the traditional legacy BIOS interface that was used with Windows 7 and older systems.   Now that Windows 10 is being widely adopted I expect to see UEFI used on almost all new machines.

Four years ago I wrote about the promise and practice of UEFI for FDE and noted that “Often it takes time for the implementations to converge to the standard. We have found that many of the implementations of UEFI just don’t support the UEFI features needed by pre-boot FDE pre-boot applications.”    Today this is still the case.  While most PC OEM UEFI implementations have the basics none have the advanced features such as wireless support for pre-boot networking.  Wireless support is in the latest UEFI standard but until the implementations catch up to the current revision of the standard  Independent Software Vendors (ISVs) like WinMagic will have to find other ways to deliver this extra value. (And we have some very advanced features:  https://www.winmagic.com/products/features/pba-pre-boot-authentication )

Meanwhile one of the key security features of UEFI, “Secure Boot”, has been implemented on 100% of the machines I have come across. With Secure Boot enabled the UEFI Boot Manager firmware that is built into the computer checks the signature of each UEFI driver and application that it loads. If the module is not properly signed (i.e. not trusted) or it has been revoked then the UEFI Boot Manager rejects the module and may display an error such as “Security Violation” at boot time.  Secure Boot helps thwart the “evil maid” attack   where the attacker gets access to the unattended, shutdown, computer and in the case of FDE modifies the UEFI PBA software to steal the user credentials the next time they are entered.   With Secure Boot on, the UEFI will reject the evil maid’s modified PBA code.  This blog, Microsoft is a good UEFI Ecosystem partner, describes how Microsoft has taken some responsibility for signing these pre-boot applications and made Secure Boot practical.

This brings us to Device Guard which is in the “What’s new” category.  For the purposes of this blog I will only address Device Guard as it relates to the pre-boot environment and ignore the OS present part. Device Guard builds on top of Secure Boot or to put it another way is a more restricted version of Secure Boot.   When Secure Boot is on the PBA UEFI application will verified by the BIOS and run if it is signed by at least one of:

• Microsoft’s own code signing certificate
• The Microsoft third party CA (That is what SecureDoc PBA  is signed by)
• The PC OEM’s code signing certificate
• Any certificate that that been specifically loaded into the machine’s Secure Boot certificate data base by the user

Device Guard at pre-boot is just Secure Boot minus support for the UEFI applications signed by Microsoft’s third party CA.    In practice this means that either the PC OEM has to sign the UEFI application or it is signed by the ISV and the co-responding ISV certificate  must be loaded in the Secure Boot certificate data base.

Personally I think most organizations will be fine with traditional Secure Boot for verifying signatures of the UEFI applications however some organizations will be prepared to do the extra work required to turn Device Guard on.   To run an ISV’s UEFI application with Device Guard on, the computer administrator will need to use a PC OEM supplied tool or BIOS menu feature to add the ISV’s cert to the machines’ Secure Boot Data base.

This is all good in theory but the PC OEM’s don’t necessarily have the tools ready to do this yet and there is still lots of testing to be done.   We will be working with the PC OEMS throughout the year to work the kinks out of the process so those end customers that really want to will be able to run Device Guard at the UEFI level with SecureDoc can.  Stay tuned for another update as we make progress on this topic.