--- /dev/null
+ +=======================================================+
+ + 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
projects / u-boot.git / commitdiff