LAN966x Secure Boot

The Trusted Firmware-A (TF-A) SW project is a multi-stage bootloader which utilizes the ARM TrustZone feature in ARM CPUs as an important part of the security concept.

The TrustZone feature in ARM CPUs introduce the concept of a Secure-World (S) and Non-Secure-World (NS) and the ability to switch between these worlds. The various CPU peripherals inside the SoC, or connected to the SoC, are then classified as secure or non-secure. Secure-World has access to everything, while Non-Secure world only has access to the non-secure peripherals.

In HW this is implemented as an additional bit in the address bus to specify the Secure/Non-Secure mode. Only Secure-World bus controllers can issue transactions with the Secure-Bit set.

When zooming in on the CPU, the S/NS worlds are often seen as an additional dimension to the exception levels (EL3 - EL0). This is illustrated below:

The CPU can jump between the secure and non-secure worlds, and the two worlds can communicate with each other by using a shared buffer. This allows the same kind of application and use-cases as when having a dedicated security processor.

The TF-A framework provides a multi-stage bootloader concept. There are many good reasons to go with a multi stage approach. To name a few points:

Here is a list with an explanation of the different boot-loader stages:

The FIP or Firmware Image Package is the file format TF-A uses to contain all the artifacts. This includes the BL2 and BL3x images, certificates, and configuration files.

The FIP is generated as part of the build process. It is written in flash in binary format without any transformation, and the BL1 ROM knows how to locate and load a particular image type in the FIP.

It can be compared to a very simple read-only file-system, as it contains only very basic information of the individual files: type, offset and size.

The TF-A project includes 2 host tools:

The FIP generation process where the fiptool and cert_create are used is shown below:

As shown above, the cert_create tool reads the BLOBs as input, it reads the keys from the disk (or generate them on the fly), and creates the needed certificates. Once the certificates have been generated, the normal fiptool can bundle both the original BLOBs and the associated certificates into the FIP which can then be authenticated. To bind devices to this chain of trust, the SHA or the public root key needs to be written into OTP.

Most modern Linux distributions can be used for building TF-A, but to ensure consistent results a docker image can be used for running all the build-commands.

This project provides a dr (docker run) script to make it easy to run a command in the desired docker container.

The dr script is provided by the https://github.com/microchip-ung/docker-run project which also offers more details on how it works.

The folder /opt/mscc must exist before you can use the dr script. This folder is used for caching BSP packages.

The short story is that prefixing a command with dr will cause it to run in a docker container.

You can test if it works just by typing dr ls and check the result.

Sources can be obtained from https://github.com/microchip-ung/arm-trusted-firmware using git clone.

A release with both source packages and binaries are provided as release artifacts and can be found at https://github.com/microchip-ung/arm-trusted-firmware/releases.

To build the TF-A binaries for LAN966x, navigate to the root of the project and run the following command:

This will by default do incremental builds. The --clean flag will delete the artifacts for a given platform/variant and cause the next build to be complete rebuild.

The build.rb script offers a set of options to tweak the default settings. The --help option shown below provides an overview of possible options, and the following sub-sections provides some additional details.

TF-A uses a hierarchy of certificates to authenticate the different images in the FIP. This hierarchy is shown at the following image:

As shown on the drawing, BL2 is authenticated by TRUSTED_BOOT_FW_CERT. TRUSTED_BOOT_FW_CERT is authenticated by the root of trust (the ROT_PUB_KEY). And the ROT_PUB_KEY is finally authenticated by the OTP SHA provided by the platform.

The key hierarchy limits the usage of the root key, and therefore also the attack surface. If one of the downstream keys is leaked, it is possible to do key revocation.

Besides the certificate based authentication, the authentication framework will also check the version number of the certificates against a non-volatile counter, provided by the platform. The version number in the certificate is covered by the signature which ensures the integrity, and the platform provides non-volatile counters that are created in such way that they can only increment.

The authentication process will first validate the signature and then continue to compare the version of the certificate against the platform counter. Here is how the comparison is performed:

The purpose of this mechanism is to have a way of performing revocation of certificates. If one of the private keys has been revealed, new certificates needs to be issued and provisioned. But the old firmware will still pass the public key authentication, and the only way to prevent an attacker from rolling back the firmware, is to have such a counter.

The ROT (root of trust) key does not have any version numbers as it cannot be updated.

TF-A uses 2 none-volatile counters: trusted_nv_ctr and non_trusted_nv_ctr. The non_trusted_fw_key_cert and non_trusted_fw_content_cert certificates are checked against the non_trusted_nv_ctr, all other (except ROT) are evaluated against trusted_nv_ctr.

To sign a certificate the private key is needed, but to authenticate a certificate only the public key is needed. The cert_create tool needs access to both the public and private keys. The public keys are needed, because they are aggregated into the certificates, and the private keys are needed to do the signing.

The following picture illustrates the entire signing process done by cert_create.

The green boxes are binaries generated by the compiler. cert_create will calculate the SHA, feed the SHA into the certificate, and sign the certificate. The trusted and non-trusted counters is version numbers. These version numbers are given at the command-line, and will be stored in the certificates as well. The trust hierarchy is created by feeding the SHA of 1 public key, into a parent certificate. The 2 certificates: TRUSTED_BOOT_FW_CERT and TRUSTED_KEY_CERT are authenticated by the root-of-trust public certificate.

When BL1 loads the BL2 and the FW_CONFIG images from the FIP, it needs to authenticate the images, and the related certificates to establish a chain of trust. This is shown in the image below:

When BL2 loads the BL32 and BL33 images from the FIP, it needs to authenticate the images, and the related certificates to establish a chain of trust. This is shown in the image below:

Firmware encryption can be used to keep the firmware confidential, and protect against an attacker reading the content of the flash devices and extracting information from that.

When enabled, firmware will be encrypted using AES-128-GCM, which uses symmetric keys.

Two types of firmware keys are supported:

Only the individual images are encrypted, but the FIP container stays unencrypted. This is not a security risk, as the FIP is just a container that does not have any sensitive information.

When images are encrypted an encryption header is prepended to the image. This header contains a flag indicating if the image has been bound or not. (Indicating using ssk or bssk).

Using bssk for firmware encryption instead of ssk have the following advantages:

The disadvantage of using bssk is the additional complications of manufacturing the boards, as it is not possible to do this with pre-programmed images.

Firmware binding can be done from the fwu.html tool or from Linux following the guide here.

See table in LAN966x Strapping Pins

See this section and the following.

The one-time-programmable memory provided by the SoC is an important source of configuration data. It is the only persistent memory not depending on any external components and it is used for many different purposes.

The OTP can be divided into regions, and each region can be write protected, and if write-protected, also read-protected.

Each OTP region contains a number of OTP attributes, which may then contain a number of OTP fields.

This is all covered in the following subsections.

In LAN966x FW_CONFIG is a binary blob, created during firmware compilation.

The format of the blob is as follows:

The image must at-least be at 512 (0x200) bytes. Only the first 512 bytes are used by BL1. The image can be extended at a later point in time, but this will only affect the BL2 usage.

The OTP Emulation portion is covered in details in the OTP Emulation section.

The content of the configuration space is generated based on the content from the scripts/fw_data.yaml file.

To ensure that keys are kept private, and that the execution of BL1, BL2 and BL32 cannot be tampered with these images must be run from secure memory.

LAN966x have 128kb of on-chip SRAM (Secure RAM), and on-the-fly DDR memory encryption.

BL1 executes from ROM directly, but uses the SRAM for static RW data and stack. BL1 will then load BL2 from flash memory into SRAM, and BL2 will then execute from SRAM and also use it for its static RW data and stack.

BL2 will initialize the DDR memory, and setup a secure and a non-secure partition. The secure partition uses on-the-fly DDR encryption, and can only be accessed from the secure world. Once completed the BL2 loads the BL32 from flash memory into the secure DDR memory.

BL32, which is executing from secure DDR memory, will then wipe the contents of the SRAM, and reconfigure the Trust Zone Controller to let all of the SRAM be accessible from the Non-Secure world.

This is important for users of the RTE, as the RTE feature needs access to the SRAM.

LAN966x supports a secure JTAG port which is configured via the SECURE_JTAG OTP attribute. The data-sheet documents the encoding of SECURE_JTAG. Once programmed the JTAG port HW will wake up in one of the following modes:

If one of the secure-modes is enabled, then the JTAG port can be unlocked using a challenge/response. The challenges is a random 32 byte blob generated by the LAN996x device, and the response to unlock is a sha256(challenge-data
OTP_SJTAG_SSK) (where OTP_SJTAG_SSK is the content of the OTP field, and + is a concatenation of the 2 blobs).

The scripts/sjtag-challenge.rb in the TF-A repository can be used to calculate the response to a challenge.

The fwu.html tool can be used to generate the challenge and unlock the JTAG port if the correct response is given.

Unlock from Linux can be done using the instructions here.