Tock as a Hardware Root of Trust (HWRoT) Operating Sytsem

This module and submodules will walk you through setting up Tock as an operating system capable of providing the software backbone of a hardware root of trust, placing emphasis on why Tock is well-suited for this role.

Background

A hardware root of trust (HWRoT) is a security-hardened device that provides the foundation of trust for another computing system. Systems such as mobile phones, servers, and industrial control systems run code and access data that needs to be trusted, and if compromised, could have severe negative impacts. HWRoTs serve to ensure the trustworthiness of the code and data their system uses to prevent these outcomes.

HWRoTs can come in two flavors: discrete and integrated.

• Discrete: a discrete HWRoT is an individually-packaged system on chip (SoC), and communicates over one or more external buses to provide functionality.

• Integrated: an integrated HWRoT is integrated into a SoC, and communicates over one or more internal buses to provide functionality to the rest of the SoC it resides in.

Some notable examples of HWRoTs include:

• The general-purpose, open-source OpenTitan HWRoT which comes in the discrete Earl Grey design as well as the Darjeeling integrated design
• Apple's Secure Enclave, the integrated root of trust in iPhone mobile processors
• Google's Titan Security Module, the discrete root of trust in Google Pixel phones
• Hewlett Packard Enterprise's Silicon Root of Trust, the integrated root of trust in their out-of-band management chip
• Microsoft's Pluton Security Processor, the integrated root of trust integrated into many of its silicon collaborators' processors (Intel, AMD, etc.)
• Arm's TrustZone, the general-purpose integrated HWRoT provided in some Cortex-M and Cortex-A processors
• Infineon's SLE78 Secure Element, which is used in YubiKey 5 series USB security keys

In practice, hardware roots of trust are essential for providing support for all kinds of operations, including:

• Application-level cryptography: While any processor can be used to perform cryptographic operations, doing so on a non-hardened processor (i.e. one that can't prevent physical attacks) can result in side-channel leaks or vulnerability to fault injection attacks, allowing attackers to uncover secrets by measuring execution time or power consumption of the chip, or by triggering incorrect execution paths, respectively. HWRoTs are specifically designed to prevent such issues.

• Key management: Similarly, cryptographic keys stored in memory can be leaked using invasive attacks on a chip--a secure element can instead store the keys and use them without them ever being copied to memory. Smaller HWRoTs focused on providing hardware cryptographic operations and secure key storage are often called secure elements.

• Secure boot: In many systems, it is critical to ensure that code the processor runs hasn't been tampered with by an attacker. Secure boot allows for this by having multiple boot stages, where each stage verifies a digital signature on the next to verify integrity. The bottom-most boot stage is immutable (usually a ROM image baked into the chip design itself). In security-critical systems, the first boot stage is the HWRoT's ROM, which then boots the rest of the RoT, and finally the main processor of the system.

• Hardware attestation: Often with internet-connected devices, it's important for a server to be able to verify that it's connected to a valid, uncompromised device before transferring data back-and-forth. During boot, each boot stage of a device with a HWRoT can generate and sign certificates attesting to the hash of the next boot stage's value. Each of these certificates establishes a conditional trust, demonstrating that a given stage is uncompromised, provided that all previous stages are also uncompromised. Together, these certificates form a trust ladder the server can review, verifying that the expected hash values were reported all the way back to the HWRoT ROM.

• Device firmware updates (DFU): Device firmware updates can be a major threat vector to a device, as a vulnerability in the target device's ability to verify authenticity of an update can allow for an attacker to achieve remote code execution. By delegating device firmware updates to a HWRoT, which can verify the signature and update flash in a tamper-free way on its own, the process of DFU can be made significantly less risky.

• Drive encryption: Similarly, drive encryption can be performed using a HWRoT to avoid attackers tampering with the drive encryption process and compromising the confidentiality of user data.

Hardware Notes

For accessibility, we will use a standard microcontroller in this demo rather than an actual hardware root of trust; that said, the principles in this demo apply readily to any HWRoT.

This guide was designed for the nRF52840dk with an attached screen. However, other hardware will work but will need some additional configuration to match the directions presented here.

Goal

Our goal is to build a simple encryption service, which we'll mount several attacks against, and demonstrate how Tock protects against them.

Along the way, we'll also cover foundational Tock concepts to give a top-level view of the OS as a whole.

nRF52840dk Hardware Setup

Before beginning, check the following configurations on your nRF52840dk board.

1. The Power switch on the top left should be set to On.
2. The nRF power source switch in the top middle of the board should be set to VDD.
3. The nRF ONLY | DEFAULT switch on the bottom right should be set to DEFAULT.

You should plug one USB cable into the top of the board for both programming and communication, into the port labeled MCU USB on the short side of the board.

Kernel Setup

This tutorial requires a Tock kernel configured with two specific capsules instantiated that may not be included by default with a particular kernel:

1. Screen
2. Encryption Oracle

The easiest way to get a kernel image with these installed is to use the Hardware Root of Trust tutorial configuration for the nRF52840dk.

cd tock/boards/tutorials/nrf52840dk-root-of-trust-tutorial
make install

However, you can also follow the guides to setup these capsules yourself in a different kernel setup or for a different board.

Organization and Getting Oriented to Tock

To get started, we briefly describe the general structure of Tock and will deep-dive into these components throughout the tutorial:

A Tock system contains primarily two components:

1. The Tock kernel, which runs as the operating system on the board. This is compiled from the Tock repository.
2. Userspace applications, which run as processes and are compiled and loaded separately from the kernel.

The Tock kernel is compiled specifically for a particular hardware device, termed a board. Tock provides a set of reference board files under /boards/<board name>. Any time you need to compile the kernel or edit the board file, you will go to that folder. You also install the kernel on the hardware board from that directory.

While the Tock kernel is written entirely in Rust, it supports userspace applications written in multiple languages. In particular, the Tock community maintains two userspace libraries for application development in C and Rust respectively:

• libtock-c for C applications ( tock/libtock-c )
• libtock-rs for Rust applications ( tock/libtock-rs )

We will use libtock-c in this tutorial. Its example applications are located in the /examples directory of the libtock-c repository.

Stages

This module is broken into three stages:

1. Creating a simple encryption service
2. Preventing attacks at runtime with the MPU
3. Preventing attacks at compile-time with Tock's isolation guarantees