Lines Matching refs:be
13 #. It should be possible for a platform port to specify the Chain of Trust in
125 platform and cannot be modified.
133 it could be any other data that requires authentication.
150 be used to authenticate the next image in the CoT.
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
182 parameters are stored as X509v3 extensions, the corresponding OID must be
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
202 other things, the authentication and image parsing methods must be specified
209 multiple CoTs then it should be verified only once e.g. the Trusted World
212 responsibility has not been described in this document but should be
216 in the CoT described in Diagram 2, each certificate can be loaded and
221 never exceed the size of a data image. It should be possible to verify this
234 linking the CM and the external library must be implemented. The following
235 functions must be provided by the CL:
253 ``_name`` must be a string containing the name of the CL. This name is used for
265 Images may have different formats (for example, authentication images could be
286 If a data image uses multiple methods, then all the methods must be a part of
288 parameters should be obtained from the parent image using the IPM.
299 The hash will be represented by the DER encoding of the following ASN.1
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
344 The digital signature will be represented by:
356 A CoT can be described as a set of image descriptors linked together in a
357 particular order. The order dictates the sequence in which they must be
369 authentication image that represents a certificate could be in the X.509v3
370 format. A data image that represents a boot loader stage could be in raw binary
373 single parsing method. There has to be one IPL for every method used by the
378 TF. This method should only be used by data images.
382 libraries will be available which can be used to parse an image represented
383 by this method. Such libraries can be used to write the corresponding IPL
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
393 The following enum can be used to define these three methods.
414 An IPL for each type must be registered using the following macro:
426 The ``init()`` function will be used to initialize the IPL.
437 be used to verify either the current or the next image in the CoT sequence.
440 will be used by the IPM to find the right parser descriptor for the image.
446 which will be used to verify it. As described in the Section "Authentication
462 parameter should be extracted from an image.
468 child image e.g. to verify the certificate image, the public key has to be
493 which enables it to uniquely identify the parameter that should be extracted
496 field can only be identified using an OID. In this case, the ``cookie`` could
498 field while the ``type`` field could be set to ``AUTH_PARAM_HASH``. A value of 0 for
546 A parameter described by ``auth_param_type_desc_t`` to verify an image could be
548 for loading the parent image will be reused for loading the child image. Hence
550 to have memory allocated for them separately where they can be stored. This
551 memory must be statically allocated by the platform port.
566 For parameters that can be obtained from the child image itself, the IPM is
571 parameters that should be extracted from it and used to verify the next image
597 parameters are specified only by authentication images and can be extracted
613 by the ``parent`` field. Those nodes with no parent must be authenticated using
627 The CoT can be found in ``drivers/auth/tbbr/tbbr_cot.c``. This CoT consists of an
629 ``REGISTER_COT(cot_desc)``, where 'cot\_desc' must be the name of the array
644 for a proper authentication. Details about the TBBR CoT may be found in the
648 identifiers for all the images and certificates that will be loaded during the
650 these identifiers can be obtained from ``include/common/tbbr/tbbr_img_def.h``.
673 is NULL, the authentication parameters will be obtained from the platform
677 be checked to consider an image authenticated. Each method consists of a
682 the method type, a different number of parameters must be specified.
686 from the parent image. The following parameter descriptors must be
689 - ``data``: data to be hashed (obtained from current image)
692 - ``AUTH_METHOD_SIG``: the image (usually a certificate) must be signed with
695 must be specified:
700 - ``data``: the data to be signed (obtained from current image)
703 must be extracted from an image once it has been authenticated. Each
712 process, some of the buffers may be reused at different stages during the boot.
715 be used to extract the parameter data from the corresponding image.
823 extensions. This must be specified in the image descriptor using the
829 four parameter descriptors must be specified with the authentication method:
836 (this key will be the ROTPK).
842 to extract the data to be signed from the certificate.
845 Trusted World public key needs to be extracted from the certificate. A new entry
847 the corresponding parameter descriptor must be specified along with the buffer
859 extension specified by ``bl31_content_pk``. This key will be copied to the
866 specified by ``bl31_hash``. This hash will be copied to the ``plat_bl31_hash_buf``
872 the reference hash, ``bl31_hash``, and the data to be hashed. In this case, it is
883 ARM platforms will use an x509v3 library based on mbed TLS. This library may be
900 The build system must be updated to include the corresponding library and
909 based on mbed TLS, which can be found in
932 be defined in the platform Makefile. It will make mbed TLS use an implementation