Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- +=======================================================+
- + 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
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
