| +=======================================================+ |
| + i.MX Secure and Encrypted Boot using HABv4 + |
| +=======================================================+ |
| |
| 1. Introduction |
| ---------------- |
| |
| The i.MX family of applications processors provides the High Assurance Boot |
| (HAB) feature in the on-chip ROM. The ROM is responsible for loading the |
| initial program image (U-Boot) from the boot media and HAB enables the ROM |
| to authenticate and/or decrypt the program image by using cryptography |
| operations. |
| |
| This feature is supported in i.MX 50, i.MX 53, i.MX 6, i.MX 7 series and |
| i.MX 8M, i.MX 8MM devices. |
| |
| Step-by-step guides are available under doc/imx/habv4/guides/ directory, |
| users familiar with HAB and CST PKI tree generation should refer to these |
| documents instead. |
| |
| 1.1 The HABv4 Secure Boot Architecture |
| --------------------------------------- |
| |
| The HABv4 secure boot feature uses digital signatures to prevent unauthorized |
| software execution during the device boot sequence. In case a malware takes |
| control of the boot sequence, sensitive data, services and network can be |
| impacted. |
| |
| The HAB authentication is based on public key cryptography using the RSA |
| algorithm in which image data is signed offline using a series of private |
| keys. The resulting signed image data is then verified on the i.MX processor |
| using the corresponding public keys. The public keys are included in the CSF |
| binary and the SRK Hash is programmed in the SoC fuses for establishing the |
| root of trust. |
| |
| The diagram below illustrate the secure boot process overview: |
| |
| Host PC + CST i.MX + HAB |
| +----------+ +----------+ |
| ---> | U-Boot | | Compare | |
| | +----------+ +----------+ |
| | | ^ ^ |
| | v Reference / \ Generated |
| | +----------+ Hash / \ Hash |
| | | Hash | Private / \ |
| | +----------+ Key / \ |
| | | | +----------+ +----------+ |
| | v | | Verify | | Hash | |
| | +----------+ | +----------+ +----------+ |
| | | Sign | <--- SRK ^ ^ |
| | +----------+ HASH \ / |
| | | | CSF \ / U-Boot |
| | v v \ / |
| | +----------+ +----------+ +----------+ |
| | | U-Boot | | | | U-Boot | |
| ---> | + | -----> | i.MX | -----> | + | |
| | CSF | | | | CSF | |
| +----------+ +----------+ +----------+ |
| |
| The U-Boot image to be programmed into the boot media needs to be properly |
| constructed i.e. it must contain a proper Command Sequence File (CSF). |
| |
| The CSF is a binary data structure interpreted by the HAB to guide |
| authentication process, this is generated by the Code Signing Tool[1]. |
| The CSF structure contains the commands, SRK table, signatures and |
| certificates. |
| |
| Details about the Secure Boot and Code Signing Tool (CST) can be found in |
| the application note AN4581[2] and in the secure boot guides. |
| |
| 1.2 The HABv4 Encrypted Boot Architecture |
| ------------------------------------------ |
| |
| The HAB Encrypted Boot feature available in CAAM supported devices adds an |
| extra security operation to the bootloading sequence. It uses cryptographic |
| techniques (AES-CCM) to obscure the U-Boot data, so it cannot be seen or used |
| by unauthorized users. This mechanism protects the U-Boot code residing on |
| flash or external memory and also ensures that the final image is unique |
| per device. |
| |
| The process can be divided into two protection mechanisms. The first mechanism |
| is the bootloader code encryption which provides data confidentiality and the |
| second mechanism is the digital signature, which authenticates the encrypted |
| image. |
| |
| Keep in mind that the encrypted boot makes use of both mechanisms whatever the |
| order is (sign and then encrypt, or encrypt and then sign), both operations |
| can be applied on the same region with exception of the U-Boot Header (IVT, |
| boot data and DCD) which can only be signed, not encrypted. |
| |
| The diagram below illustrate the encrypted boot process overview: |
| |
| Host PC + CST i.MX + HAB |
| +------------+ +--------------+ |
| | U-Boot | | U-Boot | |
| +------------+ +--------------+ |
| | ^ |
| | | |
| v DEK +--------------+ |
| +------------+ | ----> | Decrypt | |
| | Encrypt | <--- | +--------------+ |
| +------------+ DEK | ^ |
| | | | |
| | Private | | |
| v Key +------+ +--------------+ |
| +------------+ | | CAAM | | Authenticate | |
| | Sign | <--- +------+ +--------------+ |
| +------------+ DEK ^ ^ |
| | + OTPMK DEK \ / U-Boot |
| | | Blob \ / + CSF |
| v v \ / |
| +------------+ +----------+ +------------+ |
| | Enc U-Boot | | | | Enc U-Boot | |
| | + CSF | ----> | i.MX | -------> | + CSF | |
| | + DEK Blob | | | | + DEK Blob | |
| +------------+ +----------+ +------------+ |
| ^ | |
| | | |
| --------------------- |
| DEK Blob |
| (CAAM) |
| |
| The Code Signing Tool automatically generates a random AES Data Encryption Key |
| (DEK) when encrypting an image. This key is used in both encrypt and decrypt |
| operations and should be present in the final image structure encapsulated |
| by a CAAM blob. |
| |
| The OTP Master Key (OTPMK) is used to encrypt and wrap the DEK in a blob |
| structure. The OTPMK is unique per device and can be accessed by CAAM only. |
| To further add to the security of the DEK, the blob is decapsulated and |
| decrypted inside a secure memory partition that can only be accessed by CAAM. |
| |
| During the design of encrypted boot using DEK blob, it is necessary to inhibit |
| any modification or replacement of DEK blob with a counterfeit one allowing |
| execution of malicious code. The PRIBLOB setting in CAAM allows secure boot |
| software to have its own private blobs that cannot be decapsulated or |
| encapsulated by any other user code, including any software running in trusted |
| mode. |
| |
| Details about DEK Blob generation and PRIBLOB setting can be found in the |
| encrypted boot guide and application note AN12056[3] . |
| |
| 2. Generating a PKI tree |
| ------------------------- |
| |
| The first step is to generate the private keys and public keys certificates. |
| The HAB architecture is based in a Public Key Infrastructure (PKI) tree. |
| |
| The Code Signing Tools package contains an OpenSSL based key generation script |
| under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI |
| tree containing up to 4 Super Root Keys (SRK) as well as their subordinated |
| IMG and CSF keys. |
| |
| A new PKI tree can be generated by following the example below: |
| |
| - Generating 2048-bit PKI tree on CST v3.1.0: |
| |
| $ ./hab4_pki_tree.sh |
| ... |
| 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: 2048 |
| Enter PKI tree duration (years): 5 |
| How many Super Root Keys should be generated? 4 |
| Do you want the SRK certificates to have the CA flag set? (y/n)?: y |
| |
| The diagram below illustrate the PKI tree: |
| |
| +---------+ |
| | CA | |
| +---------+ |
| | |
| | |
| --------------------------------------------------- |
| | | | | |
| | | | | |
| v v v v |
| +--------+ +--------+ +--------+ +--------+ |
| | SRK1 | | SRK2 | | SRK3 | | SRK4 | |
| +--------+ +--------+ +--------+ +--------+ |
| / \ / \ / \ / \ |
| v v v v v v v v |
| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |
| |CSF1| |IMG1| |CSF2| |IMG2| |CSF3| |IMG3| |CSF4| |IMG4| |
| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |
| |
| After running the script users can check the private keys under keys/ directory |
| and their respective X.509v3 public key certificates under crts/ directory. |
| Those files will be used during the signing and authentication process. |
| |
| 2.1 Generating a fast authentication PKI tree |
| ---------------------------------------------- |
| |
| Starting in HAB v4.1.2 users can use a single SRK key to authenticate the both |
| CSF and IMG contents. This reduces the number of key pair authentications that |
| must occur during the ROM/HAB boot stage, thus providing a faster boot process. |
| |
| The script hab4_pki_tree.sh is also able to generate a Public Key Infrastructure |
| (PKI) tree which only contains SRK Keys, users should not set the CA flag when |
| generating the SRK certificates. |
| |
| - Generating 2048-bit fast authentication PKI tree on CST v3.1.0: |
| |
| $ ./hab4_pki_tree.sh |
| ... |
| 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: 2048 |
| Enter PKI tree duration (years): 5 |
| How many Super Root Keys should be generated? 4 |
| Do you want the SRK certificates to have the CA flag set? (y/n)?: n |
| |
| The diagram below illustrate the PKI tree generated: |
| |
| +---------+ |
| | CA | |
| +---------+ |
| | |
| | |
| --------------------------------------------------- |
| | | | | |
| | | | | |
| v v v v |
| +--------+ +--------+ +--------+ +--------+ |
| | SRK1 | | SRK2 | | SRK3 | | SRK4 | |
| +--------+ +--------+ +--------+ +--------+ |
| |
| 2.2 Generating a SRK Table and SRK Hash |
| ---------------------------------------- |
| |
| The next step is to generated the SRK Table and its respective SRK Table Hash |
| from the SRK public key certificates created in one of the steps above. |
| |
| In the HAB architecture, the SRK Table is included in the CSF binary and the |
| SRK Hash is programmed in the SoC SRK_HASH[255:0] fuses. |
| |
| On the target device during the authentication process the HAB code verify the |
| SRK Table against the SoC SRK_HASH fuses, in case the verification success the |
| root of trust is established and the HAB code can progress with the image |
| authentication. |
| |
| The srktool can be used for generating the SRK Table and its respective SRK |
| Table Hash. |
| |
| - Generating SRK Table and SRK Hash in Linux 64-bit machines: |
| |
| $ ../linux64/bin/srktool -h 4 -t SRK_1_2_3_4_table.bin -e \ |
| SRK_1_2_3_4_fuse.bin -d sha256 -c \ |
| SRK1_sha256_2048_65537_v3_ca_crt.pem,\ |
| SRK2_sha256_2048_65537_v3_ca_crt.pem,\ |
| SRK3_sha256_2048_65537_v3_ca_crt.pem,\ |
| SRK4_sha256_2048_65537_v3_ca_crt.pem |
| |
| The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further |
| steps as explained in HAB guides available under doc/imx/habv4/guides/ |
| directory. |
| |
| References: |
| [1] CST: i.MX High Assurance Boot Reference Code Signing Tool. |
| [2] AN4581: "Secure Boot on i.MX 50, i.MX 53, i.MX 6 and i.MX 7 Series using |
| HABv4" - Rev 2. |
| [3] AN12056: "Encrypted Boot on HABv4 and CAAM Enabled Devices" - Rev. 1 |