Changes

Jump to: navigation, search

XUELK-WP-001: Secure boot on iMX6UL

3,422 bytes added, 12:38, 30 January 2018
Created page with "Category:Software __FORCETOC__ == History == {| class="wikitable" border="1" !Version !Date !Notes |- |1.0.0 |January 2018 |First public release |} ==Introduction== Secur..."
[[Category:Software]]
__FORCETOC__
== History ==
{| class="wikitable" border="1"
!Version
!Date
!Notes
|-
|1.0.0
|January 2018
|First public release
|}

==Introduction==
Security on Embedded Device is getting important in the embedded world for executing authentic code on embedded processors. It is particularly important to guarantee that the embedded processor starts <b>only</b> software code which is the original certified software just starting from the beginning (i.e. u-boot).

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's products for protecting Customer's products and then running only original authentic software.


[1] See for example [https://www.nxp.com/docs/en/application-note/AN4581.pdf Secure Boot on i.MX 6 using HABv4].

[2] See ''[https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-6-processors/i.mx-6ultralite-processor-low-power-secure-arm-cortex-a7-core:i.MX6UL NXP i.MX6UL: i.MX 6UltraLite Processor]''.

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


[[File:Chain-of-trust.png|thumb|center|600px|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 <b>chain of trust</b> 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 flow ==
#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 <code>hab4_pki_tree.sh</code> from NXP it is possible to create the Public Keys
#* create the SRK table and SRK fuse table: using the <code>srktool</code> from NXP is it possible to generate the value to be programmed on eFuse OTP
#program the eFuse values using the ''fuse'' command on u-boot
#digital signature of binaries to be loaded
#*CSF (Command Sequence File)
#*u-boot signature using the <code>cst</code> tool from NXP and the ''CSF'' configuration file
#*bootscript, kernel and dtb digital signature
#chain of trust
#*the bootrom <b>authenticates</b> u-boot
#*u-boot, using HAB's API (<code>hab_status</code> and <code>hab_auth_img</code>) <b>autenthicates</b> the boot.scr
#*boot.scr, using HAB's API (<code>hab_status</code> and <code>hab_auth_img</code>) <b>autenthicates</b> kernel, dtb e ramdisk

At the end, starting form the ''reset'', <b>only</b> authenticated images are executed:.....
8,186
edits

Navigation menu