XUELK-WP-001: Secure boot on iMX6UL

History

Version	Date	Notes
1.0.0	February 2018	First public release

Introduction

Nowdays, thanks to embedded systems diffusion and explosive growth anyone is aware about security. One of the key factors is to grant that on a specific hardware devices should be executed only authorized SW. This is extremel importan in devices which can be upgraded Over The Air (OTA). As we said before, security on Embedded Device is getting important in the embedded world. In particular, one of the most important targets, discussed in this article is the sw authentication: It is particularly important to guarantee that the embedded processor executes only authenticated software code which which should be originally certified (i.e. u-boot, kernel,..).

In this article, it is described the process applied on DAVE Embedded Systems' devices in order to (1)demonstrate the capability of the authentication mechanisms and (2) give an idea about the effort required for implementing the process on the in-house production. It is important to highlight that this is not just a SW procedure but also a company arrangement design because of security pass through company procedure and good practice. (any alarm system doesn't work properly if you live the keys on the door..).

What described in the following starts from from the HAB Security mechanism provided on iMX6/iMX6UL processor family by NXP. This mechanism permits only that authentic/original software is executed. Than is described how an HAB enabled system, via bootrom properly configuration, guarantees that software loaded from external memroy devices, like NOR, NAND flash memories or SD card, will be executed only if has been authenticated.

References: [1] See for example Secure Boot on i.MX 6 using HABv4.

[2] See starting from pag.19 the follwoing document i.MX High Assurance Boot - Enablement & Tools

[3] See NXP i.MX6UL: i.MX 6UltraLite Processor.

Code Signing theory

The following image shows a generic code signing flow and the different actors involved. As stated above, secure an embedded devices means not only to define a SW update procedure; it requires to define a secure manufacturing procedure where it is important to ensure that security is applied to the information access. In particular an embedded systems is secure if the Super Root Keys are well protected and if the code signing keys are protected. Nowdays, very often, in the manufacturing process, some third parties are involved. This means that secure those keys is fundamental as well as define properly formal agreements with those suppliers in order to define well the responsability and calculate the "security risk".

Code signing participants

In this image it clear the process foo generate keys and certificates. Now these concepts should be applied to the embedded context. In the following it is described how this can be implemented in a real case scenario.

Implementation

The following image shows a simplified block diagram of the implemented solution. Basically this image describes how to apply the generic concepts in a real case scenario. In particular it is clear that any piece of SW should be signed and then authenticated before execution in order to grant security. This process is called Secure Boot and it is the essential tool for making possible the chain of authentication in an embedded device. In detail, Secure Boot is the mechanism used for verify (authenticate) the signature of any piece of SW. In the following sections it is described and listed the implementation procedure for make this possible in a DAVE EMbedded Systems' device called SBC Lynx based on NXP i.MX6 UL platform.

The main steps involved on Secure Boot usage are the following:

• create the Public Keys starting from the Super Root Keys. The Public Keys are then used by the bootrom RSA algorithm to authenticate the binaries to be executed.
• properly configures the iMX6UL eFuse for the bootrom to authenticate the signed binaries versus the Public/Private keys
• signing the binaries images to be validated (u-boot, bootscript, dtb and kernel, ramdisk, etc..)
• create a chain of trust avoiding any external possibility to interrupt the authenticatin process flow (i.e. only if a binary is validated it will be executed)

Is this case the role of the father is to authenticates the children before passing the software control to it.

Chain of trust example

Security process and flow

Going deep in the description, in this section it is described in detail the process with some shots on console log in order to give the precise idea about the entire procedure.

1. download Code Signing Tool (CST) NXP for CSF generation and digital signatures: the tool, once installed on a Linux environment, allows to:
   • create the PKI tree (Public Key Infrastructure): using the hab4_pki_tree.sh from NXP it is possible to create the Public Keys
   • create the SRK table and SRK fuse table: using the srktool from NXP is it possible to generate the value to be programmed on eFuse OTP This process should be kept secret as much as possible. The ability to maintain secret the private keys (Super Root Keys) is the crucial factor which security depends. Once the processor is secured there is no way to load unsecured code. This because of the verification values are stored in eFuse OTP(One Time programming) which cannot be modified once programed. This means also that it is fundamental that the bootloader process is properly tested and prepared before deploying on the field the Secure Boot process.
2. program the eFuse values using the fuse command on u-boot. Once the eFuses are programmed it is not possible to modify them.
3. digital signature of binaries to be loaded
   • CSF (Command Sequence File)
   • u-boot signature using the cst tool from NXP and the CSF configuration file
   • bootscript, kernel and dtb digital signature This process should be kept secret as much as possible. The signature of SW is directly linked to the private key generation so kepting this process secured is fundamental. Hacking a systems should happen at any system level. For this reason any SW layer should be signed. Only with this approach it is possbile to ensure a complete Secure Boot. This principle is calles also chain of trust.
4. chain of trust. In this section it is possible to see how the chain of trust works. Any piece of SW is authenticated before execution. Who is in charge of this check? The piece of code authenticated before... This means that Secure Boot will check with bootrom the u-boot and then any following piece of SW should be designed integrating the authentication check of the next stage. This is the chain of trust principle.
   • the bootrom authenticates u-boot
   • u-boot, using HAB's API (hab_status and hab_auth_img) autenthicates the boot.scr
   • boot.scr, using HAB's API (hab_status and hab_auth_img) autenthicates kernel, dtb e ramdisk

Conclusions

The complete authentication process based on Secure Boot was described in this White Paper. There are many details around how to deploy this process in a manufacturing line. DAVE Embedded Systems' has successfully completed several projects with or without external manufacturing suppliers. In any case it is important to keep in mind:

1. Make the process secure and controlled
2. Chech and verify the code carefully before deplying
3. Authenticate all SW pieces
4. Evaluate carefully the Security level needed. On top of the authentication process there is also the possibility to have encryption mechanisms but not all application should require other security mechanisms expecially because of the high level of impact in the manufacturing process and in the resources required in the embedded systems