Teddy Reed: Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4

Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4
February 10, 2018

This document is a linear review of my notes taken while exploring the Sabre Lite single-board-computer. It is a mildly expensive ($200 from Boundary Devices) SBC but it has a well documented secure boot implementation rooted in silicon ROM. It is a very good example of a vendor proprietary firmware verification mechanism. The goal of this article is purely an overview of notes, nothing here is novel or groundbreaking and it is not intended to be a tutorial.[…]


The i/MX image header, where Image Data can be U-Boot, followed by an optional CSF.


more from Duo on Apple EFI security

Nice, in addition to an upcoming new EFI tool, it appears Duo has some defensive advise, using OSQuery, Puppet, and Chef. Click on the first tweet below for an image from their upcoming presentation.


Note that Teddy Reed is giving a presentation on OSQuery in November at Usenix LISA:

Pepjin’s Apple EFI version spreadsheet:



Team Security on UEFI malware

Team Security has an article on firmware malware, focusing on UEFI-centric malware, with many references to VirusTotal.com-based images.

[…]”We would like to specially thank Teddy Reed, developer of the UEFI firmware python parser, he has been instrumental in helping us overcome our ignorance about BIOS, UEFI, and its ecosystem.”



Teddy Reed’s intro to ARM-TF, OP-TEE, and ARM UEFI

“This is a walkthrough for flashing custom ARM Trusted Firmware, OP-TEE, and the ARM UEFI Platform code on the Hikey board. Custom means code we’ve built it on our development machine, we’re not making any changes to these reference implementations just yet.[…]



Teddy Reed on firmware attacks TONIGHT

Short notice, but if you are reading this immediately and are in Bay Area, then you might be able to attend. The rest of us will have to hope they videotape this and share the archive.

Defending, detecting, and responding to hardware and firmware attacks

This presentation takes a different approach to hardware and firmware security by exploring how our enterprise defenders can recognize vulnerable systems and potential compromise. Defense begins with visibility, that means baselining kernel drivers, kernels, boot loaders, ACPI table content, SMBIOS metadata; it then continues into logging real time OS API-generated hardware events. This data and pipeline can fuel existing correlation and IoC collections to identify known good and eventually known bad. Creating production deployable and repeatable recipes for these somewhat esoteric features is essential. We will present a summary of immediate tools and actions for “deep systems defense”, an analysis of where our defenders remain blind to compromise, and recommendations on where our industry can focus tailored effort to generate massive impact.

Teddy is a Security Engineer at Facebook developing production security tools. He is very passionate about trustworthy, safe, and secure code development. He loves open source and collaborative engineering when scale, resiliency, and performance enable defensive and protective software design.



U-Boot Verified Boot to get security improvements

Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.

I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.

P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.

Full post/thread: