docs/design/trusted-board-boot.rst

6 normal world bootloader. It does this by establishing a `Chain of Trust` using
9 This document describes the design of Trusted Firmware-A (TF-A) TBB, which is an
10 implementation of the `Trusted Board Boot Requirements (TBBR)`_ specification,
12 (FWU)` design document, which implements a specific aspect of the TBBR.
14 Chain of Trust
17 A Chain of Trust (CoT) starts with a set of implicitly trusted components, which
18 are used to establish trust in the next layer of components, and so on, in a
21 The chain of trust depends on several factors, including:
23 -  The set of firmware images in use on this platform.
24    Typically, most platforms share a common set of firmware images (BL1, BL2,
32 As these vary across platforms, chains of trust also vary across
34 needs, TF-A provides a set of "default" CoTs fitting some typical trust models,
35 which platforms may reuse. The rest of this section presents general concepts
40 -  A Root of Trust Public Key (ROTPK), or a hash of it.
42    On Arm development platforms, a hash of the ROTPK (hash algorithm selected by
57 (CA) because the CoT is not established by verifying the validity of a
58 certificate's issuer but by the content of the certificate extensions. To sign
64 certificates. Content certificates are used to store the hash of a boot loader
71 The next sections now present specificities of each default CoT provided in
80 indirectly) linked to the Root of Trust Public Key (ROTPK). Typically, the same
86 -  **Root of trust key**
88    The private part of this key is used to sign the trusted boot firmware
95    one of the extension fields in the trusted key certificate.
100    non-secure world image (BL33). The public part is stored in one of the
105    For each of SCP_BL2, BL31, BL32 and BL33, the private part is used to
107    in one of the extension fields in the corresponding key certificate.
122    It is self-signed with the private part of the ROT key. It contains a hash of
123    the BL2 image and hashes of various firmware configuration files
128    It is self-signed with the private part of the ROT key. It contains the
129    public part of the trusted world key and the public part of the non-trusted
134    It is self-signed with the trusted world key. It contains the public part of
139    It is self-signed with the SCP_BL2 key. It contains a hash of the SCP_BL2
144    It is self-signed with the trusted world key. It contains the public part of
149    It is self-signed with the BL31 key. It contains hashes of the BL31 image and
154    It is self-signed with the trusted world key. It contains the public part of
159    It is self-signed with the BL32 key. It contains hashes of the BL32 image(s)
165    part of the BL33 key.
169    It is self-signed with the BL33 key. It contains hashes of the BL33 image and
175 The following diagram summarizes the part of the TBBR CoT enforced by BL2. Some
188 domains, each with its own Root of Trust key. In that sense, this CoT has 2
189 roots of trust, hence the `dualroot` name.
191 Although the dualroot CoT reuses some of the TBBR CoT components and concepts,
192 it differs on the BL33 image's chain of trust, which is rooted into a new key,
195 The following diagram summarizes the part of the dualroot CoT enforced by
206 platform owner firmware, independent. Hence, this CoT has 3 roots of trust, one
212 The CoT is verified through the following sequence of steps. The system panics
213 if any of the steps fail.
216    read from the verified certificate. A hash of that key is calculated and
217    compared with the hash of the ROTPK read from the trusted root-key storage
229    read from the verified certificate. A hash of that key is calculated and
230    compared with the hash of the ROTPK read from the trusted root-key storage
234 The next two steps are executed for each of the SCP_BL2, BL31 & BL32 images.
259 -  BL2 calculates the hash of each image. It compares it with the hash obtained
265 enabled through use of specific build flags as described in
285 :ref:`Authentication Framework & Chain of Trust` document.
290 The ``cert_create`` tool is built and runs on the host machine as part of the
301 library version to generate the X.509 certificates. The specific version of the
319 The ``encrypt_fw`` tool is built and runs on the host machine as part of the