1 +=======================================================+ 2 + i.MX Secure and Encrypted Boot using HABv4 + 3 +=======================================================+ 4 51. Introduction 6---------------- 7 8The 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 10initial program image (U-Boot) from the boot media and HAB enables the ROM 11to authenticate and/or decrypt the program image by using cryptography 12operations. 13 14This 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. 16 17Step-by-step guides are available under doc/imx/habv4/guides/ directory, 18users familiar with HAB and CST PKI tree generation should refer to these 19documents instead. 20 211.1 The HABv4 Secure Boot Architecture 22--------------------------------------- 23 24The HABv4 secure boot feature uses digital signatures to prevent unauthorized 25software execution during the device boot sequence. In case a malware takes 26control of the boot sequence, sensitive data, services and network can be 27impacted. 28 29The HAB authentication is based on public key cryptography using the RSA 30algorithm in which image data is signed offline using a series of private 31keys. The resulting signed image data is then verified on the i.MX processor 32using the corresponding public keys. The public keys are included in the CSF 33binary and the SRK Hash is programmed in the SoC fuses for establishing the 34root of trust. 35 36The diagram below illustrate the secure boot process overview: 37 38 Host PC + CST i.MX + HAB 39 +----------+ +----------+ 40 ---> | U-Boot | | Compare | 41 | +----------+ +----------+ 42 | | ^ ^ 43 | v Reference / \ Generated 44 | +----------+ Hash / \ Hash 45 | | Hash | Private / \ 46 | +----------+ Key / \ 47 | | | +----------+ +----------+ 48 | v | | Verify | | Hash | 49 | +----------+ | +----------+ +----------+ 50 | | Sign | <--- SRK ^ ^ 51 | +----------+ HASH \ / 52 | | | CSF \ / U-Boot 53 | v v \ / 54 | +----------+ +----------+ +----------+ 55 | | U-Boot | | | | U-Boot | 56 ---> | + | -----> | i.MX | -----> | + | 57 | CSF | | | | CSF | 58 +----------+ +----------+ +----------+ 59 60The U-Boot image to be programmed into the boot media needs to be properly 61constructed i.e. it must contain a proper Command Sequence File (CSF). 62 63The CSF is a binary data structure interpreted by the HAB to guide 64authentication process, this is generated by the Code Signing Tool[1]. 65The CSF structure contains the commands, SRK table, signatures and 66certificates. 67 68Details about the Secure Boot and Code Signing Tool (CST) can be found in 69the application note AN4581[2] and in the secure boot guides. 70 711.2 The HABv4 Encrypted Boot Architecture 72------------------------------------------ 73 74The HAB Encrypted Boot feature available in CAAM supported devices adds an 75extra security operation to the bootloading sequence. It uses cryptographic 76techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used 77by unauthorized users. This mechanism protects the U-Boot code residing on 78flash or external memory and also ensures that the final image is unique 79per device. 80 81The process can be divided into two protection mechanisms. The first mechanism 82is the bootloader code encryption which provides data confidentiality and the 83second mechanism is the digital signature, which authenticates the encrypted 84image. 85 86Keep in mind that the encrypted boot makes use of both mechanisms whatever the 87order is (sign and then encrypt, or encrypt and then sign), both operations 88can be applied on the same region with exception of the U-Boot Header (IVT, 89boot data and DCD) which can only be signed, not encrypted. 90 91The diagram below illustrate the encrypted boot process overview: 92 93 Host PC + CST i.MX + HAB 94 +------------+ +--------------+ 95 | U-Boot | | U-Boot | 96 +------------+ +--------------+ 97 | ^ 98 | | 99 v DEK +--------------+ 100 +------------+ | ----> | Decrypt | 101 | Encrypt | <--- | +--------------+ 102 +------------+ DEK | ^ 103 | | | 104 | Private | | 105 v Key +------+ +--------------+ 106 +------------+ | | CAAM | | Authenticate | 107 | Sign | <--- +------+ +--------------+ 108 +------------+ DEK ^ ^ 109 | + OTPMK DEK \ / U-Boot 110 | | Blob \ / + CSF 111 v v \ / 112 +------------+ +----------+ +------------+ 113 | Enc U-Boot | | | | Enc U-Boot | 114 | + CSF | ----> | i.MX | -------> | + CSF | 115 | + DEK Blob | | | | + DEK Blob | 116 +------------+ +----------+ +------------+ 117 ^ | 118 | | 119 --------------------- 120 DEK Blob 121 (CAAM) 122 123The 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 125operations and should be present in the final image structure encapsulated 126by a CAAM blob. 127 128The OTP Master Key (OTPMK) is used to encrypt and wrap the DEK in a blob 129structure. The OTPMK is unique per device and can be accessed by CAAM only. 130To further add to the security of the DEK, the blob is decapsulated and 131decrypted inside a secure memory partition that can only be accessed by CAAM. 132 133During the design of encrypted boot using DEK blob, it is necessary to inhibit 134any modification or replacement of DEK blob with a counterfeit one allowing 135execution of malicious code. The PRIBLOB setting in CAAM allows secure boot 136software to have its own private blobs that cannot be decapsulated or 137encapsulated by any other user code, including any software running in trusted 138mode. 139 140Details about DEK Blob generation and PRIBLOB setting can be found in the 141encrypted boot guide and application note AN12056[3] . 142 1432. Generating a PKI tree 144------------------------- 145 146The first step is to generate the private keys and public keys certificates. 147The HAB architecture is based in a Public Key Infrastructure (PKI) tree. 148 149The Code Signing Tools package contains an OpenSSL based key generation script 150under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI 151tree containing up to 4 Super Root Keys (SRK) as well as their subordinated 152IMG and CSF keys. 153 154A new PKI tree can be generated by following the example below: 155 156- Generating 2048-bit PKI tree on CST v3.1.0: 157 158 $ ./hab4_pki_tree.sh 159 ... 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 166 167The diagram below illustrate the PKI tree: 168 169 +---------+ 170 | CA | 171 +---------+ 172 | 173 | 174 --------------------------------------------------- 175 | | | | 176 | | | | 177 v v v v 178 +--------+ +--------+ +--------+ +--------+ 179 | SRK1 | | SRK2 | | SRK3 | | SRK4 | 180 +--------+ +--------+ +--------+ +--------+ 181 / \ / \ / \ / \ 182 v v v v v v v v 183 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 184 |CSF1| |IMG1| |CSF2| |IMG2| |CSF3| |IMG3| |CSF4| |IMG4| 185 +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ 186 187After running the script users can check the private keys under keys/ directory 188and their respective X.509v3 public key certificates under crts/ directory. 189Those files will be used during the signing and authentication process. 190 1912.1 Generating a fast authentication PKI tree 192---------------------------------------------- 193 194Starting in HAB v4.1.2 users can use a single SRK key to authenticate the both 195CSF and IMG contents. This reduces the number of key pair authentications that 196must occur during the ROM/HAB boot stage, thus providing a faster boot process. 197 198The 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 200generating the SRK certificates. 201 202- Generating 2048-bit fast authentication PKI tree on CST v3.1.0: 203 204 $ ./hab4_pki_tree.sh 205 ... 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 212 213The diagram below illustrate the PKI tree generated: 214 215 +---------+ 216 | CA | 217 +---------+ 218 | 219 | 220 --------------------------------------------------- 221 | | | | 222 | | | | 223 v v v v 224 +--------+ +--------+ +--------+ +--------+ 225 | SRK1 | | SRK2 | | SRK3 | | SRK4 | 226 +--------+ +--------+ +--------+ +--------+ 227 2282.2 Generating a SRK Table and SRK Hash 229---------------------------------------- 230 231The next step is to generated the SRK Table and its respective SRK Table Hash 232from the SRK public key certificates created in one of the steps above. 233 234In the HAB architecture, the SRK Table is included in the CSF binary and the 235SRK Hash is programmed in the SoC SRK_HASH[255:0] fuses. 236 237On the target device during the authentication process the HAB code verify the 238SRK Table against the SoC SRK_HASH fuses, in case the verification success the 239root of trust is established and the HAB code can progress with the image 240authentication. 241 242The srktool can be used for generating the SRK Table and its respective SRK 243Table Hash. 244 245- Generating SRK Table and SRK Hash in Linux 64-bit machines: 246 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 253 254The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further 255steps as explained in HAB guides available under doc/imx/habv4/guides/ 256directory. 257 258References: 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 261 HABv4" - Rev 2. 262[3] AN12056: "Encrypted Boot on HABv4 and CAAM Enabled Devices" - Rev. 1 263