1 +=======================================================+
2 + i.MX Secure and Encrypted Boot using HABv4 +
3 +=======================================================+
8 The i.MX family of applications processors provides the High Assurance Boot
9 (HAB) feature in the on-chip ROM. The ROM is responsible for loading the
10 initial program image (U-Boot) from the boot media and HAB enables the ROM
11 to authenticate and/or decrypt the program image by using cryptography
14 This feature is supported in i.MX 50, i.MX 53, i.MX 6, i.MX 7 series and
15 i.MX 8M, i.MX 8MM devices.
17 Step-by-step guides are available under doc/imx/habv4/guides/ directory,
18 users familiar with HAB and CST PKI tree generation should refer to these
21 1.1 The HABv4 Secure Boot Architecture
22 ---------------------------------------
24 The HABv4 secure boot feature uses digital signatures to prevent unauthorized
25 software execution during the device boot sequence. In case a malware takes
26 control of the boot sequence, sensitive data, services and network can be
29 The HAB authentication is based on public key cryptography using the RSA
30 algorithm in which image data is signed offline using a series of private
31 keys. The resulting signed image data is then verified on the i.MX processor
32 using the corresponding public keys. The public keys are included in the CSF
33 binary and the SRK Hash is programmed in the SoC fuses for establishing the
36 The diagram below illustrate the secure boot process overview:
38 Host PC + CST i.MX + HAB
39 +----------+ +----------+
40 ---> | U-Boot | | Compare |
41 | +----------+ +----------+
43 | v Reference / \ Generated
44 | +----------+ Hash / \ Hash
45 | | Hash | Private / \
46 | +----------+ Key / \
47 | | | +----------+ +----------+
48 | v | | Verify | | Hash |
49 | +----------+ | +----------+ +----------+
50 | | Sign | <--- SRK ^ ^
51 | +----------+ HASH \ /
54 | +----------+ +----------+ +----------+
55 | | U-Boot | | | | U-Boot |
56 ---> | + | -----> | i.MX | -----> | + |
58 +----------+ +----------+ +----------+
60 The U-Boot image to be programmed into the boot media needs to be properly
61 constructed i.e. it must contain a proper Command Sequence File (CSF).
63 The CSF is a binary data structure interpreted by the HAB to guide
64 authentication process, this is generated by the Code Signing Tool[1].
65 The CSF structure contains the commands, SRK table, signatures and
68 Details about the Secure Boot and Code Signing Tool (CST) can be found in
69 the application note AN4581[2] and in the secure boot guides.
71 1.2 The HABv4 Encrypted Boot Architecture
72 ------------------------------------------
74 The HAB Encrypted Boot feature available in CAAM supported devices adds an
75 extra security operation to the bootloading sequence. It uses cryptographic
76 techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used
77 by unauthorized users. This mechanism protects the U-Boot code residing on
78 flash or external memory and also ensures that the final image is unique
81 The process can be divided into two protection mechanisms. The first mechanism
82 is the bootloader code encryption which provides data confidentiality and the
83 second mechanism is the digital signature, which authenticates the encrypted
86 Keep in mind that the encrypted boot makes use of both mechanisms whatever the
87 order is (sign and then encrypt, or encrypt and then sign), both operations
88 can be applied on the same region with exception of the U-Boot Header (IVT,
89 boot data and DCD) which can only be signed, not encrypted.
91 The diagram below illustrate the encrypted boot process overview:
93 Host PC + CST i.MX + HAB
94 +------------+ +--------------+
96 +------------+ +--------------+
99 v DEK +--------------+
100 +------------+ | ----> | Decrypt |
101 | Encrypt | <--- | +--------------+
102 +------------+ DEK | ^
105 v Key +------+ +--------------+
106 +------------+ | | CAAM | | Authenticate |
107 | Sign | <--- +------+ +--------------+
108 +------------+ DEK ^ ^
109 | + OTPMK DEK \ / U-Boot
112 +------------+ +----------+ +------------+
113 | Enc U-Boot | | | | Enc U-Boot |
114 | + CSF | ----> | i.MX | -------> | + CSF |
115 | + DEK Blob | | | | + DEK Blob |
116 +------------+ +----------+ +------------+
119 ---------------------
123 The Code Signing Tool automatically generates a random AES Data Encryption Key
124 (DEK) when encrypting an image. This key is used in both encrypt and decrypt
125 operations and should be present in the final image structure encapsulated
128 The OTP Master Key (OTPMK) is used to encrypt and wrap the DEK in a blob
129 structure. The OTPMK is unique per device and can be accessed by CAAM only.
130 To further add to the security of the DEK, the blob is decapsulated and
131 decrypted inside a secure memory partition that can only be accessed by CAAM.
133 During the design of encrypted boot using DEK blob, it is necessary to inhibit
134 any modification or replacement of DEK blob with a counterfeit one allowing
135 execution of malicious code. The PRIBLOB setting in CAAM allows secure boot
136 software to have its own private blobs that cannot be decapsulated or
137 encapsulated by any other user code, including any software running in trusted
140 Details about DEK Blob generation and PRIBLOB setting can be found in the
141 encrypted boot guide and application note AN12056[3] .
143 2. Generating a PKI tree
144 -------------------------
146 The first step is to generate the private keys and public keys certificates.
147 The HAB architecture is based in a Public Key Infrastructure (PKI) tree.
149 The Code Signing Tools package contains an OpenSSL based key generation script
150 under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI
151 tree containing up to 4 Super Root Keys (SRK) as well as their subordinated
154 A new PKI tree can be generated by following the example below:
156 - Generating 2048-bit PKI tree on CST v3.1.0:
160 Do you want to use an existing CA key (y/n)?: n
161 Do you want to use Elliptic Curve Cryptography (y/n)?: n
162 Enter key length in bits for PKI tree: 2048
163 Enter PKI tree duration (years): 5
164 How many Super Root Keys should be generated? 4
165 Do you want the SRK certificates to have the CA flag set? (y/n)?: y
167 The diagram below illustrate the PKI tree:
174 ---------------------------------------------------
178 +--------+ +--------+ +--------+ +--------+
179 | SRK1 | | SRK2 | | SRK3 | | SRK4 |
180 +--------+ +--------+ +--------+ +--------+
183 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
184 |CSF1| |IMG1| |CSF2| |IMG2| |CSF3| |IMG3| |CSF4| |IMG4|
185 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
187 After running the script users can check the private keys under keys/ directory
188 and their respective X.509v3 public key certificates under crts/ directory.
189 Those files will be used during the signing and authentication process.
191 2.1 Generating a fast authentication PKI tree
192 ----------------------------------------------
194 Starting in HAB v4.1.2 users can use a single SRK key to authenticate the both
195 CSF and IMG contents. This reduces the number of key pair authentications that
196 must occur during the ROM/HAB boot stage, thus providing a faster boot process.
198 The script hab4_pki_tree.sh is also able to generate a Public Key Infrastructure
199 (PKI) tree which only contains SRK Keys, users should not set the CA flag when
200 generating the SRK certificates.
202 - Generating 2048-bit fast authentication PKI tree on CST v3.1.0:
206 Do you want to use an existing CA key (y/n)?: n
207 Do you want to use Elliptic Curve Cryptography (y/n)?: n
208 Enter key length in bits for PKI tree: 2048
209 Enter PKI tree duration (years): 5
210 How many Super Root Keys should be generated? 4
211 Do you want the SRK certificates to have the CA flag set? (y/n)?: n
213 The diagram below illustrate the PKI tree generated:
220 ---------------------------------------------------
224 +--------+ +--------+ +--------+ +--------+
225 | SRK1 | | SRK2 | | SRK3 | | SRK4 |
226 +--------+ +--------+ +--------+ +--------+
228 2.2 Generating a SRK Table and SRK Hash
229 ----------------------------------------
231 The next step is to generated the SRK Table and its respective SRK Table Hash
232 from the SRK public key certificates created in one of the steps above.
234 In the HAB architecture, the SRK Table is included in the CSF binary and the
235 SRK Hash is programmed in the SoC SRK_HASH[255:0] fuses.
237 On the target device during the authentication process the HAB code verify the
238 SRK Table against the SoC SRK_HASH fuses, in case the verification success the
239 root of trust is established and the HAB code can progress with the image
242 The srktool can be used for generating the SRK Table and its respective SRK
245 - Generating SRK Table and SRK Hash in Linux 64-bit machines:
247 $ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \
248 SRK_1_2_3_4_fuse.bin -d sha256 -c \
249 SRK1_sha256_2048_65537_v3_ca_crt.pem,\
250 SRK2_sha256_2048_65537_v3_ca_crt.pem,\
251 SRK3_sha256_2048_65537_v3_ca_crt.pem,\
252 SRK4_sha256_2048_65537_v3_ca_crt.pem
254 The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further
255 steps as explained in HAB guides available under doc/imx/habv4/guides/
259 [1] CST: i.MX High Assurance Boot Reference Code Signing Tool.
260 [2] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using
262 [3] AN12056: "Encrypted Boot on HABv4 and CAAM Enabled Devices" - Rev. 1