How to protect the coprocessor firmware

1. Article purpose

This article explains how to protect the software loaded by main processor in the coprocessor. It will ensure integrity of the loaded firmware.

2. Introduction

The Linux OS through the remoteproc framework allows to load firmware and control remote processors. Thanks to Arm@ Trustzone and resource isolation, it is possible to authenticate a firmware before loading it. It is required to ensure integrity of the running firmware. It could be required for a complete secure platform.

3. Principle

The protection of the coprocessor firmware is relying on the signature of the firmware using hash computation and encryption key.

• The firmware is signed using a OP-TEE signature script
• The Firmware is read from the file system by the remoteproc framework and the image is sent to the Arm@ Trustzone.
• The firmware is authenticated and managed by OP-TEE in the Arm@ Trustzone.

Error creating thumbnail: Unable to save thumbnail to destination

3.1. Firmware signature

A basic strategy to sign a firmware consists in adding an header that will contains the signature required for authentication. The signature is generated by computing a hash of the binary with the header and to encrypt this hash using a key.
On the STM32MP1, the signature and authentication procedure has be optimized to minimize the memory and accelerate the authentication process. The principe is to compute the hash of the segments to load instead of computing the hash of the full image.

The signature consists in:

1. Parse the program table in the ELF file to identify the segments to Load
2. Compute the hash of each segment and save them in the hash table chunk of the header
3. Compute the hash of the header and sign the hash with the private key

3.2. Authentication

The Authentication is executed in the secure context by an OP-TEE trusted application.

1. The Header is copied in a secure memory to prevent hacking
2. The Header is verified using the signature and the public key embedded in OP-TEE
3. The Elf segment are loaded in the MCU RAMs (assigned to secure context). Upon segment load, a hash is computed and compared to the hash provided in the header hash table.
4. The execution RAM are isolated for the Cortex-M4 usage.

4. Firmware authentication

4.1. Load firmware using RemoteProc framework

The OpenSTLinux process to load the coprocessor firmware is to use the remoteproc framework.

The current framework authentication doesn't support other than elf binary load. In case of authentication firmware management, using remoteproc framework, some rework is needed. No defined support are available to manage information needed for authentication, it could be proprietary header (such as STM32 header).

In this usage, firmware must be sent directly to secure OS in a shared memory area to be authenticated and loaded. In case of STM32 header, the firmware is signed as a signle binary, so it could not be splitted before authentication. A new SIP service must be developed and called from the remoteproc driver to send the sign firmware to secure os.

Once authentication is confirmed, the secure OS will charge the binary in the correct SRAM (depending the elf section). A Elf parser is needed to properly parse section and load firmware at the correct offset.

Once done, resource table address must be return to remoteproc framework to allow rpmsg transactions.

4.2. Secure Protection

4.2.1. Key Management

In the same way as Secure boot authentication, the firmware authentication will use the same API (using bootrom services) but can use a different key to authenticate. The key hash must be store in OTP to be checked in secure OS.

4.2.2. Memory Management

MCU SRAM can be dedicated to MCU usage (isolated). It must not be done at boot time to allow secure OS to write in MCU RAM.

The shared memory have to be locked using the TZC400 mechanism to avoid any change into the secure FW during authentication processing.

Once authentication is completed, firmware can be parsed (ELF parsing) by secure OS and could be copied into MCU SRAM.

Final processing is to dedicate MCU SRAM for MCU only by using ETZPC API. The secure OS can return the resource table address to the remoteproc framework.

4.3. Firmware Start

As the firmware was loaded and verified, it is up to remoteProc processing to start the firmware in the standard way.

5. Firmware signature

The coprocessor firmware can be signed in the same way as the bootloader using Signing Tool. It will add a complete header that will contains the public key and the signature required for authentication. Using this tool is compliant with the authentication processing that is already done for bootloader authentication. This authentication is ECDSA based.

./STM32AP_SigningTool_CLI -bin /home/User/Folder1/BinaryFile.bin –pubk /home/user/publicKey.pem –prvk /home/user/privateKey.pem –iv 0 –pwd azerty –s –la 0x20000000 –ep 0x08000000 –a 2 –o /home/user/Folder2/Folder3/signedFile.bin -type copro

Linux^® is a registered trademark of Linus Torvalds.

Operating system

Arm^® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

Open portable trusted execution environment

Executable and linkable file

Microcontroller unit (MCUs have internal flash memory and are intended to operate with a minimum amount of external support ICs. They commonly are a self-contained, system-on-chip (SoC) designs.)

Random access memory (Early computer memories generally hadserial access. Memories where any given address can be accessed when desired were then called "random access" to distinguish them from the memories where contents can only be accessed in a fixed order. The term is used today for volatile random-acces ssemiconductor memories.)

Cortex^®

Application programming interface

One time programmed

Extended trustzone protection controller

Elliptic curve digital signature algorithm