Eric Lee / smarc-uboot

Download as
Browse Code »

Commit c9a3780acc0401eba688fe43ad7cf4e5df4f5c38

Authored by Breno Lima
Committed by Ye Li
1 parent de4e64ce37
Exists in smarc-imx_v2018.03_4.14.78_1.0.0_ga

MLK-20553-1 doc: imx: ahab: Add AHAB introduction 

The AHAB is currently supported in i.MX8QXP and i.MX8QM devices.

Add an introductory document containing the following topics:

- AHAB Secure Boot Architecture
- System Control Unit (SCU) introduction
- Security Controller (SECO) introduction
- i.MX8/8x secure boot flow
- AHAB PKI tree generation
- SRK Table and SRK Hash generation

Signed-off-by: Breno Lima <breno.lima@nxp.com>
Reviewed-by: Frank Zhang <frank.zhang@nxp.com>
Reviewed-by: Marius Grigoras <marius.grigoras@nxp.com>
Reviewed-by: Utkarsh Gupta <utkarsh.gupta@nxp.com>
(cherry picked from commit 6e9ceb2526bd4a45c6ff669afb086cc3a0627e6b)

Showing 1 changed file with 301 additions and 0 deletions Side-by-side Diff

doc/imx/hab/ahab/introduction_ahab.txt
Diff comments   View file @ c9a3780
  1 + +=======================================================+
  2 + + i.MX8/8x AHAB Secure Boot introduction +
  3 + +=======================================================+
  4 +
  5 +1. Introduction
  6 +----------------
  7 +
  8 +The i.MX8 and i.MX8x family of applications processors introduce a new
  9 +secure boot concept. Due to the multi-core architecture the Security
  10 +Controller (SECO) and System Control Unit (SCU) are heavily involved in
  11 +the secure boot process.
  12 +
  13 +Step-by-step guides are available under doc/imx/hab/ahab/guides/ directory,
  14 +users familiar with AHAB architecture and CST PKI tree generation should
  15 +refer to this directory instead.
  16 +
  17 +1.1 The AHAB Secure Boot Architecture
  18 +--------------------------------------
  19 +
  20 +The Advanced High Assurance Boot (AHAB) feature relies in digital signatures to
  21 +prevent unauthorized software execution during the device boot sequence. In
  22 +case a malware takes control of the boot sequence, sensitive data, services and
  23 +network can be impacted.
  24 +
  25 +The AHAB authentication is based on public key cryptography in which image
  26 +data is signed offline using one or more private keys. The resulting signed
  27 +image data is then verified on the i.MX processor using the corresponding
  28 +public keys. The public keys are included in the final binary and the SRK
  29 +Hash is programmed in the SoC fuses for establishing the root of trust.
  30 +
  31 +In i.MX8 and i.MX8x families the SCU is responsible to interface with the boot
  32 +media, managing the process of loading the firmware and software images in
  33 +different partitions of the SoC. The SECO is responsible to authenticate the
  34 +images and authorize the execution of them.
  35 +
  36 +1.1.1 The System Control Unit (SCU)
  37 +------------------------------------
  38 +
  39 +The System Control Unit SCU is a subsystem equipped with a programmable M4
  40 +core, which is responsible to handle the resource allocation, power, clocking,
  41 +IO configuration and muxing.
  42 +
  43 +The SCU is also responsible to interface between the rest of the system. In the
  44 +secure boot flow the SCU interfaces with the Security Controller (SECO),
  45 +requesting the image authentication.
  46 +
  47 +The System Control Unit FW (SCFW) is responsible to control all the
  48 +functionalities of the SCU. This firmware is distributed in a porting kit form.
  49 +Instructions to download the SCFW Porting Kit are available in the Linux BSP
  50 +Release Notes.
  51 +
  52 +Details about SCU can be found in the processors Reference Manual (RM).
  53 +
  54 +1.1.2 The Security Controller (SECO)
  55 +-------------------------------------
  56 +
  57 +The SECO is a M0+ core dedicated to handle the SoC security subsystem. The
  58 +controller communicates with SCU domain through a dedicate message unit (MU).
  59 +
  60 +The SECO has a dedicate ROM which is responsible to initialize low level
  61 +security features and to authenticate the SECO firmware previously loaded by
  62 +the SCU ROM.
  63 +
  64 +The SECO firmware provides security services at run-time to different domains
  65 +of the SoC, one of these being the capability of authenticate images.
  66 +
  67 +The SECO firmware is signed and distributed by NXP and is always authenticated
  68 +in OEM open and closed configuration, instructions to download the SECO FW are
  69 +available in the Linux BSP Release Notes.
  70 +
  71 +Details about SECO can be found in the processors Security Reference Manual
  72 +(SRM).
  73 +
  74 +1.2 The image container
  75 +------------------------
  76 +
  77 +Due to the new the architecture, multiple firmwares and softwares are required
  78 +to boot i.MX8 and i.MX8x family devices. In order to store all the images in a
  79 +single binary the container image structure is used.
  80 +
  81 +At least two containers are needed for the boot process, the first container
  82 +must include only the SECO FW (provided by NXP). Additional containers can
  83 +contain one or multiple images, depending on the users specific application.
  84 +
  85 +The final binary is generated by the imx-mkimage tool. The tool can generate
  86 +additional containers and also combine all containers in a single binary.
  87 +
  88 +1.3 The i.MX8/8x secure boot flow
  89 +----------------------------------
  90 +
  91 +As mentioned in the introduction, due to the multiple cores architecture the
  92 +i.MX8 boot sequence involves SCU ROM, SCFW, SECO ROM, and SECO FW.
  93 +
  94 +The diagram below illustrate the secure boot flow overview:
  95 +
  96 +System Controller │ Security Controller │ Cortex-M │ Cortex-A
  97 + (SCU) │ (SECO) │ │
  98 + │ │ │
  99 + ╔═════════════╗ │ ╔═════════════╗ ┌───────────┐ ┌─────────┐
  100 + ║ SCU INIT ║ │ ║ SECO INIT ║ │ │ │ │ │ │
  101 + ╚══════╤══════╝ │ ╚══════╤══════╝ │ │ v │ │ v
  102 + │ │ │ │ │ ┌──────────┐ │ │ ┌────────────┐
  103 + ╔══════╧══════╗ │ │ │ │ │ Start M4 │ │ │ │ Start AP │
  104 + ║Load SECO FW ║ │ │ │ │ │ IMG │ │ │ │ IMG │
  105 + ╚══════╤══════╝ │ ╔══════╧══════╗ │ │ └──────────┘ │ │ └─────┬──────┘
  106 + ├──────────────>║Auth SECO FW ║ │ │ │ │ │
  107 + ╔══════╧══════╗ │ ╚══════╤══════╝ │ │ ┌────────────┘ │ │
  108 + ║ Load SCU FW ║ │ │ │ │ │ │ │
  109 + ║ and DCD ║ │ │ │ │ │ │ ┌─────┴──────┐
  110 + ╚══════╤══════╝ │ ┌──────┴──────┐ │ │ │ │ │ Load │
  111 + ├──────────────>│ Auth SCU FW │ │ │ │ │ │ Add AP IMG │
  112 + │ │ │ and DCD │ │ │ │ │ └─────┬──────┘
  113 + ╔══════╧══════╗ │ └──────┬──────┘ │ │ │ │ │
  114 + ║ Run DCD ║<──────────────┤ │ │ │ │ │
  115 + ╚══════╤══════╝ │ │ │ │ │ ┌───────────────┤
  116 + │ │ │ │ │ │ │ │ │
  117 + ╔══════╧══════╗ │ │ │ │ │ │ │ │
  118 + ║ Load M4 IMG ║ │ │ │ │ │ │ │ │
  119 + ╚══════╤══════╝ │ ┌──────┴──────┐ │ │ │ │ │ │
  120 + ├──────────────>│ Auth M4 IMG │ │ │ │ │ │ │
  121 + ╔══════╧══════╗ │ └──────┬──────┘ │ │ │ │ │ ┌─────┴──────┐
  122 + ║ Load AP IMG ║ │ │ │ │ │ │ │ │ Run │
  123 + ╚══════╤══════╝ │ ┌──────┴──────┐ │ │ │ │ │ │ Add AP IMG │
  124 + ├──────────────>│ Auth AP IMG │ │ │ │ │ │ └────────────┘
  125 + ╔══════╧══════╗ │ └─────────────┘ │ │ │ │ │
  126 + ║Start SCU FW ║ │ ┌──────────────────┘ │ │ │ │
  127 + ╚══════╤══════╝ │ │ │ │ │ │
  128 + │ │ │ ┌─────────────────────┘ │ │
  129 + ┌──────┴──────┐ │ │ │ │ │ │
  130 + │ Start M4 ├──────┘ │ ┌──────────────────────┘ │
  131 + └──────┬──────┘ │ │ │ │ │
  132 + │ │ │ │ │ │
  133 + ┌──────┴──────┐ │ │ │ │ │
  134 + │ Start AP ├──────────┘ │ │ │
  135 + └─────────────┘ │ │ │ │
  136 + ┌───────────────────────┘ │ │
  137 + │ │ │ │
  138 + v │ │ │
  139 + ┌─────────────┐ │ ┌─────────────┐ │ │
  140 + │Request SECO ├───────>│ Auth AP IMG │ │ │
  141 + └─────────────┘ │ └─────────────┘ │ │
  142 + │ │ │
  143 +
  144 +Notes:
  145 +All boxes enclosed by double dash (═) are performed at SCU/SECO ROM level.
  146 +
  147 +The sequence below explains the i.MX8 and i.MX8x boot flow:
  148 +
  149 +1 - At reset, the SCU ROM and SECO ROM both start execution.
  150 +2 - The SCU ROM reads the boot configuration and loads the SECO FW (First
  151 + container) from the boot media to the SECO TCM.
  152 +3 - A message is sent by the SCU ROM via MU requesting the SECO ROM to
  153 + authenticate the SECO FW which is signed using NXP key.
  154 +4 - The SCU ROM loads the second container from the boot media, this container
  155 + must contain at least the SCFW which is signed using the OEM keys.
  156 +5 - The SCU ROM loads the SCFW to the SCU TCM, a message is sent via MU
  157 + requesting the SECO FW to authenticate the SCFW and DCD table.
  158 +6 - The SCU ROM configures the DDR and loads the M4 and AP images included in
  159 + the second container to their respective load addresses.
  160 +7 - The SCU ROM request the SECO FW to authenticate the M4 image.
  161 +8 - The SCU ROM request the SECO FW to authenticate the AP image. This image
  162 + is the initial AP core software, depending in the U-Boot target it can
  163 + be the U-Boot and ATF or only SPL.
  164 +9 - The SCFW is initialized and starts the ARM Cortex-M and Cortex-A cores.
  165 +10 - From this point additional containers can be loaded by Cortex-M and
  166 + Cortex-A cores and authenticated by SECO, the AP SW must interface with
  167 + SCU by calling the sc_misc_seco_authenticate() API function. In current
  168 + U-Boot implementation the additional image can be the Linux Kernel binary
  169 + or the U-Boot proper and ATF. Details about current U-Boot implementation
  170 + can be found in AHAB guides included in doc/imx/hab/ahab/guides/ directory.
  171 +
  172 +2. Generating a PKI tree
  173 +-------------------------
  174 +
  175 +The first step is to generate the private keys and public keys certificates.
  176 +The AHAB architecture is based on a Public Key Infrastructure (PKI) tree.
  177 +
  178 +The Code Signing Tools package contains an OpenSSL based key generation script
  179 +under keys/ directory. The ahab_pki_tree.sh script generates a PKI tree
  180 +containing 4 Super Root Keys (SRK), possible to also include a subordinate
  181 +SGK key.
  182 +
  183 +The AHAB supports both RSA and ECC keys, a new PKI tree can be generated by
  184 +following the example below:
  185 +
  186 +- Generating a P384 ECC PKI tree on CST v3.1.0:
  187 +
  188 + $ ./ahab_pki_tree.sh
  189 + ...
  190 + Do you want to use an existing CA key (y/n)?: n
  191 + Do you want to use Elliptic Curve Cryptography (y/n)?: y
  192 + Enter length for elliptic curve to be used for PKI tree:
  193 + Possible values p256, p384, p521: p384
  194 + Enter the digest algorithm to use: sha384
  195 + Enter PKI tree duration (years): 5
  196 + Do you want the SRK certificates to have the CA flag set? (y/n)?: n
  197 +
  198 +The diagram below illustrate the PKI tree generated:
  199 +
  200 + ┌─────────┐
  201 + │ CA │
  202 + └────┬────┘
  203 + │
  204 + │
  205 + ┌───────────────┬────────┴────────┬───────────────┐
  206 + │ │ │ │
  207 + │ │ │ │
  208 + v v v v
  209 + ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
  210 + │ SRK1 │ │ SRK2 │ │ SRK3 │ │ SRK4 │
  211 + └────────┘ └────────┘ └────────┘ └────────┘
  212 +
  213 +2.1 Generating a PKI tree including a subordinate SGK key
  214 +----------------------------------------------------------
  215 +
  216 +The ahab_pki_tree.sh script is also able to generate a PKI tree containing a
  217 +subordinate key of the SRK, this key can be used to verify the signature
  218 +included in the final signed image.
  219 +
  220 +Users should set the CA flag when generating the SRK certificates.
  221 +
  222 +- Generating a P384 ECC PKI tree with a subordinate SGK key on CST v3.1.0:
  223 +
  224 + $ ./ahab_pki_tree.sh
  225 + ...
  226 + Do you want to use an existing CA key (y/n)?: n
  227 + Do you want to use Elliptic Curve Cryptography (y/n)?: y
  228 + Enter length for elliptic curve to be used for PKI tree:
  229 + Possible values p256, p384, p521: p384
  230 + Enter the digest algorithm to use: sha384
  231 + Enter PKI tree duration (years): 5
  232 + Do you want the SRK certificates to have the CA flag set? (y/n)?: y
  233 +
  234 +The diagram below illustrate the PKI tree generated:
  235 +
  236 + ┌─────────┐
  237 + │ CA │
  238 + └────┬────┘
  239 + │
  240 + │
  241 + ┌───────────────┬────────┴────────┬───────────────┐
  242 + │ │ │ │
  243 + v v v v
  244 + ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
  245 + │ SRK1 │ │ SRK2 │ │ SRK3 │ │ SRK4 │
  246 + └────┬───┘ └───┬────┘ └────┬───┘ └───┬────┘
  247 + │ │ │ │
  248 + v v v v
  249 + ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
  250 + │ SGK1 │ │ SGK2 │ │ SGK3 │ │ SGK4 │
  251 + └────────┘ └────────┘ └────────┘ └────────┘
  252 +
  253 +Note: Due to a limitation in i.MX8QXP B0 silicon it's not possible to use RSA
  254 +4096-bit SRK keys with an additional subordinate SGK key.
  255 +
  256 +2.2 Generating a SRK Table and SRK Hash
  257 +----------------------------------------
  258 +
  259 +The next step is to generated the SRK Table and its respective SRK Table Hash
  260 +from the SRK public key certificates created in one of the steps above.
  261 +
  262 +In the AHAB architecture, the SRK Table is included in the signed image and the
  263 +SRK Hash is programmed in the SoC SRK_HASH[511:0] fuses.
  264 +
  265 +On the target device during the authentication process the AHAB code verify the
  266 +SRK Table against the SoC SRK_HASH fuses, in case the verification is successful
  267 +the root of trust is established and the AHAB code can progress with the image
  268 +authentication.
  269 +
  270 +The srktool can be used for generating the SRK Table and its respective SRK
  271 +Table Hash.
  272 +
  273 +- Generating SRK Table and SRK Hash in Linux 64-bit machines:
  274 +
  275 + $ cd ../crts/
  276 + $ ../linux64/bin/srktool -a -s sha384 -t SRK_1_2_3_4_table.bin \
  277 + -e SRK_1_2_3_4_fuse.bin -f 1 -c \
  278 + SRK1_sha384_secp384r1_v3_usr_crt.pem,\
  279 + SRK2_sha384_secp384r1_v3_usr_crt.pem,\
  280 + SRK3_sha384_secp384r1_v3_usr_crt.pem,\
  281 + SRK4_sha384_secp384r1_v3_usr_crt.pem
  282 +
  283 +- Optionally users can check if the sha512sum of SRK_1_2_3_4_table matches with
  284 + the SRK_1_2_3_4_fuse.bin:
  285 +
  286 + $ od -t x4 --endian=big SRK_1_2_3_4_fuse.bin
  287 + 0000000 01b04697 0253376b 2066fe56 aaef9a91
  288 + 0000020 e62e09d8 14fb7e36 d5b38d05 0982edab
  289 + 0000040 7ada6576 2f6b4f59 1fd9347e 46e7305d
  290 + 0000060 46e34bf0 89780bd1 c809e714 a17e2f4e
  291 +
  292 + $ sha512sum SRK_1_2_3_4_table.bin
  293 + 01b046970253376b2066fe56aaef9a91\
  294 + e62e09d814fb7e36d5b38d050982edab\
  295 + 7ada65762f6b4f591fd9347e46e7305d\
  296 + 46e34bf089780bd1c809e714a17e2f4e\
  297 + SRK_1_2_3_4_table.bin
  298 +
  299 +The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further
  300 +steps as explained in AHAB guides available under doc/imx/hab/ahab/guides/
  301 +directory.