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
250 These functions are registered in the CM using the macro:
267 This function is mainly used in the ``MEASURED_BOOT`` and ``DRTM_SUPPORT``
276 hash is saved in OTP.
286 - ``hashed_pk_ptr``: to return a pointer to a buffer, which hash should be the one saved in OTP.
296 description provided by the platform in the CoT descriptor.
301 used in the CoT. This library must implement the specific methods to parse the
316 The platform may specify these methods in the CoT in case it decides to define
389 A CoT can be described as a set of image descriptors linked together in a
390 particular order. The order dictates the sequence in which they must be
395 Unless otherwise specified, the data structures described in the following
402 authentication image that represents a certificate could be in the X.509v3
403 format. A data image that represents a boot loader stage could be in raw binary
410 is treated as being in raw binary format e.g. boot loader images used by
417 e.g. the X.509 parsing library code in mbed TLS.
463 that the image is in the format corresponding to the parsing method and has not
470 be used to verify either the current or the next image in the CoT sequence.
472 Each image in the CoT will specify the parsing method it uses. This information
479 which will be used to verify it. As described in the Section "Authentication
500 #. Extract authentication parameters from a parent image in order to verify a
527 from an image. For example, the hash of a BL3x image in its corresponding
528 content certificate is stored in an X509v3 custom extension field. An extension
573 Using the method type specified in the ``type`` field, the AM finds out what field
597 field is used to specify the length of the data in the memory.
605 (child) in a CoT.
614 Describing an image in a CoT
617 An image in a CoT is a consolidation of the following aspects of a CoT described
621 to locate the image in a FIP and load it in the memory reserved for the data
622 image in the CoT.
626 #. Authentication methods and their parameters as described in the previous
629 #. Parameters which are used to verify the next image in the current CoT. These
633 The following data structure describes an image in a CoT.
647 authenticated using the ROTPK stored in the platform.
654 Functional Mode (AFM) as specified in the TBBR-Client document. It is
660 CoT specific to BL1 and BL2 can be found in ``drivers/auth/tbbr/tbbr_cot_bl1.c``
662 BL1 and BL2 can be found in ``drivers/auth/tbbr/tbbr_cot_common.c``.
664 registered in the framework using the macro ``REGISTER_COT(cot_desc)``, where
668 The number of images participating in the boot process depends on the CoT.
669 There is, however, a minimum set of images that are mandatory in TF-A and thus
679 for a proper authentication. Details about the TBBR CoT may be found in the
686 Arm platforms include this file in ``include/plat/arm/common/arm_def.h``. Other
690 CoT array, so the descriptors location in the array must match the identifiers.
710 key, whose public part is stored in the platform).
716 the image (i.e. if the parameter is stored in an x509v3 extension, the
751 Next in that file, the parameter descriptors are defined. These descriptors will
888 extensions. This must be specified in the image descriptor using the
911 is created in the ``authenticated_data`` array for that purpose. In that entry,
916 parameter in the signature authentication method. The key is stored in the
923 has been authenticated, we have to extract the BL31 public key, stored in the
930 After authentication, we need to extract the BL31 hash, stored in the extension
945 depend on the images used in the CoT. Raw images do not need a library, so
949 found in ``drivers/auth/mbedtls/mbedtls_x509_parser.c``. It exports three
960 The library is registered in the framework using the macro
963 in this file.
974 based on mbed TLS, which can be found in
975 ``drivers/auth/mbedtls/mbedtls_crypto.c``. This library is registered in the
1000 - ``TF_MBEDTLS_KEY_ALG`` can take in 3 values: `rsa`, `ecdsa` or `rsa+ecdsa`.
1001 This variable allows the Makefile to include the corresponding sources in
1003 enables support for both rsa and ecdsa algorithms in the mbedTLS library.
1013 be defined in the platform Makefile. It will make mbed TLS use an