1. Article purpose[edit source]
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[edit source]
The Linux OS through the remoteproc framework that 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. Firmware authentication[edit source]
3.1. Load firmware using RemoteProc framework[edit source]
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.
3.2. Secure Protection[edit source]
3.2.1. Key Management[edit source]
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.
3.2.2. Memory Management[edit source]
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.
3.3. Firmware Start[edit source]
As the firmware was loaded and verified, it is up to remoteProc processing to start the firmware in the standard way.
4. Firmware signature[edit source]
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
Arm® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. 