引流關鍵詞: 中斷、同步異常、異步異常、irq、fiq、BL1,BL2,BL3,BL31,BL32,BL33,AP_BL1,AP_BL2,AP_BL3,AP_BL31,AP_BL32,AP_BL33,SCP_BL1,SCP_BL2,BL0,BL30, optee、ATF、TF-A、Trustzone、optee3.14、MMU、VMSA、cache、TLB、arm、armv8、armv9、TEE、安全、內存管理、頁表…

快速鏈接:
.
👉👉👉 個人博客筆記導讀目錄(全部) 👈👈👈


[專欄目錄]-ATF/FF-A/specification學習

2.身份驗證框架和信任鏈

本文檔的目的是描述在可信固件-A (TF-A) 中實現的身份驗證框架。該框架滿足以下要求：

(1) 平臺端口應該可以根據證書層次結構和用于驗證特定圖像/證書的機制來指定信任鏈。

(2) 該框架應區分：

• 用于編碼和傳輸信息的機制，例如 DER 編碼的 X.509v3 證書以傳送主題公鑰、散列和非易失性計數器。

• 用于驗證傳輸信息的機制，即密碼庫。

該框架是按照下圖所示的模塊化方法設計的：

+---------------+---------------+------------+ | Trusted | Trusted | Trusted | | Firmware | Firmware | Firmware | | Generic | IO Framework | Platform | | Code i.e. | (IO) | Port | | BL1/BL2 (GEN) | | (PP) | +---------------+---------------+------------+^ ^ ^| | |v v v+-----------+ +-----------+ +-----------+| | | | | Image || Crypto | | Auth | | Parser || Module |<->| Module |<->| Module || (CM) | | (AM) | | (IPM) || | | | | |+-----------+ +-----------+ +-----------+^ ^| |v v +----------------+ +-----------------+ | Cryptographic | | Image Parser | | Libraries (CL) | | Libraries (IPL) | +----------------+ +-----------------+| || || |v v+-----------------+| Misc. Libs e.g. || ASN.1 decoder || |+-----------------+DIAGRAM 1.

本文檔描述了身份驗證框架的內部細節以及可用于指定信任鏈的抽象機制。

2.1。框架設計

本節描述了框架設計的某些方面及其背后的基本原理。這些方面是驗證信任鏈的關鍵。

2.1.1。信任鏈?

CoT 基本上是一系列身份驗證圖像，通常以信任根開始，最終形成單個數據圖像。下圖說明了它如何映射到 TBBR-Client 規范中描述的 BL31 映像的 CoT 。

+------------------+ +-------------------+ | ROTPK/ROTPK Hash |------>| Trusted Key | +------------------+ | Certificate || (Auth Image) |/+-------------------+/ |/ |/ |/ |L v +------------------+ +-------------------+ | Trusted World |------>| BL31 Key | | Public Key | | Certificate | +------------------+ | (Auth Image) |+-------------------+/ |/ |/ |/ |/ v +------------------+ L +-------------------+ | BL31 Content |------>| BL31 Content | | Certificate PK | | Certificate | +------------------+ | (Auth Image) |+-------------------+/ |/ |/ |/ |/ v +------------------+ L +-------------------+ | BL31 Hash |------>| BL31 Image | | | | (Data Image) | +------------------+ | |+-------------------+DIAGRAM 2.

信任根通常是已經在平臺中燒毀且無法修改的公鑰（ROTPK）。

2.1.2. 鏡像類型?

CoT 中的圖像分為認證圖像和數據圖像。認證圖像包含用于認證數據圖像或另一個認證圖像的信息。數據映像通常是引導加載程序二進制文件，但也可以是任何其他需要身份驗證的數據。

2.1.3。組件職責?

對于信任鏈中的每個圖像，執行以下高級操作來驗證它：

• （1）靜態或在運行時為圖像分配內存。

• （2）識別圖像并將其加載到分配的內存中。

• （3）根據圖像類型檢查圖像的完整性。

• （4）根據使用的加密算法對圖像進行身份驗證。

• （5）如果圖像是驗證圖像，則提取將用于驗證 CoT 中的下一個圖像的信息。

在圖 1 中，每個組件負責一個或多個這些操作。下面簡要介紹一下職責。

2.1.3.1。TF-A 通用代碼和 IO 框架（GEN/IO）

這些組件負責為 BL1 或 BL2 中的特定圖像啟動身份驗證過程。對于每個需要身份驗證的 BL 圖像，通用代碼會遞歸地詢問身份驗證模塊父圖像是什么，直到達到經過身份驗證的圖像或 ROT。然后Generic代碼調用IO框架加載鏡像并調用Authentication模塊對其進行認證，跟隨CoT從ROT到Image。

2.1.3.2。TF-A 平臺端口 (PP)

該平臺負責：

• （1）為需要驗證的每個圖像指定 CoT。稍后將解釋平臺如何指定 CoT 的詳細信息。該平臺還指定了用于每個圖像的身份驗證方法和解析方法。

• （2）為每個圖像中的每個參數靜態分配內存，用于驗證 CoT，例如用于公鑰、哈希等的內存。

• （3）提供 ROTPK 或它的散列。

• （4）向 IPM 提供附加信息以使其能夠識別和提取圖像中包含的身份驗證參數，例如，如果參數存儲為 X509v3 擴展，則必須提供相應的 OID。

• （5）滿足 IPM 和 CM 的任何其他內存要求（本文檔中當前未描述）。

• （6）導出函數來驗證使用 CM 無法解釋的身份驗證方法的圖像，例如，如果必須使用 NV 計數器驗證圖像，則要與之比較的計數器的值只能由平臺提供。

• （7）如果正在使用專有圖像格式（稍后描述），則導出自定義 IPM。

2.1.3.3。認證模塊 (AM)

它負責：

• （1）提供必要的抽象機制來描述 CoT。其中，身份驗證和圖像解析方法必須由 CoT 中的 PP 指定。

• （2）利用 PP、IPM 和 CM 導出的功能驗證 GEN 通過的 CoT。

• （3）跟蹤哪些圖像已經過驗證。如果一個圖像是多個 CoT 的一部分，那么它應該只驗證一次，例如 TBBR-Client 規范中的可信世界密鑰證書。包含驗證 SCP_BL2、BL31、BL32 的信息，每個都有單獨的 CoT。（這個責任沒有在本文檔中描述，但應該很容易實現）。

• （4）重用用于數據圖像的內存來驗證認證圖像，例如在圖 2 中描述的 CoT 中，每個證書都可以在平臺為 BL31 圖像保留的內存中加載和驗證。到加載 BL31（數據圖像）時，所有驗證它的信息都將從父圖像（即 BL31 內容證書）中提取出來。假設認證圖像的大小永遠不會超過數據圖像的大小。應該可以在構建時使用斷言來驗證這一點。

2.1.3.4。密碼模塊 (CM)?

CM 負責提供 API 以：

• （1）驗證數字簽名。

• （2）驗證哈希。

CM 不包含任何與加密相關的代碼，但它依賴于外部庫來執行加密操作。必須實現鏈接 CM 和外部庫的加密庫 (CL)。CL必須提供以下功能：

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);

這些函數使用宏在 CM 中注冊：

REGISTER_CRYPTO_LIB(_name, _init, _verify_signature, _verify_hash);

_name必須是包含 CL 名稱的字符串。此名稱用于調試目的。

2.1.3.5。圖像解析器模塊 (IPM)?

IPM 負責：

• （1）檢查 IO 框架加載的每個圖像的完整性。

• （2）根據平臺在 CoT 描述符中提供的描述提取用于驗證圖像的參數。

圖像可能有不同的格式（例如，身份驗證圖像可以是 x509v3 證書、簽名的 ELF 文件或任何其他特定于平臺的格式）。IPM 允許為 CoT 中使用的每種圖像格式注冊一個圖像解析器庫 (IPL)。這個庫必須實現特定的方法來解析圖像。IPM 從 CoT 獲取圖像格式并調用正確的 IPL 來檢查圖像完整性并提取認證參數。

有關 IPM 提供的用于定義和注冊 IPL 的機制的更多詳細信息，請參閱“描述圖像解析方法”部分。

2.1.4。身份驗證方法?

AM 支持以下認證方式：

• （1）哈希

• （2）電子簽名

平臺可以在 CoT 中指定這些方法，以防它決定定義自定義 CoT 而不是重用預定義的 CoT。

如果一個數據圖像使用多種方法，那么所有方法必須是同一個 CoT 的一部分。參數的數量和類型是特定于方法的。這些參數應使用 IPM 從父圖像中獲取。

• （1）哈希

參數：

• 指向要散列的數據的指針

• 數據長度

• 指向哈希的指針

• 哈希的長度

哈希將由以下 ASN.1 類型的 DER 編碼表示：

DigestInfo ::= SEQUENCE {digestAlgorithm DigestAlgorithmIdentifier,digest Digest }

這種 ASN.1 結構可以消除任何關于散列算法類型的假設，因為此信息伴隨散列。這應該允許密碼庫 (CL) 支持多種散列算法實現。

• （2）電子簽名

參數：

• 指向要簽名的數據的指針

• 數據長度

• 公鑰算法

• 公鑰值

• 數字簽名算法

• 數字簽名值

公鑰參數將由以下 ASN.1 類型的 DER 編碼表示：

SubjectPublicKeyInfo ::= SEQUENCE {algorithm AlgorithmIdentifier{PUBLIC-KEY,{PublicKeyAlgorithms}},subjectPublicKey BIT STRING }

數字簽名算法將由以下 ASN.1 類型的 DER 編碼表示。

AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {algorithm ALGORITHM.&id({IOSet}),parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL }

數字簽名將由以下形式表示：

signature ::= BIT STRING

身份驗證框架將使用圖像描述符來提取與身份驗證相關的所有信息。

2.2. 指定信任鏈

CoT 可以描述為以特定順序鏈接在一起的一組圖像描述符。順序決定了它們必須被驗證的順序。每個圖像都有一組屬性，允許 AM 對其進行驗證。這些屬性如下所述。

PP 負責為數據圖像定義單個或多個 CoT。除非另有說明，以下部分中描述的數據結構由 PP 靜態填充。

2.2.1。描述圖像解析方法?

解析方法是指特定圖像的格式。例如，代表證書的身份驗證圖像可以是 X.509v3 格式。表示引導加載程序階段的數據映像可以是原始二進制或 ELF 格式。IPM 支持三種解析方法。圖像必須使用下面描述的三種方法之一。IPL 負責解釋單個解析方法。平臺使用的每種方法都必須有一個 IPL。

• （1）原始格式：此格式實際上是 nop，因為使用此方法的圖像被視為原始二進制格式，例如 TF-A 使用的引導加載程序圖像。此方法應僅用于數據圖像。

• （2）X509V3 方法：此方法使用 X.509 等行業標準來表示 PKI 證書（身份驗證圖像）。預計將提供可用于解析此方法表示的圖像的開源庫。此類庫可用于編寫相應的 IPL，例如 mbed TLS 中的 X.509 解析庫代碼。

• （3）平臺定義方法：此方法滿足平臺特定的專有標準來表示身份驗證或數據圖像。例如，數據圖像的簽名可以附加到數據圖像原始二進制文件中。可以將標頭附加到組合的 blob 以指定每個組件的范圍。平臺必須實現相應的 IPL 來解釋這種格式。

以下枚舉可用于定義這三種方法。

typedef enum img_type_enum {IMG_RAW, /* Binary image */IMG_PLAT, /* Platform specific format */IMG_CERT, /* X509v3 certificate */IMG_MAX_TYPES, } img_type_t;

IPL 必須提供具有以下原型的函數：

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);

必須使用以下宏注冊每種類型的 IPL：

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

• _type: 上述類型之一。

• _name：包含用于調試目的的 IPL 名稱的字符串。

• _init：初始化函數指針。

• _check_int：檢查圖像完整性函數指針。

• _get_param: 提取認證參數函數指針。

該init()函數將用于初始化 IPL。

該check_integrity()函數傳遞一個指針，該指針指向 IO 框架已加載圖像的內存和圖像長度。應該保證圖片是解析方式對應的格式，沒有被篡改過。例如，RFC-2459 描述了 X.509 證書的驗證序列。

該get_auth_param()函數被傳遞一個參數描述符，其中包含有關參數 (type_desc和cookie) 的信息，以從圖像中識別和提取與該參數對應的數據。此數據將用于驗證 CoT 序列中的當前或下一個圖像。

CoT 中的每個圖像都將指定它使用的解析方法。IPM 將使用此信息來查找圖像的正確解析器描述符。

2.2.2。描述身份驗證方法?

作為 CoT 的一部分，每個圖像都必須指定一種或多種身份驗證方法，用于對其進行驗證。如“身份驗證方法”部分所述，AM 支持三種方法。

typedef enum {AUTH_METHOD_NONE,AUTH_METHOD_HASH,AUTH_METHOD_SIG,AUTH_METHOD_NUM } auth_method_type_t;

AM 定義了身份驗證方法使用的每個參數的類型。它使用這些信息來：

指定get_auth_param()IPM 導出的函數，應從圖像中提取哪個參數。

調用CM和PP導出的校驗函數時，正確編組參數。

從父圖像中提取身份驗證參數以驗證子圖像，例如為了驗證證書圖像，必須從父圖像中獲取公鑰。

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 定義了以下結構來識別驗證圖像所需的身份驗證參數。

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

cookie平臺使用它來為 IPM 指定附加信息，使其能夠唯一標識應從??圖像中提取的參數。例如，BL3x 圖像在其相應內容證書中的哈希存儲在 X509v3 自定義擴展字段中。擴展字段只能使用 OID 來標識。在這種情況下，cookie可以包含指向平臺為散列擴展字段定義的 OID 的指針，而該type字段可以設置為AUTH_PARAM_HASH。該字段的值為 0cookie表示未使用該字段。

對于每種方法，AM 都定義了一個結構，其中包含驗證圖像所需的參數。

/** 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 定義了以下結構來描述驗證圖像的身份驗證方法/** 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;

使用type字段中指定的方法類型，AM 找出param聯合內需要訪問的字段。

2.2.3。存儲認證參數

用于驗證圖像的參數auth_param_type_desc_t可以從圖像本身或其父圖像中獲得。為加載父圖像分配的內存將被重新用于加載子圖像。因此，從父級獲得的用于驗證子圖像的參數需要為它們單獨分配內存，以便存儲它們。此內存必須由平臺端口靜態分配。

AM 定義了以下結構來存儲與認證參數對應的數據。

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

該auth_param_ptr字段由平臺初始化。該auth_param_len 字段用于指定內存中數據的長度。

對于可以從子圖像本身獲取的參數，IPM 負責在執行函數時填充auth_param_ptr和字段。auth_param_lenimg_get_auth_param()

AM 定義了以下結構，以使圖像能夠描述應從中提取并用于驗證 CoT 中的下一個圖像（子圖像）的參數。

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

2.2.4。在 CoT 中描述圖像

CoT 中的圖像是上述 CoT 的以下方面的合并。

• （1）平臺指定的唯一標識符，允許 IO 框架在 FIP 中定位圖像并將其加載到為 CoT 中的數據圖像保留的內存中。

• （2）AM 使用的一種解析方法來查找適當的 IPM。

• （3）上一節中描述的身份驗證方法及其參數。這些用于驗證當前圖像。

• （4）用于驗證當前 CoT 中的下一個圖像的參數。這些參數僅由身份驗證圖像指定，一旦經過驗證，就可以從當前圖像中提取。

以下數據結構描述了 CoT 中的圖像。

typedef struct auth_img_desc_s {unsigned int img_id;const struct auth_img_desc_s *parent;img_type_t img_type;const auth_method_desc_t *const img_auth_methods;const auth_param_desc_t *const authenticated_data; } auth_img_desc_t;

CoT 定義為指向由字段auth_image_desc_t鏈接在一起的結構的指針數組。parent那些沒有父節點的節點必須使用存儲在平臺中的 ROTPK 進行身份驗證。

2.3. 實現示例

本節是詳細指南，解釋使用身份驗證框架的可信引導實現。此示例對應于 TBBR-Client 文檔中指定的應用功能模式 (AFM)。建議與源代碼一起閱讀本指南。

2.3.1。TBBR CoT

BL1 和 BL2 特有的 CoT 可以分別在drivers/auth/tbbr/tbbr_cot_bl1.c 和中找到drivers/auth/tbbr/tbbr_cot_bl2.c。在 BL1 和 BL2 中使用的通用 CoT 可以在drivers/auth/tbbr/tbbr_cot_common.c. 這個 CoT 由一組指向圖像描述符的指針組成，并使用宏在框架中注冊REGISTER_COT(cot_desc)，其中 cot_desc必須是數組的名稱（傳遞指針或任何其他類型的間接將導致注冊過程失敗）。

參與引導過程的映像數量取決于 CoT。然而，在 TF-A 中有一組最少的圖像是強制性的，因此所有 CoT 都必須呈現：

• BL2

• SCP_BL2（特定于平臺）

• BL31

• BL32（可選的）

• BL33

TBBR 指定了必須伴隨這些圖像以進行正確身份驗證的附加證書。有關 TBBR CoT 的詳細信息可在 Trusted Board Boot文檔中找到。

遵循移植指南，平臺必須為將在引導過程中加載的所有映像和證書提供唯一標識符。如果平臺使用 TBBR 作為可信引導的參考，則這些標識符可以從include/common/tbbr/tbbr_img_def.h. Arm 平臺將此文件包含在include/plat/arm/common/arm_def.h. 其他平臺也可能包含此文件或提供自己的標識符。

重要提示：身份驗證模塊使用這些標識符來索引 CoT 數組，因此數組中的描述符位置必須與標識符匹配。

每個圖像描述符必須指定：

• img_id：平臺定義的對應圖片唯一標識。

• img_type：圖像解析器模塊使用圖像類型調用正確的解析庫來檢查圖像完整性并提取所需的認證參數。目前支持三種類型的圖像：
  – IMG_RAW：圖像是原始二進制文件。除了讀取整個圖像之外，沒有可用的解析功能。
  – IMG_PLAT：圖像格式是特定于平臺的。平臺可以將此類型用于身份驗證框架不直接支持的自定義圖像。
  – IMG_CERT：圖像是 x509v3 證書。

• parent: 指向父圖像描述符的指針。父級將包含驗證當前圖像所需的信息。如果 parent 為 NULL，則從平臺獲取認證參數（即 BL2 和 Trusted Key 證書使用 ROT 私鑰簽名，其公共部分存儲在平臺中）。

• img_auth_methods：這指向一個數組，該數組定義了必須檢查的身份驗證方法以認為圖像已通過身份驗證。每個方法都包含一個類型和一個參數描述符列表。參數描述符由類型和cookie 組成，cookie 將指向從圖像中提取該參數所需的特定信息（即，如果參數存儲在x509v3 擴展中，cookie 將指向擴展OID）。根據方法類型，必須指定不同數量的參數。該指針不應為 NULL。支持的方法有：
  – AUTH_METHOD_HASH：圖像的哈希必須與從父圖像中提取的哈希匹配。必須指定以下參數描述符：
  ----- data：要散列的數據（從當前圖像中獲取）
  ----- hash：參考哈希（從父圖像獲得）
  – AUTH_METHOD_SIG: 圖像（通常是證書）必須使用其公共部分從父圖像（如果父圖像為 NULL 則為平臺）提取的私鑰簽名。必須指定以下參數描述符：
  ----- pk: 公鑰（從父鏡像中獲取）
  ----- sig：數字簽名（從當前圖像中獲得）
  ----- alg：使用的簽名算法（從當前圖像中獲得）
  ----- data：要簽名的數據（從當前圖像中獲取）

• authenticated_data：此數組指針指示一旦圖像經過身份驗證，必須從圖像中提取哪些身份驗證參數。每個參數由一個參數描述符和用于存儲參數的緩沖區地址/大小組成。CoT 負責分配所需的內存來存儲參數。該指針可能為 NULL。

在該tbbr_cot*.c文件中，分配了一組緩沖區來存儲從證書中提取的參數。在 TBBR CoT 的情況下，這些參數是散列和公鑰。在 DER 格式中，一個 RSA-4096 公鑰需要 550 個字節，而散列需要 51 個字節。根據 CoT 和身份驗證過程，一些緩沖區可能會在引導期間的不同階段重復使用。

接下來在該文件中，定義參數描述符。這些描述符將用于從相應的圖像中提取參數數據。

2.3.1.1。示例：BL31 信任鏈?

四個圖像描述符構成了 BL31 信任鏈：

static const auth_img_desc_t trusted_key_cert = {.img_id = TRUSTED_KEY_CERT_ID,.img_type = IMG_CERT,.parent = NULL,.img_auth_methods = (const auth_method_desc_t[AUTH_METHOD_NUM]) {[0] = {.type = AUTH_METHOD_SIG,.param.sig = {.pk = &subject_pk,.sig = &sig,.alg = &sig_alg,.data = &raw_data}},[1] = {.type = AUTH_METHOD_NV_CTR,.param.nv_ctr = {.cert_nv_ctr = &trusted_nv_ctr,.plat_nv_ctr = &trusted_nv_ctr}}},.authenticated_data = (const auth_param_desc_t[COT_MAX_VERIFIED_PARAMS]) {[0] = {.type_desc = &trusted_world_pk,.data = {.ptr = (void *)trusted_world_pk_buf,.len = (unsigned int)PK_DER_LEN}},[1] = {.type_desc = &non_trusted_world_pk,.data = {.ptr = (void *)non_trusted_world_pk_buf,.len = (unsigned int)PK_DER_LEN}}} }; static const auth_img_desc_t soc_fw_key_cert = {.img_id = SOC_FW_KEY_CERT_ID,.img_type = IMG_CERT,.parent = &trusted_key_cert,.img_auth_methods = (const auth_method_desc_t[AUTH_METHOD_NUM]) {[0] = {.type = AUTH_METHOD_SIG,.param.sig = {.pk = &trusted_world_pk,.sig = &sig,.alg = &sig_alg,.data = &raw_data}},[1] = {.type = AUTH_METHOD_NV_CTR,.param.nv_ctr = {.cert_nv_ctr = &trusted_nv_ctr,.plat_nv_ctr = &trusted_nv_ctr}}},.authenticated_data = (const auth_param_desc_t[COT_MAX_VERIFIED_PARAMS]) {[0] = {.type_desc = &soc_fw_content_pk,.data = {.ptr = (void *)content_pk_buf,.len = (unsigned int)PK_DER_LEN}}} }; static const auth_img_desc_t soc_fw_content_cert = {.img_id = SOC_FW_CONTENT_CERT_ID,.img_type = IMG_CERT,.parent = &soc_fw_key_cert,.img_auth_methods = (const auth_method_desc_t[AUTH_METHOD_NUM]) {[0] = {.type = AUTH_METHOD_SIG,.param.sig = {.pk = &soc_fw_content_pk,.sig = &sig,.alg = &sig_alg,.data = &raw_data}},[1] = {.type = AUTH_METHOD_NV_CTR,.param.nv_ctr = {.cert_nv_ctr = &trusted_nv_ctr,.plat_nv_ctr = &trusted_nv_ctr}}},.authenticated_data = (const auth_param_desc_t[COT_MAX_VERIFIED_PARAMS]) {[0] = {.type_desc = &soc_fw_hash,.data = {.ptr = (void *)soc_fw_hash_buf,.len = (unsigned int)HASH_DER_LEN}},[1] = {.type_desc = &soc_fw_config_hash,.data = {.ptr = (void *)soc_fw_config_hash_buf,.len = (unsigned int)HASH_DER_LEN}}} }; static const auth_img_desc_t bl31_image = {.img_id = BL31_IMAGE_ID,.img_type = IMG_RAW,.parent = &soc_fw_content_cert,.img_auth_methods = (const auth_method_desc_t[AUTH_METHOD_NUM]) {[0] = {.type = AUTH_METHOD_HASH,.param.hash = {.data = &raw_data,.hash = &soc_fw_hash}}} };

Trusted Key 證書使用ROT 私鑰簽名，并包含 Trusted World 公鑰和 Non-Trusted World 公鑰作為 x509v3 擴展。這必須分別使用 img_auth_methods和authenticated_data數組在圖像描述符中指定。

可信密鑰證書通過使用 ROTPK 檢查其數字簽名來進行身份驗證。檢查簽名需要四個參數：公鑰、算法、簽名和已簽名的數據。因此，認證方法必須指定四個參數描述符：

• subject_pk: 類型的參數描述符AUTH_PARAM_PUB_KEY。此類型用于從父圖像中提取公鑰。如果 cookie 是 OID，則從相應的 x509v3 擴展中提取密鑰。如果 cookie 為 NULL，則檢索主題公鑰。在這種情況下，由于父圖像為 NULL，因此從平臺獲取公鑰（此密鑰將是 ROTPK）。

• sig: 類型的參數描述符AUTH_PARAM_SIG。它用于從證書中提取簽名。

• sig_alg: 類型的參數描述符AUTH_PARAM_SIG。它用于從證書中提取簽名算法。

• raw_data: 類型的參數描述符AUTH_PARAM_RAW_DATA。它用于從證書中提取要簽名的數據。

一旦檢查了簽名并驗證了證書，就需要從證書中提取 Trusted World 公鑰。authenticated_data為此，在數組中創建了一個新條目。在該條目中，必須指定相應的參數描述符以及緩沖區地址以存儲參數值。在這種情況下，trusted_world_pk 描述符用于從具有 OID 的 x509v3 擴展中提取公鑰 TRUSTED_WORLD_PK_OID。BL31 密鑰證書將使用該描述符作為簽名認證方法中的參數。密鑰存儲在 trusted_world_pk_buf緩沖區中。

BL31 Key 證書是通過使用之前從 Trusted Key 證書中獲得的 Trusted World 公鑰檢查其數字簽名來驗證的。在圖像描述符中，我們通過簽名指定單一的身份驗證方法，其公鑰為trusted_world_pk. 一旦這個證書被認證，我們必須提取 BL31 公鑰，存儲在soc_fw_content_pk. 該密鑰將被復制到 content_pk_buf緩沖區。

BL31 證書是通過使用先前從 BL31 Key 證書中獲得的BL31 公鑰檢查其數字簽名來驗證的。soc_fw_content_pk我們使用公鑰指定身份驗證方法。身份驗證后，我們需要提取 BL31 哈希值，存儲在指定的擴展名中soc_fw_hash。此哈希將被復制到 soc_fw_hash_buf緩沖區。

BL31圖像通過計算其哈希值并將其與從 BL31 證書獲得的哈希值進行匹配來進行身份驗證。圖像描述符包含通過哈希的單一身份驗證方法。散列方法的參數是參考散列、soc_fw_hash和要散列的數據。在這種情況下，它是整個圖像，所以我們指定raw_data.

2.3.2. 圖像解析器庫?

圖像解析器模塊依賴庫來檢查圖像完整性并提取身份驗證參數。解析器庫的數量和類型取決于 CoT 中使用的圖像。原始圖像不需要庫，因此 TBBR CoT 只需要 x509v3 庫。

Arm 平臺將使用基于 mbed TLS 的 x509v3 庫。這個庫可以在drivers/auth/mbedtls/mbedtls_x509_parser.c. 它導出三個函數：

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);

該庫使用宏在框架中注冊 REGISTER_IMG_PARSER_LIB()。圖像解析模塊每次需要訪問類型為 的圖像時IMG_CERT，都會調用該文件中導出的相應函數。

必須更新構建系統以包含相應的庫和 mbed TLS 源。Arm 平臺使用該arm_common.mk文件來拉取源。

2.3.3。密碼庫?

密碼模塊依賴于庫來執行所需的操作，即驗證散列或數字簽名。Arm 平臺將使用基于 mbed TLS 的庫，該庫位于 drivers/auth/mbedtls/mbedtls_crypto.c. 該庫使用宏在身份驗證框架中注冊，REGISTER_CRYPTO_LIB()并導出四個函數：

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); int auth_decrypt(enum crypto_dec_algo dec_algo, void *data_ptr,size_t len, const void *key, unsigned int key_len,unsigned int key_flags, const void *iv,unsigned int iv_len, const void *tag,unsigned int tag_len)

mbedTLS 庫算法支持由 TF_MBEDTLS_KEY_ALG和TF_MBEDTLS_KEY_SIZE變量配置。

• TF_MBEDTLS_KEY_ALG可以接受 3 個值：rsa、ecdsa或rsa+ecdsa。此變量允許 Makefile 在構建中包含各種算法的相應源。將變量設置為rsa+ecdsa 可以支持 mbedTLS 庫中的 rsa 和 ecdsa 算法。

• TF_MBEDTLS_KEY_SIZE設置 TFA 支持的 RSA 密鑰大小。有效值包括 1024、2048、3072 和 4096。

• TF_MBEDTLS_USE_AES_GCM啟用基于 AES-GCM 算法的認證解密支持。有效值為 0 和 1。

注意：如果代碼大小是一個問題，MBEDTLS_SHA256_SMALLER可以在平臺 Makefile 中定義構建選項。它將使 mbed TLS 使用 SHA-256 的實現，內存占用更小（約 1.5 KB 少）但速度更慢（約 30%）。

總結

以上是生活随笔為你收集整理的2-Authentication Framework Chain of Trust的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。