XUELK-WP-001: Secure boot on iMX6UL

From DAVE Developer's Wiki
Revision as of 12:38, 30 January 2018 by U0007 (talk | contribs) (Created page with "Category:Software __FORCETOC__ == History == {| class="wikitable" border="1" !Version !Date !Notes |- |1.0.0 |January 2018 |First public release |} ==Introduction== Secur...")

(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

History[edit | edit source]

Version Date Notes
1.0.0 January 2018 First public release

Introduction[edit | edit source]

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 only 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 Secure Boot on i.MX 6 using HABv4.

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

Implementation[edit | edit source]

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 flow[edit | edit source]

  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:.....