Nikolaj’s UEFI SecureBoot tutorial

CodeRush has a new tutorial on UEFI SecureBoot:
Taming UEFI SecureBoot tutorial

[…] let’s talk about how to make a UEFI SecureBoot not work for the benefit of Microsoft, as it is often set at default, and for the good of us. If you’re wondering how to generate their own your own keys for SecureBoot how to install them instead of the standard (or with them), you sign your favorite EFI-boot, how to prevent loading of unsigned or signed other people’s key code, it looks like the interface to configure SecureBoot at AMI, Insyde and Phoenix, […]

It is in Russian, use a translation tool if you can’t read Russian (like me). The article has multiple examples and screenshots of multiple UEFI implementations, and includes some UEFI links at the end that I’ve never seen before, exciting!’s/

Secure Boot for USBArmory

[[  UPDATE: Earlier I called this “UEFI Secure Boot”. Vincent Zimmer of Intel read their blog article more closely than I did, read the comment he just made:  click on the “Comment” link on the left side of the blog, At the moment, I am not sure what flavor(s) of “Secure Boot” InversePath is using for the USB Armory. ]]

InversePath has updated the USB Armory to support Secure Boot (unclear what kind of  “Secure Boot” this is..

Interesting read to see what is involved in getting Secure Boot to work, even if you don’t have one of these devices. I like the disclaimer:

IMPORTANT: enabling Secure Boot functionality on the USB armory SoC, unlike similar features on modern PCs, is an irreversible action that permanenty fuses verification keys hashes on the device. This means that any errors in the process or loss of the signing PKI will result in a bricked device uncapable of executing unsigned code. This is a security feature, not a bug. The activation and use of the Secure Boot functionality is therefore at your own risk and must be approached with care.

Microsoft Windows HSTI (Hardware Security Test Interface)

I just noticed that Microsoft has a “Hardware Security Testability Specification”, still at version 1.0, which defines the Microsoft Windows “Hardware Security Test Interface” (HSTI). The Windows Hardware Certification Program is a self-testing and certification process for Windows OEMs and IHVs. The OEMs/IHVs run some tests, pass them, upload the test log output showing the passing, the vendor gets their code signed and/or they won’t get their marketing logo. Though the test name and the group  name have changed, these tests have been around since the beginning of Windows NT. The tests have grown over time to cover more system components, and certification and logo requirements have gotten more tied to passing test results. As these tests are only useful for Windows-centric IHVs and OEMs, I’ve not paid much attention to what firmware tests are available. These days, there are tests for chip vendors and for IBVs (Independent BIOS Vendors), in addition to OEMs and IHVs. It looks like they have a few UEFI-centric tests regarding Secure Boot, and dealing with system suspend/resume.

Jeremiah Cox of Microsoft gave a talk at the Summer 2013 UEFI Forum plugfest (Summerfest): “Validating Hardware Security Through Firmware Interfaces“, see below for URL to slides.

Excerpts from the MSDN web page:

HSTI helps avoid misconfiguration of security features on devices running Windows. Thus, HSTI provides better assurance of compliance with Windows Hardware Security Requirements. HSTI aims to simplify the interface for designing tests to ensure compliance, reducing the effort required to comply with Windows Hardware Security Requirements. The results of HSTI tests will be consumed by Windows Certification Tests and can be used to verify that devices have been properly configured to enable supported security features. These tests may be used to identify unsecure engineering devices in the field; for example, engineering devices which may contain unsecure test keys. The results of these tests may be used by the Windows operating system to display a watermark (or similar indicator) on unsecured devices. The IHV will develop reference security designs for their platforms that comply with the Windows Compatibility Requirements. In addition, IHVs and IBVs will also implement programmatic tests that verify proper enablement of the reference security implementations and report the results via the Hardware Security Test Interface. These tests are delivered to OEMs & ODMs as compiled modules (not source) and should work without modification. If an OEM/ODM deviates from reference security designs, these test modules may report failures, and the OEM/ODM will need to contact Microsoft to review the modifications and implement an additional HSTI instance that reports these exceptions. OEMs should be able to leverage these security modules with no modification required by following the reference design and documentation. OEMs who wish to add additional security modules, or modify the behavior of any security module, must undergo a design review with Microsoft. Silicon suppliers and IBVs who support Connected Standby systems must implement the platform independent interfaces for querying the respective hardware and firmware security states of their reference platforms. These implementations must be delivered as compiled modules. It is recommended that these modules be signed, and that a signature check is performed when they are run. The purpose is to query the hardware and firmware designs and states to report proper security provisioning of the platform. If an OEM wants to provide an alternate implementation of HSTI tested security features the OEM may provide additional tests. OEM security checks must at least fully cover one IHV or IBV security test. Before use, OEMs must submit to a design review by Microsoft and are subject to the same Documentation and Tool disclosure requirements as other HSTI test providers. Upon approval from Microsoft, the OEM may include security tests that extend upon the IHV and IBV tests. Note that OEM attestation is not required as part of the HSTI design. HSTI is not a list of requirements for OEMs; it is an interface to guarantee effective programmatic security testing of firmware, hardware, and configuration parameters. Silicon and firmware suppliers should make available to Microsoft all necessary security-related reference documentation and tools that they provide to OEMs. This documentation and tools should be made available no later than they are provided to Windows OEMs. This should include, but is not limited to, all documentation and tools related to fusing, installing and updating firmware, firmware and boot recovery, hardware diagnostics, firmware diagnostics, & boot diagnostics. This documentation and tools provided should be fully sufficient to perform HSTI checks in a lab environment.

Beyond Canonical’s FirmWare Test Suite (FWTS) tool for Ubuntu systems, I wonder if Linux Foundation (and FreeBSD Foundation) have anything close to this testing and certification policy for (not just a test), to help encourage silicon vendors, IBVs, IHVs, and OEMs to best (and most securely) work with Linux (and FreeBSD). In addition to passing FWTS, Intel-based systems should also have to pass current CHIPSEC release before Linux or FreeBSD should touch the platform.

This also reminds me of my last blog post, about getting CHIPSEC results more widely available for consumer’s pre-sales knowledge, depending on the strength of these Windows tests, Microsoft may have some OEM/IBV test results that I wish they’d share (but they never would share that kind of data about their Partner, of course).

For the good of all OSes, not just Windows, I wish Microsoft would add CHIPSEC to their test suites, to force OEMs to pass CHIPSEC. I wonder if CHIPSEC works using IronPython when run as an OS-level app on Windows. 🙂

More Information:

Click to access UEFI_Summerfest_2013_-_Microsoft_Hardware_Security_Test_Interface.pdf

Spring Plugfest presentations uploaded

The PDFs of the presentations from last months’ UEFI Forum plugfest have been uploaded to
(scroll about half-way through the page, after the Youtube videos…)

* System Prep Applications – Powerful New Feature in UEFI 2.5 – Kevin Davis (Insyde Software)
* Filling UEFI/FW Gaps in the Cloud – Mallik Bulusu (Microsoft) and Vincent Zimmer (Intel)
* PreBoot Provisioning Solutions with UEFI – Zachary Bobroff (AMI)
* An Overview of ACPICA Userspace Tools – David Box (Intel)
* UEFI Firmware – Securing SMM – Dick Wilkins (Phoenix Technologies)
* Overview of Windows 10 Requirements for TPM, HVCI and SecureBoot – Gabe Stocco, Scott Anderson and Suhas Manangi (Microsoft)
* Porting a PCI Driver to ARM AArch64 Platforms – Olivier Martin (ARM)
* Firmware in the Data Center: Goodbye PXE and IPMI. Welcome HTTP Boot and Redfish! – Samer El-Haj-Mahmoud (Hewlett Packard)
* A Common Platforms Tree – Leif Lindholm (Linaro)

This’ll be a very short blog, as I’m busy reading 9 new PDFs… 🙂 I’ll do blogs on some these specific presentations in the coming days.