Alex blogs and updates UEFITool!

Double entry for Alex: he’s got a new blog post on Intel Boot Guard, plus he’s updated UEFITool!

“[…]Today I released a new build of UEFITool with visual validation of Intel Boot Guard coverage. The code pushed to the github repository. A standalone binary of UEFITool can be downloaded here.[…]”

View story at


Embedi: Bypassing Intel Boot Guard

In recent years, there is an increasing attention to the UEFI BIOS security. As a result, there are more advanced technologies created to protect UEFI BIOS from illegal modifications. One of such technologies is Intel Boot Guard (BG) – a hardware-assisted BIOS integrity verification mechanism available since Haswell microarchitecture (2013). So-called «UEFI rootkits killer» this technology is designed to create a trusted boot chain (where a current boot component cryptographically measures/verifies the integrity of the next one) with Root-of-Trust locked into hardware.[…]

Dell PowerEdge 14G firmware updates

Dell/EMC has a new Tech Note, written by Wei Liu and Seamus Jones, summarizing some of the new firmware security features available in their new server:

Cyber-Resiliency Starts at the Chipset and BIOS

2-page Tech Note covering new BIOS features introduced with PowerEdge 14G servers, offering unique resiliency to malicious intent or user error. The two features highlighted, BIOS Recovery and integration of Intel Boot Guard, respectively, are further demonstration of PowerEdge engineering commitment to ensuring the security and stability of enterprise infrastructures.


coreboot adds Intel BootGuard support to Intel ME Tool

“util/intelmetool: Add bootguard information dump support:
With this implementation it’s possible to detect the state of bootguard in intel based systems.
Currently it’s WIP and in a testphase. Handle it with care!”

Intel Boot Guard

Intel Boot Guard

As defined by Wikipedia: “Intel Boot Guard is a processor feature that prevents the computer from running firmware images not released by the system manufacturer. When turned on, the processors verifies a signature contained in the firmware image before executing it, using the hash of the public half of the signing key, which is fused into the system’s Platform Controller Hub (PCH) by the system manufacturer (not by Intel). Intel Boot Guard is an optional processor feature, meaning that it does not need to be activated during the system manufacturing. As a result, Intel Boot Guard, when activated, makes it impossible for end users to install replacement firmware such as Coreboot.

Boot Guard attempts to protect the system before Secure Boot starts. Boot Guard is a big new player in the security -vs- user-control equation. To conserve words, I’ll just point to a few other blog posts on this topic by others:

Security must be addressed, but the cost might be General Purpose Computing?

I hope Intel — or other chip vendors — can help both audiences, not only enterprise vendors who want to use the OEM’s installation of Windows and never change their systems. The locally-present user should be able to override features like this, and install what they want, at firmware, pre-OS and OS-level software. Some systems may need to be tamper-resistant to local users, but that’s just for enterprise bank employees, not for citizens. Intel: please give us more control over the products we purchase.

book review: Platform Embedded Security Technology Revealed

Book review:
Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded Security and Management Engine
Xiaoyu Ruan (Intel)
APress Open, 2014
ISBN: 978-1-4302-6571-9 and 978-1-4302-6572-6

The book reveals the technical details of Intel’s security and management engine, with the focus on the architecture and design of its firmware infrastructure. For the past several years, the engine has been serving as the base of many security technologies included in Intel platforms. This book talks about the various Intel boot security technologies, focusing on the Intel Management Engine (ME) and how ME interacts with the other Intel security technologies at the hardware, firmware, and OS-levels. Much of the book focuses on boot integrity, process isolation, and various Intel hardware-based protections. The book gives good background on how a chip vendor deals with hardware/firmware hybrid solutions, as well as how recent security researcher’s attacks against Intel have impacted their product designs.

It is from APress Open, not Intel Press. But it does read like an book-length whitepaper by Intel, explaining most of Intel’s hardware/firmware security offerings, with some crypto background on some of the designs. The author, Xiaoyu Ruan, is a security researcher with the Platform Engineering Group at Intel Corporation, and is responsible for designing cryptography infrastructure and security applications for Intel’s security and management engine.

The Management Engine (ME) is sometimes just called a management engine, later is starts to become called the security engine:

“Depending on the end product in which the embedded engine resides, the engine is denominated differently. For the embedded system shipped with computing devices featuring Intel Core family microprocessors, it is called the management engine. For the embedded system shipped with computing devices featuring the Intel Atom system-on-chip (SoC), it is called the security engine. Note that not all Atom platforms use the security engine introduced in this book.”

The list of Intel security technologies and acronyms discussed in this book is extensive:
* Intel Security Security Engine, aka Management Engine (ME)
* Intel Boot Guard
* Intel Trusted Execution Technology (TXT)
* Intel Software Guard Extensions (SGX)
* Intel Identity Protection Technology (IPT)
* Intel Active Management Technology (AMT)
* Intel Virtualization Technology
* Intel Anti-Theft Technology
* Intel management engine BIOS extension (MEBX)
* Host-Embedded Controller Interface (HECI)
* Intel EPID (Enhanced Privacy Identification)
* Intel PAVP (Protected Audio And Video Path)
* Intel Platform Trust Technology (PTT)

The discussion on Boot Guard goes into detail as to how it works with Verified Boot and Measured Boot, including use of TPM on Measured Boot. There is a comparison of these various Intel HW/FW security technologies to ARM’s TrustZone. There is discussion on how some of these security technologies are used for “Rights Protection” (DRM), including Intel Sandy Bridge hardware protection technology for UltraViolet-based video content. The author talks about WS-Management interfaces, as well as pre-WSMAN SOAP-based External Operations Interface (EOI) interfaces to engine. There is discussion of the OS-level drivers used to communicate with ME, including Baseboard Management Controllers (BMC) and Out-of-bound traffic to systems via ME on servers. There is some clarification of ME -vs- AMT -vs- vPro, as well as ME use of TPM (discrete or software-based).

The engine has many features. It includes a secure timer, a protected real-time clock in the engine. It can be used for secure storage:

“A partition of the SPI flash chip is reserved for storing the security and management engine’s nonvolatile data. As the flash size is very limited, the files cannot be too large. Generally speaking, the storage is intended for keys and credentials, such as device private keys, AMT passwords, and so on. It is not designed for storing bulk data such as video frames or network traffic.”

Regarding debugging, production parts have fewer silicon diagnostic abilities, but the ME “offers two ways—debug messaging and special production-signed firmware—to facilitate debugging on production parts.”

The book helps enlighten you as to some of the reasons your firmware is generating network traffic, eg:

“To get the current date/time information, the EPID manager requests a real-time OCSP (Online Certificate Status Protocol) response from a trusted OCSP server, which was endorsed by Intel.”

“As an embedded system, the security and management engine does not have convenient network access. Therefore, the SIGMA protocol is designed such that the platform does not communicate with the OCSP server directly but only connects with the verifier.”

The engine adds new crypto protocols, new PKIs, for cryptographers to enjoy. I’m not sure what code outside the engine uses this yet.

Intel EPID (Enhanced Privacy Identification) was added to the management engine:

“Intel’s chipset series 5 (released in 2008) and newer natively support the EPID platform functionality. A unique private key, in its encrypted form, is burned into security fuses for every chipset part during manufacturing. For this EPID ecosystem, Intel acts as the EPID authority. Using the private key, the security and management engine proves that it is a genuine Intel platform, and hence eligible for premium services that are only available for Intel platforms.

Yet it sounds like there is hardware and knowledge available for attackers to obtain to sidestep some of this technology, and rubberhoses can trump NDAs:

“The implementation of the security and management engine attempts to ensure that the EPID key cannot be revealed from a device without special and expensive equipment and advanced expertise in hacking.”

The engine includes a Dynamic Application Launcher (DAL). One thing that jumped out to me about the ME is that it runs Java code from the hard drive! After spending a lot of time explaining why ME is isolated and secure from third-party code, the author mentions two ME limitations: not enough space on Flash for more ME-based firmware apps, and inability of third parties to use the ME.

“To address these drawbacks to some extent, newer versions of the security and management engine firmware include a module called the Dynamic Application Loader, or DAL for short. As indicated by the name, the DAL allows the engine to dynamically load and execute Java applets at runtime. The applets are not stored on the flash, but on the host’s hard drive. With the DAL, the embedded engine is no longer a closed-door realm. The engine is now open to more flexibility and possibilities to be explored.”

“The DAL is essentially a Java virtual machine that enables the operation of Java applets in the security and management engine’s firmware environment. The Java applets in bytecode implement their designed functionalities that can be executed in the firmware.”

“Depending on product, the IPT may be implemented as an applet for the engine’s DAL feature, or a native firmware module on the engine. If the firmware supports DAL, for example, on most Intel Ultrabook models, then the IPT implementation will be distributed in a Java applet. On certain smartphones and other products where the DAL is not built into the engine’s firmware, the IPT will be a native firmware ingredient that is loaded from the system’s flash chip. The firmware design and functionalities of the IPT component are identical for both variants.”

Interestingly, it sounds like the management engine uses some open source code, but doesn’t mention what code is used, only that the TLS used in AMT is not ported from OpenSSL:

“In the security and management engine’s firmware, only a small fraction originates from open-source domain, and it is only used in modules that do not assume security responsibilities. For example, the TLS implementation in the AMT firmware application is not ported from OpenSSL and hence not affected by OpenSSL’s vulnerabilities such as the Heartbleed. The validation of the engine does not discriminate between open source and closed source. Thorough testing is performed against open-source software used by the engine.

(Tianocore’s UEFI implementation of Secure Boot requires the use of libOpenSSL to implement the crypto. OEMs/IBVs could replace that with another library, and may be doing so, but there’s no docs to clarify this.)

In some ways, I look at Intel platforms a bit differently now. In the beginning, it was simple (and insecure): BIOS loaded MS-DOS, then you had a shell, and you ran an app, with the occasional service (TSR). These days, OSes are much more complex, BIOS was replaced by UEFI, which itself a new OS added to stack. The mangement engine and SMM are two background layers to the stack as well. Before reading this, I really thought of the non-UEFI, non-SMM, non-TPM, non-IPMI background interactions were infrequent. But the management engine looks like a significant new addition to the stack, running it’s own drivers, virtual TPMs, ISV Java code off the hard disk, it sounds like yet-another OS (er, platform) added to the stack. It makes sense if you are Intel, I suppose. But I feel uneasy about how complex HW/FW is becoming… Some of these technologies are going to get in the way of General Purpose Computing, helping some companies make disposable systems where vendors dictate all FW/OS choices, and you cannot install your own OS. On the other hand, security issues need addressing, somehow. Boot system, start SMM, start background ME OS, then start background UEFI OS, then load user’s main OS, …that’s a lot of platforms in one stack.

In summary, I liked this book. Unlike my blog posts, the book was well-written. 🙂 The author knows a LOT about Intel security technologies. I learned a lot. If you care about firmware security on Intel platforms, you should get this book. You might be able to avoid the book if you spend a lot of time researching the various technologies off Intel’s web sites and online, but this book does a great job of integrating all of these technologies into one source. I hope to see a 2nd edition once Intel adds more features to the engine.