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 Inline Diff

doc/imx/hab/ahab/introduction_ahab.txt
Diff comments   View file @ c9a3780
File was created 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.
302