How to protect the coprocessor firmware

Revision as of 15:58, 31 May 2019 by Registered User (First Draft Intro)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Template:ArticleMainWriter Template:ArticleDraftVersion


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 URL 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 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(TODO cf secure boot). 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

4. Firmware authentication[edit source]

The standard process to load the coprocessor firmware is to use the remoteproc driver <linux_src/drivers/remoteproc/stm32_rproc.c.

In order to authenticate the firmware to be loaded, it must be directly sent to secure OS (or secure monitor). A new SIP service must be developed and called from the remoteproc driver to send the sign firmware to secure os. It must not parse binary and send directly the binary to