Exploring Universal Flash Storage (UFS) Write Protection on the HiKey960

This post explores the potential of a do-it-yourself root of trust on the HiKey960 using UFS hardware write protections. The 960 version has an onboard Universal Flash Storage (UFS) devices, the future of MMC, and much faster! UFS as a standard has existed since 2011, but seems only since 2017 they were generally obtainable. Support in Linux has experienced very-recent updates (4.15+).

The unfortunate news is I have not found a way to implement an open-source/do-it-yourself Root of Trust on the HiKey960. I will explain why during this post, but this post will focus more on UFS write-protection.

Read More

DIY Root of Trust using ARM Trusted Firmware on the 96Boards Hikey

DIY Root of Trust using ARM Trusted Firmware on the 96Boards Hikey

This is a series of notes designed to be a walkthrough on how to configure the HiKey Kirin 620 to boot securely with ARM Trusted Firmware's Trusted Board Boot. This does not use any proprietary settings or vendor-specific details about the SoC. Instead, the secure boot path relies on the SoC's BOOT_SEL configured to boot solely from the eMMC. With this configuration there should be no way to interrupt or bypass the root of trust via runtime changes.

Pay special attention to the should as this is not speaking from authority but rather from suspicion and research.

The Root of Trust (ROT) begins in the BL2 programmed to the eMMC's boot0 partition. The bootrom must execute the HiKey's l-loader.bin and ARM-Trusted-Firmware's (ATF) bl2.bin written to this alternate boot partition. The eMMC's extended CSD register 173 (BOOT_WP) is written to permanent write-protect this content. This is a 1-time program operation that has the potential to brick the device.

Read More

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

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.

Read More

Minnowboard Max: Booting Linux Securely

Minnowboard Max: Booting Linux Securely

Newish desktops, laptops, and other systems, might come with Secure Boot enforcement enabled; those system owners can install Ubuntu and get 'for free' a more-or-less verified boot starting with their UEFI firmware and extended all the way to their kernel. I say 'more-or-less' because there are tons of places where the verification can be subverted. Unfortunately, if you start examining the implementation and configuration details of the streamlined Secure Boot support, you'll find plenty of bypasses.

Let's talk briefly about each bypass and conclude with a simple way to use Secure Boot and enforce a signed kernel execution on Ubuntu. To be clear, there are no vulnerabilities here as there is no documented intention (e.g.,BUG/1401532) to boot Linux securely, only to support a Secure Boot and boot Linux.

Read More