ARM Trusted Firmware-auth Framework

Term

Cot-chain of Trusted

Rotpk-root of Trusted public Key

Tf-trusted Firmware

Cm-crypto Module

Am-auth Module

Ipm-image Parser Module

Ipl-image Parser Libraries

Scp-specific Platform

Fip-fireware Image Package

1. Introduction

The purpose of this article is to describe the Authertication framework implemented in trusted firmware. This framework meets the requirements of providing platform support for chain's trust implementation, providing a mechanism framework for validating specific mirrors and certificates, and providing mechanisms for encoding and transmitting information, such as DER-encoded X.509v3 certificates, which can contain public keys, hashes, and nonvolatile counts A mechanism for verifying the transmission of information, such as an encrypted library

The framework is implemented according to the module, the module frame diagram, as follows

This document describes the internal details of the authentication framework and constructs an cot abstract mechanism.
2 Framework Design

This section describes some aspects of the framework design, as well as the basic theories of these designs. These are the key to verifying cot.
2.1 Chain of trust

A cot is a series of authenticated mirrors, usually starting with a trusted root and finally reaching a data mirror.
2.2 Image Types

The mirrors on the cot are divided into certified mirrors and data mirroring. A certified mirror contains information that authenticates other authenticated mirrors or data mirrors. A data mirror is usually a bootloader binary file, or any other data that needs to be authenticated.
2.3 Component Responsibility

For a mirror on the cot, you typically do the following: Allocate mirrored memory, dynamic or static. The mirror is found and loaded into the allocated memory. According to the type of mirror, check the integrity of the mirror to verify the mirror using the specified encryption algorithm. If the mirror is a certified mirror, extract the information from the mirror so that it can be used to authenticate the next mirror image in the cot chain.
2.3.1 TF Generic Code and IO framework

Tf-trusted Firmware

This part of the component is responsible for initializing the mirroring authentication process in BL1 or BL2. For each BL image that requires authentication, the generic code loops through the parent mirror's authentication module, until an authenticated mirror or root of Trusted is called. Finally, the generic code calls the IO framework to load the mirror and then invokes the authentication module authentication mirror, from the rot down the cot to the mirror.
2.3.2 TF Platform Port (PP)

This framework is responsible for specifying the cot that each mirror needs to be authenticated, and how this framework determines that cot will explain later. The framework also specifies the authentication method and the mirroring resolution method. The memory is statically allocated for each parameter in each mirror, which is used to validate cot, such as allocating memory for the public key or hashes. Provides additional information to IPM for ROTPK or ROTPK hash values that enable IPM to identify and extract the authentication parameters contained in the mirror. If the parameter is stored in X509v3, then the corresponding OID must be supplied to satisfy the memory allocation requirements of IPM and CM modules if the authentication method used by a mirror cannot be interpreted by cm, then PP can provide a custom function to validate the image. For example, if a mirror is to be validated using the NV counter, then the comparison process for this value can only be provided by the platform.
If you use a proprietary mirror format, provide a custom IPM,
2.3.3 Authentication Module (AM)

Responsible for the following work: provide the necessary abstract mechanism to describe cot. Among them, cot authentication and mirror resolution methods must be specified in pp. Using the functions provided by PP, IPM, and CM, verify that the cot records which Mirror has been validated, such as a mirror contained in more than one cot, it only needs to be validated once. For example, Trusted World key certificate. This certificate contains information that validates SCP_BL2, BL31, BL32, and is part of a different cot chain. Reusing memory
2.3.4 Cryptographic Module (CM)

CM is responsible for providing such as the System API: Verifying the digital signature verification hash

CM does not include any encryption-related code, but it relies on external libraries to perform the decryption operation. A cryptographic library is linked to the CM module, and CL must provide the following function

void (*init) (void);
Int (*verify_signature) (void *data_ptr, unsigned int data_len,
                        void *sig_ptr, unsigned int sig_len,
                        void *sig_ ALG, unsigned int sig_alg_len,
                        void *pk_ptr, unsigned int pk_len);
Int (*verify_hash) (void *data_ptr, unsigned int data_len,
                   void *digest_info_ptr, unsigned int digest_info_len);

These functions are registered with the following macros to CM

Register_crypto_lib (_name, _init, _verify_signature, _verify_hash);

2.3.5 Image Parser Module (IPM)

IPM is responsible for checking the integrity of mirrored mirrors that are loaded by the IO framework. Extracts the parameters used by the validation mirror, which is based on the description in the cot descriptor.

Mirrors can have different formats, for example, a certified image can be a x509v3 certificate, a signed Elf file, or another platform-specific format. IPM allows you to define an Image parser library (IPL) for each format used in cot.

IPL must implement a specific method to parse the mirror. IPM obtains the mirror format from the cot and then invokes the correct IPL to check the integrity of the mirror and extract the authentication parameters

2.4 Authentication Methods

AM supports the following authentication methods: Hash Digital Signature

If you use custom cot, the platform can specify these methods in cot.

If data mirroring uses multiple methods, then all methods must be in the same cot. The number and type of parameters are method-specific. These parameters can be obtained from the parent image through IPM.

Hash:

parameter to do hash data pointer data length hash pointer hash length

Hash uses the DER encoding method:

Digestinfo:: = SEQUENCE {
    digestalgorithm  digestalgorithmidentifier,
    Digest           Digest
}

Digital signatures

Parameters: Data pointers to sign data length public key algorithm public key value digital Signature Algorithm digital signature value

Public key parameters are represented using the DER encoding method

Subjectpublickeyinfo  :: =  SEQUENCE  {
    algorithm         algorithmidentifier{public-key,{ PUBLICKEYALGORITHMS}},
    subjectpublickey  BIT STRING  }

The digital Signature algorithm uses the DER encoding method to express

Algorithmidentifier {Algorithm:ioset}:: = SEQUENCE {
    algorithm         algorithm.&id ({ioset}),
    parameters        Algorithm.&type ({ioset}{@algorithm}) OPTIONAL
}

The authentication framework uses mirror descriptors to extract information that is known to be authentication-related.

3. Specifying a chain of trust

CoT is a set of mirror descriptors that are linked in a specific order. The order of the links determines the order of validation. Each mirror has a set of properties that allow am to validate it. These properties are described below.

PP is responsible for defining one or more cots for a data mirror. Unless specifically stated, the data structure described in the following section is statically defined in pp.
3.1 Describing the image parsing methods

The mirroring resolution method corresponds to the mirrored format. For example, an authenticated mirror representing a certificate is a X.509v3 format. Data mirroring on behalf of bootloader should be raw binary or elf format. IPM supports the resolution of the above three types of mirrors. A mirror describes three methods using the following description. An IPL is responsible for an analytic method, each interpretation method of the platform should correspond to an IPL RAW format: The image of this format is treated as a raw binary format mirror, such as the bootloader mirror used by arm TF. This method is used only on data mirroring. X509v3 method: This method uses industry standard X509 to represent PKI certificates. You can use open Source Library functions To resolve mirroring of this method definition. Platform-specific methods: This approach is to meet the platform-specific standard definition of authentication or data mirroring. For example, a data-mirroring signature can be appended to the raw binary data mirror. A header is added to the merged mirror before the header is used to describe the length of each part. For this image, the platform must implement a corresponding IPL to interpret this format.

The following enumeration is used to define these three methods

typedef enum IMG_TYPE_ENUM {
    Img_raw,/            * Binary image/
    Img_plat,/           * Platform specific format * *
    Img_cert,           /* X509v3 certificate * *
    img_max_types,
} img_type_t;

A IPL must provide the following function prototypes

void init (void);
int check_integrity (void *img, unsigned int img_len);
int Get_auth_param (const auth_param_type_desc_t *TYPE_DESC,
                      void *img, unsigned int img_len,
                      void **param, unsigned int *param_len);

The IPL corresponding to each type is registered with the following macro

Register_img_parser_lib (_type, _name, _init, _check_int, _get_param)

A type in the _type:img_type_t
_name: A string containing the IPL name, for debugging purposes
_init: Initializing function pointers
_check_int: Check mirror integrity function pointers
_get_auth_param: Extract the authentication parameter function pointer

_init function to initialize IPL

The parameters of the Check_int function include the memory address of the mirrored load, and the mirror length. This function ensures that the loaded mirrors conform to the appropriate format. For example, RFC-2459 defines a valid sequence of X.509 certificates

The parameter-parameter descriptor of the Get_auth_param function contains the information of the parameter and is used to extract the data from a mirror. This data is used to validate the current or next mirror image in the cot sequence.

The mirrors in each cot should identify the parsing method used. IPM uses this information to find the correct parser descriptor.
3.2 Describing the authentication methods

In cot, each mirror should identify one or more authentication methods to authenticate the mirror itself. As described in the Authenticaion methods section, am supports three of methods.

typedef enum {
    Auth_method_none,
    Auth_method_hash,
    auth_method_sig,
    auth_method_num
} auth_ method_type_t;

AM defines each parameter type used by the authentication method. By using this information: Specify in the Get_auth_parm () function call, which parameter is extracted from the mirror
When you call the CM and PP validation functions, the correct serialization parameter extracts the authentication parameters from the parent mirror to verify the child mirroring: for example, when validating a certificate image, you must obtain the public key from its parent mirror.

typedef enum {
    Auth_param_none,
    auth_param_raw_data,/        * RAW Image DATA */
    Auth_param_sig,         /* the Image Signature */
    AUTH_PARAM_SIG_ALG,/     * The image Signature Algorithm/
    Auth_param_hash,/        * A Hash (including the algorithm) * *
    Auth_param_pub_key,/     * A Public KEY * * *
auth_param_type_t;

AM defines the following data structure to identify the authentication parameters required to authenticate the mirror.

typedef struct AUTH_PARAM_TYPE_DESC_S {
    auth_param_type_t type;
    void *cookie;
} auth_param_type_desc_t;

The platform uses cookies to identify additional information to IPM, which makes it possible to uniquely identify the parameters extracted from the mirror. For example, for the corresponding content certificate hash value in the bl3x mirror, it is stored in a customizable extended domain of x509v3. Customizable extension domains need to be used to identify. In this case, the cookie contains a pointer to the OID, and the type is set to Auth_param_hash. A cookie value of 0 indicates that the member is not in use.

For each method, am defines the structure that contains the parameters required to validate the mirror:

 * * Parameters for authentication by hash matching * *
typedef struct AUTH_METHOD_PARAM_HASH_S {
    auth_ param_type_desc_t *data;   /* Data to Hash * *
    auth_param_type_desc_t *hash;   * * Hash to match with *
/} auth_method_param_hash_t;
 * * Parameters for authentication by signature
 /
typedef struct AUTH_METHOD_PARAM_SIG_S {
    auth_ param_type_desc_t *PK; /* Public key *
    /auth_param_type_desc_t *sig;    /* Signature to check *
    /auth_param_type_desc_t *alg;    /* Signature Algorithm * *
    auth_param_type_desc_t *tbs;    /* Data signed *
/} auth_method_param_sig_t;

AM defines the following structure to describe the authentication method used to verify mirroring.

 * * Authentication method Descriptor
 /
typedef struct AUTH_METHOD_DESC_S {
    auth_method_type_t type;
    Union {
        auth_method_param_hash_t hash;
        auth_method_param_sig_t Sig;
    param;
} auth_method_desc_t;

By method type Type,am knows how to access param union members

3.3 Storing authentication parameters

The parameters described by auth_param_type_desc_t are used to validate mirrors, either from the mirror itself or from the parent mirror. The memory allocated by loading the parent mirror can be loaded by a quilt image. Therefore, the memory is allocated for parameters obtained from the parent mirror, so that subsequent validation of the child mirroring is used. This memory is statically allocated from the platform port.

AM defines the following data structures to store authentication parameters

typedef struct AUTH_PARAM_DATA_DESC_S {
    void *auth_param_ptr;
    unsigned int auth_param_len;
} auth_param_data_desc_t;

AUTH_PARAM_PTR members are platform-initialized and Auth_param_len are used to define the length of data in memory.

For parameters that can be obtained from a child mirror, IPM is responsible for storing auth_param_ptr and Auth_param_len members when executing the Img_get_auth_param () function.

AM defines the following structure that describes the parameters extracted from the mirror, which can be used to verify the cot on the chain.

typedef struct AUTH_PARAM_DESC_S {
    auth_param_type_desc_t type_desc;
    auth_param_data_desc_t data;
} auth_param_desc_t;

3.4 Describing an image in a CoT

Mirroring within a cot includes the following aspects: a unique identifier through which the IO framework can locate the mirror location in FIP and load it into the memory space reserved for cot data mirroring. An analytic method by which the corresponding IPM authentication method and their parameters can be found, which are used to verify the current mirror image. The parameter used to verify the next mirror image in the current cot. These parameters are only stored in the authentication mirror, and once the mirror is authenticated, these parameters can be extracted from the current mirror.

The following data structure can be used to describe a mirror in cot.

typedef struct AUTH_IMG_DESC_S {
    unsigned int img_id;
    const struct auth_img_desc_s *parent;
    img_type_t Img_type;
    auth_method_desc_t Img_auth_methods[auth_method_num];
    auth_param_desc_t authenticated_data[cot_max_verified_params];
} auth_img_desc_t;

A cot is defined as a set of auth_image_desc_t structures, linked by parent members. Mirrors that do not have a parent node must have been ROTPK validated.
4 Implementation Example

This section describes in detail a trusted startup implementation that uses the authentication framework. This example corresponds to the applicative functional Mode of the tbbr-client document. It is recommended that you read this document as you read the code.
4.1 The Tbbr CoR

Cot in drivers/auth/tbbr/tbbr_cot.c. This cot contains the mirror descriptor queue, cot is registered with the authentication framework through Register_cot macros. Cot_desc must be the name of the queue.

The number of mirrors participating in the boot process depends on the cot. Of course Trusted firmware forces a minimum mirror set, and all cots must contain these mirrors.

Generally, cot contains the following mirrors BL2 scp_bl2 BL31 BL32 BL33

In addition to these mirrors, the TBBR also identifies the additional certificates required to achieve proper authentication. For details about Tbbr Cot, refer to the Trusted Board boot documentation

According to platform porting Guide, a platform must provide unique identifiers for all mirrors and certificates in order to load them during startup. If a platform uses TBBR as a reference for a trusted startup, you can get those identifiers from the include/common/tbbr/tbbr_img_def.h. Other platforms can contain this file, or define their own identifiers.

Important: The authentication module uses these identifiers to index the members of the cot array, so the Arrary descriptor position must match the identifier ID

Each mirror descriptor must include: img_id: Mirroring the corresponding platform unique descriptor
Img_type: Mirror-resolution module uses mirror type to determine which parsing library to use: Check mirror integrity, extract required authentication parameters, currently supports three types of mirrors: Img_raw: Mirror is RAW binary. There are no analytic functions except for reading mirrors
Img_plat: The mirrored format is platform-specific. The platform can use this type to customize mirroring without the need for direct support from the certification framework.
Img_cert: Mirroring is a X.509v3 certificate. Parent: Point to the parent mirror descriptor, which contains the information required to authenticate the current mirror. If the parent descriptor is empty, obtain the authentication parameters from the platform (for example, the BL2 and trusted key certificates are signed with the Rot Private key, ROTPK on the platform) Img_auth_methods: An array, The authentication method to be performed by the authentication mirror is defined in the array. Each authentication method contains a type and a parameter description Fu Chinqu. Parameter descriptors contain types and cookies (cookies point to a specific information used to extract parameters from a mirror, such as when the parameter is stored in a x509v3 extension, the cookie points to the extended OID), and the number of parameters depends on the type of validation method. The following authentication methods are supported: Auth_method_hash: The mirrored hash must match the hash value extracted from the parent mirror. The following argument descriptors must be included:
4.1.1 Example:the BL31 chain of trust 4.2 The Image parser library 4.3 The cryptographic library