introduction_habv4.txt 12 KB

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