Lines Matching refs:the
10 The aim of this document is to describe the authentication framework implemented
11 in the Trusted Firmware. This framework fulfills the following requirements:
13 #. It should be possible for a platform port to specify the Chain of Trust in
14 terms of certificate hierarchy and the mechanisms used to verify a
23 - The mechanism used to verify the transported information i.e. the
26 The framework has been designed following a modular approach illustrated in the
67 This document describes the inner details of the authentication framework and
68 the abstraction mechanisms available to specify a Chain of Trust.
73 This section describes some aspects of the framework design and the rationale
81 illustrates how this maps to a CoT for the BL31 image described in the
124 The root of trust is usually a public key (ROTPK) that has been burnt in the
138 For every image in a Chain of Trust, the following high level operations are
141 #. Allocate memory for the image either statically or at runtime.
143 #. Identify the image and load it in the allocated memory.
145 #. Check the integrity of the image as per its type.
147 #. Authenticate the image as per the cryptographic algorithms used.
149 #. If the image is an authentication image, extract the information that will
150 be used to authenticate the next image in the CoT.
158 These components are responsible for initiating the authentication process for a
160 the Generic code asks recursively the Authentication module what is the parent
161 image until either an authenticated image or the ROT is reached. Then the
162 Generic code calls the IO framewotk to load the image and calls the
163 Authentication module to authenticate it, following the CoT from ROT to Image.
170 #. Specifying the CoT for each image that needs to be authenticated. Details of
171 how a CoT can be specified by the platform are explained later. The platform
172 also specifies the authentication methods and the parsing method used for
176 used for verifying the CoT, e.g. memory for public keys, hashes etc.
178 #. Providing the ROTPK or a hash of it.
180 #. Providing additional information to the IPM to enable it to identify and
181 extract authentication parameters contained in an image, e.g. if the
182 parameters are stored as X509v3 extensions, the corresponding OID must be
185 #. Fulfill any other memory requirements of the IPM and the CM (not currently
189 cannot be interpreted by the CM, e.g. if an image has to be verified using a
190 NV counter, then the value of the counter to compare with can only be
191 provided by the platform.
201 #. Providing the necessary abstraction mechanisms to describe a CoT. Amongst
202 other things, the authentication and image parsing methods must be specified
203 by the PP in the CoT.
205 #. Verifying the CoT passed by GEN by utilising functionality exported by the
209 multiple CoTs then it should be verified only once e.g. the Trusted World
210 Key Certificate in the TBBR-Client spec. contains information to verify
216 in the CoT described in Diagram 2, each certificate can be loaded and
217 verified in the memory reserved by the platform for the BL31 image. By the
218 time BL31 (the data image) is loaded, all information to authenticate it
219 will have been extracted from the parent image i.e. BL31 content
220 certificate. It is assumed that the size of an authentication image will
221 never exceed the size of a data image. It should be possible to verify this
233 external library to perform the cryptographic operations. A Crypto-Library (CL)
234 linking the CM and the external library must be implemented. The following
235 functions must be provided by the CL:
247 These functions are registered in the CM using the macro:
253 ``_name`` must be a string containing the name of the CL. This name is used for
261 #. Checking the integrity of each image loaded by the IO framework.
263 description provided by the platform in the CoT descriptor.
268 used in the CoT. This library must implement the specific methods to parse the
269 image. The IPM obtains the image format from the CoT and calls the right IPL to
270 check the image integrity and extract the authentication parameters.
272 See Section "Describing the image parsing methods" for more details about the
273 mechanism the IPM provides to define and register IPLs.
278 The AM supports the following authentication methods:
283 The platform may specify these methods in the CoT in case it decides to define
286 If a data image uses multiple methods, then all the methods must be a part of
287 the same CoT. The number and type of parameters are method specific. These
288 parameters should be obtained from the parent image using the IPM.
295 #. Length of the data
296 #. A pointer to the hash
297 #. Length of the hash
299 The hash will be represented by the DER encoding of the following ASN.1
309 This ASN.1 structure makes it possible to remove any assumption about the
310 type of hash algorithm used as this information accompanies the hash. This
311 should allow the Cryptography Library (CL) to support multiple hash
319 #. Length of the data
325 The Public Key parameters will be represented by the DER encoding of the
334 The Digital Signature Algorithm will be represented by the DER encoding of
335 the following ASN.1 types.
350 The authentication framework will use the image descriptor to extract all the
357 particular order. The order dictates the sequence in which they must be
358 verified. Each image has a set of properties which allow the AM to verify it.
362 Unless otherwise specified, the data structures described in the following
363 sections are populated by the PP statically.
365 Describing the image parsing methods
368 The parsing method refers to the format of a particular image. For example, an
369 authentication image that represents a certificate could be in the X.509v3
372 of the three methods described below. An IPL is responsible for interpreting a
373 single parsing method. There has to be one IPL for every method used by the
383 by this method. Such libraries can be used to write the corresponding IPL
384 e.g. the X.509 parsing library code in mbed TLS.
388 example, The signature of a data image could be appended to the data image
389 raw binary. A header could be prepended to the combined blob to specify the
390 extents of each component. The platform will have to implement the
404 An IPL must provide functions with the following prototypes:
414 An IPL for each type must be registered using the following macro:
420 - ``_type``: one of the types described above.
421 - ``_name``: a string containing the IPL name for debugging purposes.
426 The ``init()`` function will be used to initialize the IPL.
428 The ``check_integrity()`` function is passed a pointer to the memory where the
429 image has been loaded by the IO framework and the image length. It should ensure
430 that the image is in the format corresponding to the parsing method and has not
435 information about the parameter (``type_desc`` and ``cookie``) to identify and
436 extract the data corresponding to that parameter from an image. This data will
437 be used to verify either the current or the next image in the CoT sequence.
439 Each image in the CoT will specify the parsing method it uses. This information
440 will be used by the IPM to find the right parser descriptor for the image.
442 Describing the authentication method(s)
445 As part of the CoT, each image has to specify one or more authentication methods
446 which will be used to verify it. As described in the Section "Authentication
447 methods", there are three methods supported by the AM.
458 The AM defines the type of each parameter used by an authentication method. It
461 #. Specify to the ``get_auth_param()`` function exported by the IPM, which
464 #. Correctly marshall the parameters while calling the verification function
465 exported by the CM and PP.
468 child image e.g. to verify the certificate image, the public key has to be
469 obtained from the parent image.
478 AUTH_PARAM_HASH, /* A hash (including the algorithm) */
482 The AM defines the following structure to identify an authentication parameter
492 ``cookie`` is used by the platform to specify additional information to the IPM
493 which enables it to uniquely identify the parameter that should be extracted
494 from an image. For example, the hash of a BL3x image in its corresponding
496 field can only be identified using an OID. In this case, the ``cookie`` could
497 contain the pointer to the OID defined by the platform for the hash extension
498 field while the ``type`` field could be set to ``AUTH_PARAM_HASH``. A value of 0 for
499 the ``cookie`` field means that it is not used.
501 For each method, the AM defines a structure with the parameters required to
502 verify the image.
524 The AM defines the following structure to describe an authentication method for
540 Using the method type specified in the ``type`` field, the AM finds out what field
541 needs to access within the ``param`` union.
547 obtained from either the image itself or its parent image. The memory allocated
548 for loading the parent image will be reused for loading the child image. Hence
549 parameters which are obtained from the parent for verifying a child image need
551 memory must be statically allocated by the platform port.
553 The AM defines the following structure to store the data corresponding to an
563 The ``auth_param_ptr`` field is initialized by the platform. The ``auth_param_len``
564 field is used to specify the length of the data in the memory.
566 For parameters that can be obtained from the child image itself, the IPM is
567 responsible for populating the ``auth_param_ptr`` and ``auth_param_len`` fields
568 while executing the ``img_get_auth_param()`` function.
570 The AM defines the following structure to enable an image to describe the
571 parameters that should be extracted from it and used to verify the next image
584 An image in a CoT is a consolidation of the following aspects of a CoT described
587 #. A unique identifier specified by the platform which allows the IO framework
588 to locate the image in a FIP and load it in the memory reserved for the data
589 image in the CoT.
591 #. A parsing method which is used by the AM to find the appropriate IPM.
593 #. Authentication methods and their parameters as described in the previous
594 section. These are used to verify the current image.
596 #. Parameters which are used to verify the next image in the current CoT. These
598 from the current image once it has been verified.
613 by the ``parent`` field. Those nodes with no parent must be authenticated using
614 the ROTPK stored in the platform.
620 the authentication framework. This example corresponds to the Applicative
621 Functional Mode (AFM) as specified in the TBBR-Client document. It is
622 recommended to read this guide along with the source code.
628 array of image descriptors and it is registered in the framework using the macro
629 ``REGISTER_COT(cot_desc)``, where 'cot\_desc' must be the name of the array
630 (passing a pointer or any other type of indirection will cause the registration
633 The number of images participating in the boot process depends on the CoT. There
634 is, however, a minimum set of images that are mandatory in the Trusted Firmware
643 The TBBR specifies the additional certificates that must accompany these images
644 for a proper authentication. Details about the TBBR CoT may be found in the
647 Following the `Platform Porting Guide`_, a platform must provide unique
648 identifiers for all the images and certificates that will be loaded during the
649 boot process. If a platform is using the TBBR as a reference for trusted boot,
654 **Important**: the authentication module uses these identifiers to index the
655 CoT array, so the descriptors location in the array must match the identifiers.
659 - ``img_id``: the corresponding image unique identifier defined by the platform.
660 - ``img_type``: the image parser module uses the image type to call the proper
661 parsing library to check the image integrity and extract the required
665 other than reading the whole image.
667 type for custom images not directly supported by the authentication
671 - ``parent``: pointer to the parent image descriptor. The parent will contain
672 the information required to authenticate the current image. If the parent
673 is NULL, the authentication parameters will be obtained from the platform
674 (i.e. the BL2 and Trusted Key certificates are signed with the ROT private
675 key, whose public part is stored in the platform).
676 - ``img_auth_methods``: this array defines the authentication methods that must
680 extract that parameter from the image (i.e. if the parameter is stored in an
681 x509v3 extension, the cookie will point to the extension OID). Depending on
682 the method type, a different number of parameters must be specified.
685 - ``AUTH_METHOD_HASH``: the hash of the image must match the hash extracted
686 from the parent image. The following parameter descriptors must be
692 - ``AUTH_METHOD_SIG``: the image (usually a certificate) must be signed with
693 the private key whose public part is extracted from the parent image (or
694 the platform if the parent is NULL). The following parameter descriptors
697 - ``pk``: the public key (obtained from parent image)
698 - ``sig``: the digital signature (obtained from current image)
699 - ``alg``: the signature algorithm used (obtained from current image)
700 - ``data``: the data to be signed (obtained from current image)
704 parameter consists of a parameter descriptor and the buffer address/size
705 to store the parameter. The CoT is responsible for allocating the required
706 memory to store the parameters.
708 In the ``tbbr_cot.c`` file, a set of buffers are allocated to store the parameters
709 extracted from the certificates. In the case of the TBBR CoT, these parameters
711 bytes, and a hash requires 51 bytes. Depending on the CoT and the authentication
712 process, some of the buffers may be reused at different stages during the boot.
714 Next in that file, the parameter descriptors are defined. These descriptors will
715 be used to extract the parameter data from the corresponding image.
717 Example: the BL31 Chain of Trust
720 Four image descriptors form the BL31 Chain of Trust:
821 The **Trusted Key certificate** is signed with the ROT private key and contains
822 the Trusted World public key and the Non-Trusted World public key as x509v3
823 extensions. This must be specified in the image descriptor using the
827 using the ROTPK. Four parameters are required to check a signature: the public
828 key, the algorithm, the signature and the data that has been signed. Therefore,
829 four parameter descriptors must be specified with the authentication method:
832 is used to extract a public key from the parent image. If the cookie is an
833 OID, the key is extracted from the corresponding x509v3 extension. If the
834 cookie is NULL, the subject public key is retrieved. In this case, because
835 the parent image is NULL, the public key is obtained from the platform
836 (this key will be the ROTPK).
838 the signature from the certificate.
840 extract the signature algorithm from the certificate.
842 to extract the data to be signed from the certificate.
844 Once the signature has been checked and the certificate authenticated, the
845 Trusted World public key needs to be extracted from the certificate. A new entry
846 is created in the ``authenticated_data`` array for that purpose. In that entry,
847 the corresponding parameter descriptor must be specified along with the buffer
848 address to store the parameter value. In this case, the ``tz_world_pk`` descriptor
849 is used to extract the public key from an x509v3 extension with OID
851 parameter in the signature authentication method. The key is stored in the
855 using the Trusted World public key obtained previously from the Trusted Key
856 certificate. In the image descriptor, we specify a single authentication method
857 by signature whose public key is the ``tz_world_pk``. Once this certificate has
858 been authenticated, we have to extract the BL31 public key, stored in the
859 extension specified by ``bl31_content_pk``. This key will be copied to the
863 using the BL31 public key obtained previously from the BL31 Key certificate.
864 We specify the authentication method using ``bl31_content_pk`` as public key.
865 After authentication, we need to extract the BL31 hash, stored in the extension
866 specified by ``bl31_hash``. This hash will be copied to the ``plat_bl31_hash_buf``
870 with the hash obtained from the BL31 certificate. The image descriptor contains
871 a single authentication method by hash. The parameters to the hash method are
872 the reference hash, ``bl31_hash``, and the data to be hashed. In this case, it is
873 the whole image, so we specify ``raw_data``.
878 The image parser module relies on libraries to check the image integrity and
879 extract the authentication parameters. The number and type of parser libraries
880 depend on the images used in the CoT. Raw images do not need a library, so
881 only an x509v3 library is required for the TBBR CoT.
895 The library is registered in the framework using the macro
896 ``REGISTER_IMG_PARSER_LIB()``. Each time the image parser module needs to access
897 an image of type ``IMG_CERT``, it will call the corresponding function exported
900 The build system must be updated to include the corresponding library and
901 mbed TLS sources. ARM platforms use the ``arm_common.mk`` file to pull the
907 The cryptographic module relies on a library to perform the required operations,
910 ``drivers/auth/mbedtls/mbedtls_crypto.c``. This library is registered in the
911 authentication framework using the macro ``REGISTER_CRYPTO_LIB()`` and exports
924 The mbedTLS library algorithm support is configured by the
926 `rsa+ecdsa`. This variable allows the Makefile to include the corresponding
927 sources in the build for the various algorthms. Setting the variable to
928 `rsa+ecdsa` enables support for both rsa and ecdsa algorithms in the mbedTLS
931 Note: If code size is a concern, the build option ``MBEDTLS_SHA256_SMALLER`` can
932 be defined in the platform Makefile. It will make mbed TLS use an implementation