Lines Matching refs:in
5 implemented in Trusted Firmware-A (TF-A). This framework fulfills the
8 #. It should be possible for a platform port to specify the Chain of Trust in
21 The framework has been designed following a modular approach illustrated in the
75 a root of trust and culminates in a single data image. The following diagram
76 illustrates how this maps to a CoT for the BL31 image described in the
119 The root of trust is usually a public key (ROTPK) that has been burnt in the
125 Images in a CoT are categorised as authentication and data images. An
133 For every image in a Chain of Trust, the following high level operations are
138 #. Identify the image and load it in the allocated memory.
145 be used to authenticate the next image in the CoT.
154 particular image in BL1 or BL2. For each BL image that requires authentication,
170 #. Statically allocating memory for each parameter in each image which is
176 extract authentication parameters contained in an image, e.g. if the
181 described in this document).
198 by the PP in the CoT.
205 Key Certificate in the TBBR-Client spec. contains information to verify
207 responsibility has not been described in this document but should be
211 in the CoT described in Diagram 2, each certificate can be loaded and
212 verified in the memory reserved by the platform for the BL31 image. By the
242 These functions are registered in the CM using the macro:
258 description provided by the platform in the CoT descriptor.
263 used in the CoT. This library must implement the specific methods to parse the
278 The platform may specify these methods in the CoT in case it decides to define
351 A CoT can be described as a set of image descriptors linked together in a
352 particular order. The order dictates the sequence in which they must be
357 Unless otherwise specified, the data structures described in the following
364 authentication image that represents a certificate could be in the X.509v3
365 format. A data image that represents a boot loader stage could be in raw binary
372 is treated as being in raw binary format e.g. boot loader images used by
379 e.g. the X.509 parsing library code in mbed TLS.
425 that the image is in the format corresponding to the parsing method and has not
432 be used to verify either the current or the next image in the CoT sequence.
434 Each image in the CoT will specify the parsing method it uses. This information
441 which will be used to verify it. As described in the Section "Authentication
462 #. Extract authentication parameters from a parent image in order to verify a
489 from an image. For example, the hash of a BL3x image in its corresponding
490 content certificate is stored in an X509v3 custom extension field. An extension
535 Using the method type specified in the ``type`` field, the AM finds out what field
559 field is used to specify the length of the data in the memory.
567 (child) in a CoT.
576 Describing an image in a CoT
579 An image in a CoT is a consolidation of the following aspects of a CoT described
583 to locate the image in a FIP and load it in the memory reserved for the data
584 image in the CoT.
588 #. Authentication methods and their parameters as described in the previous
591 #. Parameters which are used to verify the next image in the current CoT. These
595 The following data structure describes an image in a CoT.
609 authenticated using the ROTPK stored in the platform.
616 Functional Mode (AFM) as specified in the TBBR-Client document. It is
622 CoT specific to BL1 and BL2 can be found in ``drivers/auth/tbbr/tbbr_cot_bl1.c``
624 BL1 and BL2 can be found in ``drivers/auth/tbbr/tbbr_cot_common.c``.
626 registered in the framework using the macro ``REGISTER_COT(cot_desc)``, where
630 The number of images participating in the boot process depends on the CoT.
631 There is, however, a minimum set of images that are mandatory in TF-A and thus
641 for a proper authentication. Details about the TBBR CoT may be found in the
648 Arm platforms include this file in ``include/plat/arm/common/arm_def.h``. Other
652 CoT array, so the descriptors location in the array must match the identifiers.
672 key, whose public part is stored in the platform).
678 the image (i.e. if the parameter is stored in an x509v3 extension, the
713 Next in that file, the parameter descriptors are defined. These descriptors will
850 extensions. This must be specified in the image descriptor using the
873 is created in the ``authenticated_data`` array for that purpose. In that entry,
878 parameter in the signature authentication method. The key is stored in the
885 has been authenticated, we have to extract the BL31 public key, stored in the
892 After authentication, we need to extract the BL31 hash, stored in the extension
907 depend on the images used in the CoT. Raw images do not need a library, so
911 found in ``drivers/auth/mbedtls/mbedtls_x509_parser.c``. It exports three
922 The library is registered in the framework using the macro
925 in this file.
936 based on mbed TLS, which can be found in
937 ``drivers/auth/mbedtls/mbedtls_crypto.c``. This library is registered in the
959 - ``TF_MBEDTLS_KEY_ALG`` can take in 3 values: `rsa`, `ecdsa` or `rsa+ecdsa`.
960 This variable allows the Makefile to include the corresponding sources in
962 enables support for both rsa and ecdsa algorithms in the mbedTLS library.
972 be defined in the platform Makefile. It will make mbed TLS use an