XUELK-WP-001: Secure boot on iMX6UL

Contents

HistoryEdit

Version	Date	Notes
1.0.0	February 2018	First public release

IntroductionEdit

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 demonstrate the capability of the authentication mechanisms and give an idea about the effort required for implementing the process 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..).

The mechanism to ensure that only authentic/original software is executed can be realised starting from the HAB Security mechanism provided on iMX6/iMX6UL processor family by NXP.

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.

This white paper describes how i.MX6UL-based HAB configuration can be used on DAVE Embedded Systems' products for protecting Customer's products and then running only original authentic software.

[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 theoryEdit

The following image shows a generic code signing flow and the different actors involved:

Code signing participants

ImplementationEdit

The following image shows a simplified block diagram of the implemented solution.

Chain of trust

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

• create the Public Keys 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 Puiblic/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.

Security process and flowEdit

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
2. program the eFuse values using the fuse command on u-boot
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
4. chain of trust
   • 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

At the end, starting form the reset, only authenticated images are executed:.....