Lines Matching refs:the
11 the platform by authenticating all firmware images up to and including the
15 This document describes the design of ARM Trusted Firmware TBB, which is an
16 implementation of the Trusted Board Boot Requirements (TBBR) specification,
17 ARM DEN0006C-1. It should be used in conjunction with the `Firmware Update`_
18 design document, which implements a specific aspect of the TBBR.
24 the ARM development platforms, these components are:
26 - A SHA-256 hash of the Root of Trust Public Key (ROTPK). It is stored in the
29 - The BL1 image, on the assumption that it resides in ROM so cannot be
32 The remaining components in the CoT are either certificates or boot loader
33 images. The certificates follow the `X.509 v3`_ standard. This standard
34 enables adding custom extensions to the certificates, which are used to store
35 essential information to establish the CoT.
37 In the TBB CoT all certificates are self-signed. There is no need for a
38 Certificate Authority (CA) because the CoT is not established by verifying the
39 validity of a certificate's issuer but by the content of the certificate
40 extensions. To sign the certificates, the PKCS#1 SHA-256 with RSA Encryption
46 certificates. Content certificates are used to store the hash of a boot loader
48 with the hash extracted from the content certificate. The SHA-256 function is
50 non-standard extension fields in the `X.509 v3`_ certificates.
52 The keys used to establish the CoT are:
56 The private part of this key is used to sign the BL2 content certificate and
57 the trusted key certificate. The public part is the ROTPK.
61 The private part is used to sign the key certificates corresponding to the
63 one of the extension fields in the trusted world certificate.
67 The private part is used to sign the key certificate corresponding to the
68 non secure world image (BL33). The public part is stored in one of the
69 extension fields in the trusted world certificate.
73 For each of SCP\_BL2, BL31, BL32 and BL33, the private part is used to
74 sign the content certificate for the BL3-X image. The public part is stored
75 in one of the extension fields in the corresponding key certificate.
77 The following images are included in the CoT:
86 The following certificates are used to authenticate the images.
90 It is self-signed with the private part of the ROT key. It contains a hash
91 of the BL2 image.
95 It is self-signed with the private part of the ROT key. It contains the
96 public part of the trusted world key and the public part of the non-trusted
101 It is self-signed with the trusted world key. It contains the public part of
102 the SCP\_BL2 key.
106 It is self-signed with the SCP\_BL2 key. It contains a hash of the SCP\_BL2
111 It is self-signed with the trusted world key. It contains the public part of
112 the BL31 key.
116 It is self-signed with the BL31 key. It contains a hash of the BL31 image.
120 It is self-signed with the trusted world key. It contains the public part of
121 the BL32 key.
125 It is self-signed with the BL32 key. It contains a hash of the BL32 image.
129 It is self-signed with the non-trusted world key. It contains the public
130 part of the BL33 key.
134 It is self-signed with the BL33 key. It contains a hash of the BL33 image.
136 The SCP\_BL2 and BL32 certificates are optional, but they must be present if the
142 The CoT is verified through the following sequence of steps. The system panics
143 if any of the steps fail.
145 - BL1 loads and verifies the BL2 content certificate. The issuer public key is
146 read from the verified certificate. A hash of that key is calculated and
147 compared with the hash of the ROTPK read from the trusted root-key storage
148 registers. If they match, the BL2 hash is read from the certificate.
150 Note: the matching operation is platform specific and is currently
151 unimplemented on the ARM development platforms.
153 - BL1 loads the BL2 image. Its hash is calculated and compared with the hash
154 read from the certificate. Control is transferred to the BL2 image if all
155 the comparisons succeed.
157 - BL2 loads and verifies the trusted key certificate. The issuer public key is
158 read from the verified certificate. A hash of that key is calculated and
159 compared with the hash of the ROTPK read from the trusted root-key storage
160 registers. If the comparison succeeds, BL2 reads and saves the trusted and
161 non-trusted world public keys from the verified certificate.
163 The next two steps are executed for each of the SCP\_BL2, BL31 & BL32 images.
164 The steps for the optional SCP\_BL2 and BL32 images are skipped if these images
167 - BL2 loads and verifies the BL3x key certificate. The certificate signature
168 is verified using the trusted world public key. If the signature
169 verification succeeds, BL2 reads and saves the BL3x public key from the
172 - BL2 loads and verifies the BL3x content certificate. The signature is
173 verified using the BL3x public key. If the signature verification succeeds,
174 BL2 reads and saves the BL3x image hash from the certificate.
176 The next two steps are executed only for the BL33 image.
178 - BL2 loads and verifies the BL33 key certificate. If the signature
179 verification succeeds, BL2 reads and saves the BL33 public key from the
182 - BL2 loads and verifies the BL33 content certificate. If the signature
183 verification succeeds, BL2 reads and saves the BL33 image hash from the
186 The next step is executed for all the boot loader images.
188 - BL2 calculates the hash of each image. It compares it with the hash obtained
189 from the corresponding content certificate. The image authentication succeeds
190 if the hashes match.
193 BL1 and BL2 code, and in tool code on the host build machine. The feature is
194 enabled through use of specific build flags as described in the `User Guide`_.
196 On the host machine, a tool generates the certificates, which are included in
197 the FIP along with the boot loader images. These certificates are loaded in
198 Trusted SRAM using the IO storage framework. They are then verified by an
199 Authentication module included in the Trusted Firmware.
201 The mechanism used for generating the FIP and the Authentication module are
202 described in the following sections.
207 The authentication framework included in the Trusted Firmware provides support
208 to implement the desired trusted boot sequence. ARM platforms use this framework
209 to implement the boot requirements specified in the TBBR-client document.
211 More information about the authentication framework can be found in the
217 The ``cert_create`` tool is built and runs on the host machine as part of the
218 Trusted Firmware build process when ``GENERATE_COT=1``. It takes the boot loader
219 images and keys as inputs (keys must be in PEM format) and generates the
220 certificates (in DER format) required to establish the CoT. New keys can be
221 generated by the tool in case they are not provided. The certificates are then
222 passed as inputs to the ``fiptool`` utility for creating the FIP.
224 The certificates are also stored individually in the in the output build
227 The tool resides in the ``tools/cert_create`` directory. It uses OpenSSL SSL
228 library version 1.0.1 or later to generate the X.509 certificates. Instructions
229 for building and using the tool can be found in the `User Guide`_.