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.
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
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
.JPG)
.JPG)
.JPG)
.JPG)
