Casual Hacking++

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.

This ARM Cortex-A53, 8-core, 2GB DDR3, board is amazing! I'm an entry-level ARM security enthusiast and this board feels like the perfect starting place for TrustZone and a secure/verified boot research.

Hikey supports the ARM Trusted Firmware and OP-TEE reference specifications so we can *clone* from Github, compile, and flash rather effortlessly. We can write the secure 'ROM', secure world operating system, and the non-trusted firmware executing in the normal world.

This next step will detour a bit and provide a walkthrough of UEFI platform code modifications. Pre-built firmware updates for the Minnow, in binary form, can be downloaded on it's firmware page-- as of January 10th 2016 the latest is version 0.84. The 64-bit image does not enable the TPM 2.0, whereas the 32-bit image will. I remember reading a mention in the 0.82 release notes that the 64bit disablement was related to either export controls or a licensing conflict.

Perfect! Let's use this limitation as an opprotunity to build a UEFI firmware volumn to flash onto the Minnow's SPI chip. In our volumn we will use the lastest-supported 64bit TianoCore EDKII code, the (also provided) Minnow FSF package, and enable the TPM 2.0. Unfortunately the Minnow's firmware is not 100% open but the process for slip-streaming the required binary objects is well-documented. One of the Minnow's purposes is to be a development and test platform for the UEFI EDK2 so we should assume as much TianoCore code as possible will be used in our source-built firmware.

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.

This is the first of a collection of posts related to Intel's Minnowboard MAX development board. It begins with a barebones quick start leading to the simplest UEFI-based secure boot and paves the way towards a Secure Root of Trust Measurement (SRTM), where the "root" is the UEFI platform code.

By the end of the article the Minnowboard MAX will boot a Ubuntu 14.04 operating system using a signed shim bootloader, signed GRUB stage 2 bootloader, and signed Linux 3.xx kernel. The UEFI platform code will not be changed, meaning the out-of-the-box firmware will remain (no flashing), and any kernel modules or Linux executables will remain unsigned and unmeasured.

There are quite a few operating/execution environments running below or before an Operating System's kernel. Computer science calls protection domains "Rings" and an Operating system's kernel is called "Ring 0" or "Supervisor mode". Researchers have called the lower-level environments Ring -1 (Hypervisor mode), and Ring -3 ("system management mode"), and they are fairly apt-names. I like to bundle all of these into a scary-but-funny-and-fitting name subzero, dun dun dun!

Intel and the UEFI (Universal Extensible Firmware Interface) forum embody a really awesome subzero concept highlighted in the UEFI acronym-expansion. That is, applying standards to highly-privileged protection domains allows software engineers and vendors to take advantage of each other's development and security improvements. Never-the-less, standards and their implementation-specific variations attract security researches too!!

This post will function as a short walk through for installing and using a TPM on a BeagleBone to implement a Secured Boot (wooo...). I will use an example Secure Boot implementation called libsboot for U-Boot. Let's jump right in with a schematic for the (mostly) required additions to the BeagleBone.

This is an 'easy mode' guide to the NFPC at Defcon 20. Let's begin: starting at packet 253, there is a TCP/LPD session from 10.0.1.4 to 10.0.1.3. A quick scan of the reconstructed session reveals little:

Having never seen LPD traffic, we gave the RFC 1179 a quick read, lucky it's relatively short.

I plan to have a series of posts outlining my curiosity with embedded development and trust. Let's start with poking around where my (our) trust lies when deciding on a SoC for embedded development, using the BeagleBone [SRM] as an example. In this post we'll move trust from CircuitCO's (the Bone manufacture) included bootloaders, Angstrom Linux kernel, and Angstrom development environment to your own compiled bootloaders, kernel, and OS.