View source for XUELK-WP-001: Secure boot on iMX6UL

== 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.
*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
<pre class="board-terminal">
dvdk@vagrant-ubuntu-trusty-64:~/lynx/hab/cst-2.3.3/keys$ ./hab4_pki_tree.sh

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    This script is a part of the Code signing tools for Freescale's
    High Assurance Boot.  It generates a basic PKI tree.  The PKI
    tree consists of one or more Super Root Keys (SRK), with each
    SRK having two subordinate keys: 
        + a Command Sequence File (CSF) key 
        + Image key. 
    Additional keys can be added to the PKI tree but a separate 
    script is available for this.  This this script assumes openssl
    is installed on your system and is included in your search 
    path.  Finally, the private keys generated are password 
    protectedwith the password provided by the file key_pass.txt.
    The format of the file is the password repeated twice:
        my_password
        my_password
    All private keys in the PKI tree are in PKCS #8 format will be
    protected by the same password.

    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Do you want to use an existing CA key (y/n)?: n
Do you want to use Elliptic Curve Cryptography (y/n)?: n
Enter key length in bits for PKI tree: 3072
Enter PKI tree duration (years): 10
How many Super Root Keys should be generated? 4
Do you want the SRK certificates to have the CA flag set? (y/n)?: y

+++++++++++++++++++++++++++++++++++++
+ Generating CA key and certificate +
+++++++++++++++++++++++++++++++++++++

Generating a 3072 bit RSA private key
.........++
........................................................................................++
writing new private key to 'temp_ca.pem'
-----

++++++++++++++++++++++++++++++++++++++++
+ Generating SRK key and certificate 1 +
++++++++++++++++++++++++++++++++++++++++

Generating RSA private key, 3072 bit long modulus
..............................++
..................................++

...
...
...

++++++++++++++++++++++++++++++++++++++++
+ Generating IMG key and certificate 4 +
++++++++++++++++++++++++++++++++++++++++

Generating RSA private key, 3072 bit long modulus
................................................................................................................................................++
.....................++
e is 65537 (0x10001)
Using configuration from ../ca/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'IMG4_1_sha256_3072_65537_v3_usr'
Certificate is to be certified until Jan  9 16:35:07 2028 GMT (3650 days)

Write out database with 1 new entries
Data Base Updated
dvdk@vagrant-ubuntu-trusty-64:~/lynx/hab/cst-2.3.3/keys$ 
</pre>
* 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 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.
*program the eFuse values using the ''fuse'' command on u-boot. Once the eFuses are programmed it is not possible to modify them. 
<pre class="board-terminal">
=> fuse prog -y 3 0 0x56D3468C
Programming bank 3 word 0x00000000 to 0x56d3468c...
=> fuse prog -y 3 1 0x2313CE16
Programming bank 3 word 0x00000001 to 0x2313ce16...
=> fuse prog -y 3 2 0xF374DA2D
Programming bank 3 word 0x00000002 to 0xf374da2d...
=> fuse prog -y 3 3 0xB0843A55
Programming bank 3 word 0x00000003 to 0xb0843a55...
=> fuse prog -y 3 4 0x74F39B9
Programming bank 3 word 0x00000004 to 0x074f39b9...
=> fuse prog -y 3 5 0xEF12FBA6
Programming bank 3 word 0x00000005 to 0xef12fba6...
=> fuse prog -y 3 6 0x2555E044
Programming bank 3 word 0x00000006 to 0x2555e044...
=> fuse prog -y 3 7 0x242C46B8
Programming bank 3 word 0x00000007 to 0x242c46b8...
</pre>
*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 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.
*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 <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

=== Examples of authentication process on u-boot ===
* u-boot not signed with status ''open'' 
<pre class="board-terminal">
U-Boot 2016.03-xuelk-2.0.0-hab-00002-g3a4f591 (Jan 11 2018 - 17:18:25 +0100)

CPU:   Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 44C
Reset cause: POR
Environment: MMC
I2C:   ready
DRAM:  512 MiB
Relocating to 9ff20000, new gd at 9ef1deb8, sp at 9ef1de90
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
NAND:  2048 MiB
MMC:   FSL_SDHC: 0
In:    serial
Out:   serial
Err:   serial
switch to partitions #0, OK
mmc0 is current device
SOM ConfigID#: 00000013
SOM UniqueID#: ea9c2afe:3b0899d4
CB ConfigID#: 0000002f
CB UniqueID#: 00000000:00000000
Board: MX6UL SBC Lynx
Net:   FEC0
Normal Boot
Hit any key to stop autoboot:  0
=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
        0xdb 0x00 0x14 0x42 0x33 0x28 0x33 0x00
        0x00 0x00 0x00 0x0f 0x87 0x7f 0xbb 0xd4
        0x00 0x09 0x00 0x00

STS = HAB_FAILURE (0x33)
RSN = HAB_INV_CALL (0x28)
CTX = HAB_CTX_TARGET (0x33)
ENG = HAB_ENG_ANY (0x00)

...
...
</pre>

* u-boot signed with ''valid'' signature
<pre class="board-terminal">
U-Boot 2016.03-xuelk-2.0.0-hab-00002-g3a4f591 (Jan 11 2018 - 18:30:36 +0100)

CPU:   Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 45C
Reset cause: POR
Environment: MMC
I2C:   ready
DRAM:  512 MiB
Relocating to 9ff20000, new gd at 9ef1deb8, sp at 9ef1de90
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
NAND:  2048 MiB
MMC:   FSL_SDHC: 0
In:    serial
Out:   serial
Err:   serial
switch to partitions #0, OK
mmc0 is current device
SOM ConfigID#: 00000013
SOM UniqueID#: ea9c2afe:3b0899d4
CB ConfigID#: 0000002f
CB UniqueID#: 00000000:00000000
Board: MX6UL SBC Lynx
Net:   FEC0
Normal Boot
Hit any key to stop autoboot:  0
=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

=>
</pre>

* bootscript, kernel and dtb with ''valid'' signature
<pre class="board-terminal">
U-Boot 2016.03-xuelk-2.0.0-hab-00002-g3a4f591 (Jan 11 2018 - 18:30:36 +0100)

CPU:   Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 45C
Reset cause: POR
Environment: MMC
I2C:   ready
DRAM:  512 MiB
Relocating to 9ff20000, new gd at 9ef1deb8, sp at 9ef1de90
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
NAND:  2048 MiB
MMC:   FSL_SDHC: 0
In:    serial
Out:   serial
Err:   serial
switch to partitions #0, OK
mmc0 is current device
SOM ConfigID#: 00000013
SOM UniqueID#: ea9c2afe:3b0899d4
CB ConfigID#: 0000002f
CB UniqueID#: 00000000:00000000
Board: MX6UL SBC Lynx
Net:   FEC0
Normal Boot
Hit any key to stop autoboot:  0
reading boot.scr
20512 bytes read in 19 ms (1 MiB/s)

Authenticate image from DDR location 0x80700000...

Secure boot enabled

HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

bootscript AUTHENTICATED
## Executing script at 80700000
reading xuelk-2.0.1-signed_uImage
7106592 bytes read in 323 ms (21 MiB/s)

Authenticate image from DDR location 0x80800000...

Secure boot enabled

HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

kernel AUTHENTICATED
reading xuelk-2.0.1-signed_imx6ul-lynx-som0013-cb002f.dtb
53280 bytes read in 24 ms (2.1 MiB/s)

Authenticate image from DDR location 0x83000000...

Secure boot enabled

HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

fdt AUTHENTICATED

Authenticate image from DDR location 0x80800000...

Secure boot enabled

HAB Configuration: 0xf0, HAB State: 0x66
No HAB Events Found!

## Booting kernel from Legacy Image at 80800000 ...
   Image Name:   Linux-4.1.15-xuelk-2.0.1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    7090064 Bytes = 6.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 83000000
   Booting using the fdt blob at 0x83000000
   Loading Kernel Image ... OK
   Using Device Tree in place at 83000000, end 8300b21d
Modify /soc/aips-bus@02000000/bee@02044000:status disabled
ft_system_setup for mx6

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.1.15-xuelk-2.0.1 (jenkins@linuxserver2) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Tue Oct 3 16:18:51 CEST 2017
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Freescale i.MX6 UltraLite LYNX Board
[    0.000000] cma: Reserved 64 MiB at 0x9c000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] PERCPU: Embedded 12 pages/cpu @9bbb2000 s17420 r8192 d23540 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
[    0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait rw ip=192.168.0.99:192.168.0.23::255.255.255.0:xelk:eth0:off panic=1 console=ttymxc0,115200 vmalloc=400M 
...
...
</pre>

=== HAB Warnings ===
Not everything that is notified by <code>hab_status</code> command as <code>HAB Event</code> is a critical error (in other words: invalid signature)

On some cases (in our experience depending on silicon revision, part to part differences and bootloader software releases) there might be some HAB events that are just warning, e.g. the following is a warning on an issue RNG initialization (please note the difference in <code>STS</code> field, from <code>HAB_FAILURE</code> to <code>HAB_WARNING</code>)<syntaxhighlight lang="text">
=> hab_status

Secure boot disabled

HAB Configuration: 0xf0, HAB State: 0x66

--------- HAB Event 1 -----------------
event data:
        0xdb 0x00 0x24 0x42 0x69 0x30 0xe1 0x1d
        0x00 0x08 0x00 0x02 0x40 0x00 0x36 0x06
        0x55 0x55 0x00 0x03 0x00 0x00 0x00 0x00
        0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
        0x00 0x00 0x00 0x01

STS = HAB_WARNING (0x69)
RSN = HAB_ENG_FAIL (0x30)
CTX = HAB_CTX_ENTRY (0xE1)
ENG = HAB_ENG_CAAM (0x1D)

</syntaxhighlight>

Warnings like this don't  prevent booting even if secure boot is enabled