mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-14 00:47:26 +00:00
263 lines
12 KiB
Text
263 lines
12 KiB
Text
|
+=======================================================+
|
||
|
|
+ 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
|