Lines Matching refs:an
149 #. If the image is an authentication image, extract the information that will
161 image until either an authenticated image or the ROT is reached. Then the
181 extract authentication parameters contained in an image, e.g. if the
188 #. Export functions to verify an image which uses an authentication method that
189 cannot be interpreted by the CM, e.g. if an image has to be verified using a
208 #. Tracking which images have been verified. In case an image is a part of
220 certificate. It is assumed that the size of an authentication image will
227 The CM is responsible for providing an API to:
232 The CM does not include any cryptography related code, but it relies on an
262 #. Extracting parameters used for authenticating an image based upon a
267 The IPM allows to register an Image Parser Library (IPL) for every image format
368 The parsing method refers to the format of a particular image. For example, an
376 #. Raw format: This format is effectively a nop as an image using this method
382 libraries will be available which can be used to parse an image represented
431 been tampered with. For example, RFC-2459 describes a validation sequence for an
436 extract the data corresponding to that parameter from an image. This data will
458 The AM defines the type of each parameter used by an authentication method. It
462 parameter should be extracted from an image.
482 The AM defines the following structure to identify an authentication parameter
483 required to verify an image.
494 from an image. For example, the hash of a BL3x image in its corresponding
495 content certificate is stored in an X509v3 custom extension field. An extension
496 field can only be identified using an OID. In this case, the ``cookie`` could
524 The AM defines the following structure to describe an authentication method for
525 verifying an image
546 A parameter described by ``auth_param_type_desc_t`` to verify an image could be
553 The AM defines the following structure to store the data corresponding to an
570 The AM defines the following structure to enable an image to describe the
581 Describing an image in a CoT
600 The following data structure describes an image in a CoT.
612 A CoT is defined as an array of ``auth_image_desc_t`` structures linked together
627 The CoT can be found in ``drivers/auth/tbbr/tbbr_cot.c``. This CoT consists of an
669 - ``IMG_CERT``: image is an x509v3 certificate.
677 be checked to consider an image authenticated. Each method consists of a
680 extract that parameter from the image (i.e. if the parameter is stored in an
703 must be extracted from an image once it has been authenticated. Each
710 are hashes and public keys. In DER format, an RSA-2048 public key requires 294
832 is used to extract a public key from the parent image. If the cookie is an
849 is used to extract the public key from an x509v3 extension with OID
881 only an x509v3 library is required for the TBBR CoT.
883 ARM platforms will use an x509v3 library based on mbed TLS. This library may be
897 an image of type ``IMG_CERT``, it will call the corresponding function exported
932 be defined in the platform Makefile. It will make mbed TLS use an implementation