Late September mumbling

I'm back to the (still) sunny Pacific Northwest from the Intel Developer Forum (IDF) in San Francisco.  Roy Hopkins & I presented on UEFI and McAfee EEPC.  The presentation can be found at https://intel.activeevents.com/sf12/scheduler/catalog.do "Intel and McAfee: Hardening and Harnessing the Secure Platform" session EFIS003.  As an "Advanced" course, we stayed away from generic feature overviews and spent most time in design issues and code examples, including how a key logger could afflict a pre-UEFI Secure Boot system.   Some best practices for system design and coding were reviewed with the goal to follow-up w/ a document detailing this advocacy for posting at www.tianocore.org.   

Looks like I was premature calling September the end of the speaking circuit.   I will present at the Seattle Tech Forum on 10/17 along with speakers from Citrix and Cloudant on "Cases of Network Technology."   More details can be found at http://www.meetup.com/Sea-Tech-Forum/events/36852802/.  This meetup goes out to about 20k technologists in the Seattle area, so the subset of that list who show up in person should prove interesting. During my session, I will discuss the state of the art in UEFI pre-OS networking and security.

In addition, I will travel to down to the backyard of Intel, namely the Portland area, to talk about UEFI Secure Boot.

      October 4th, 2012

      UEFI Secure Boot and Open Source. 

      It's not a 'general war against computation.' 
 

More details can be found at http://pdxlinux.org and http://calagator.org/events/1250462851.   Judging by some direct messages from some of the possible attendees, it should prove to be an 'animated' meeting.

Speaking of UEFI Secure Boot, the Register picked up the posting http://www.itsec.it/2012/09/18/uefi-technology-say-hello-to-the-windows-8-bootkit.   Akin to many earlier presentations, from John Heasman in BlackHat 2007 to Loukas K's BlackHat 2012 talk, they all conclude with the sentiment that UEFI image signing is a good idea.  For Heasman, his advocacy antedated UEFI Secure Boot, but Loukas K and the ITSEC posting all advocate UEFI Secure Boot as part of their mitigation recommendations to address attacks against arbitrary UEFI code extensibility.

The dialectic isn't too complicated, IMHO, once the case is plainly stated.  Here's the Q/A I'd like to have with the alarmists on this topic-

Question: What is UEFI?

Answer:  UEFI stands for the “Unified Extensible Firmware Interface,” a software interface to the platform for booting operating systems such as Linux and Microsoft Windows. Along with the Advanced Configuration and Power Interface (ACPI), UEFI abstracts away many of the platform hardware details from the operating system.

UEFI software interfaces are codified in the UEFI Specification, which is presently at version 2.3.1c. That specification is owned and evolved by the UEFI Forum, an industry group that includes OS vendors (OSVs), independent hardware vendors (IHVs), independent BIOS vendors (IBVs), original equipment manufacturers (OEMs), and independent software vendors (ISVs).

Question: What is UEFI Secure Boot?

Answer:   UEFI Secure Boot entails a set of technology elements that apply policy for loading UEFI executables, including applications and drivers. These elements include the Platform Key (PK), the Key Exchange Key (KEK), the allowed database (db), and the prohibited database (dbx). To provide access control, these objects are stored in something called an authenticated variable, which is a class of UEFI variable that needs to be cryptographically signed to update the contents. These keys contain policy about who can update things and what code can run.

UEFI is all about loading images, the most important being the OS loader. With UEFI Secure Boot, the UEFI images are signed using Authenticode, or an embedded signature format inside of the PE/COFF executable. Authenticode and PE/COFF are the same cryptographic signature and image encoding used by Microsoft Windows.

Question: What was the world like before UEFI Secure Boot?

Answer: Prior to UEFI Secure Boot, the UEFI firmware would load any well-formed UEFI executable found in an adapter card, the EFI System Partition on the disk, or from across the network. With the addition of UEFI Secure Boot, the UEFI firmware now will assess the UEFI executable to see if it “meets policy.” This policy includes if the image is cryptographically signed used asymmetric cryptography such as public/private keys, whether the signature verifies to another key in the allowed list, and whether it’s on the prohibited list.

In a sense, UEFI Secure Boot is a simple form of managing and enforcing a white list of “good” and “bad” UEFI drivers and applications. This allows the system board vendor or owner and other authorized parties to manage which software publishers can execute content on a platform.

Question: Why is it important to the industry?

Answer: At the highest level, security is an important facet of platform deployment, along with compatibility, usability, performance, power and other capabilities. In the context of UEFI, Secure Boot helps support the general roll-out and mass deployment of UEFI-based technology in the market. A platform owner can leverage UEFI to defend the platform and operating systems from malware and other software attacks.

To see why this is important, recall that the “E” in UEFI stands for “extensibility.” Extensibility acts as a two-edged knife: on the bright edge of extensibility, a UEFI-conforming platform can “just work” with executables that conform to the construction and API rules of the UEFI specification. This allows for shrink-wrap operating system vendors to write one loader (Windows loader, Linux loader), or an IHV one boot driver (NIC, GFX, Storage adapter), or an ISV pre-boot application (diagnostic/provisioning), for a given micro architecture (Itanium, IA32, x64, ARM). 

On the dark edge of the UEFI knife, a permissive load policy of “any UEFI executable” as featured in the UEFI specification circa 2006 might allow bad actors to add and run content on the platform. Since UEFI executables can be introduced via a pluggable PCI card, a possibly hostile network, or from a disk that UEFI cannot protect after booting to an OS, there’s a rich set of attack vectors. This class of attack against the boot process is known in the security community as a “boot kit.” Such kits for both UEFI-based and PC/AT BIOSs exist today. And, as operating systems and hypervisors grow increasingly robust, malware and viruses are moving earlier in the boot and into the platform.   UEFI Secure Boot provides a policy based control for the Extensible code elements within a UEFI pre-OS environment.

Question: Is this locking out the user and a salvo in the “war against computation” http://www.softwarefreedom.org/blog/2012/jan/04/doctorow-ccc-keynote/?

Answer: No.   The UEFI Specification only reads on the mechanism.   End-user controls and choice of operating system, such as enabled via Custom Mode screens to add additional keys, are provided in UEFI-based products.   UEFI Secure Boot is not an ‘attack’ on the compute ecosystem so much as a ‘prevention’ of wounds on the compute ecosystem that the dark side of UEFI’s extensibility may inflict.

For more information on UEFI Secure Boot, see

Chapter 27 of the UEFI 2.3.1c specification www.uefi.org

Magnus Nystrom, Martin Nicholes, Vincent Zimmer, "UEFI Networking and Pre-OS Security," in Intel Technology Journal - UEFI Today:  Boostrapping the Continuum, Volume 15, Issue 1, pp. 80-101, October 2011, ISBN 978-1-934053-43-0, ISSN 1535-864X  

http://www.intel.com/content/www/us/en/research/intel-technology-journal/2011-volume-15-issue-01-intel-technology-journal.html