關鍵詞：TBBR、TBB、FIP、AES、RSA等等。
ARM TBBR定義了安全系統基本需求，ATF中實現了COT，包括FIP生成、密碼庫調用、鏡像簽名加密/解密驗簽等等流程。
下面主要參考ARM TBBR文檔，以及《Trusted Firmware-A Documention》。
ARM文檔《Trusted Board Boot Requirements (TBBR)》中定義了安全啟動需求。
ARM Trusted Firmware的《Trusted Board Boot》根據TBBR，對實現COT、TBB流程、認證、加密實現細節進行介紹。
《Building FIP images with support for Trusted Board Boot》對如何編譯支持TBB的FIP進行介紹。
1. ARM Trusted Board Boot Requirements
以下內容來源於：《Trusted Board Boot Requirements (TBBR)》。
2 Overview of the Trusted Boot Process
Trusted Boot Process是一種確保SOC復位開始，僅有正確、計划中的固件/OS/TEE被加載、初始化到SOC上的一種方案。
2.1 Authentication of Code Images by Certificate
2.2 Software Architecture
2.3 Trusted Base System Architecture
3 Trusted Boot Requirements
3.2 Certificate Structure and Cryptography
介紹本文所使用到的密碼算法以及證書結構。
3.2.1 Cryptography
證書簽名必須滿足NSA suite B 128-bit安全標准，並使用如下加密算法：AES-128、SHA-256、ECC256 (ECDSA) or (legacy support of) RSA2048 (RSA-PSS) 。
PKCS #1 – Standard for RSA、FIPS 186-4 – Standard for ECDSA 。
3.2.2 Boot certificates
下圖是X.509 v3證書結構概覽：
3.3 SOC Cryptographic keys
對TBSA所需的SOC的加密秘鑰進行總結。
3.3.1 NV Counters
NV Counters用於保護設備免於版本回滾。
TBBR需要兩個可信NV Counters來保證可信啟動流程：可信固件NV Counter和非可信固件NV Counter。
當鏡像被驗證通過后，將其版本號和硬件中NV Counter值比較：
- 如果版本號小於NV Counter，表示驗證失敗。
- 版本號等於NV Counter，驗證成功。
- 版本號大於NV Counter，驗證成功並更新硬件中NV Counter值。
3.4 Trusted Boot Process
介紹可信啟動流程，介紹何為Chain of Trust、可信流程圖概述、SOC冷啟動后安全。
3.4.2 Overview
可信啟動流程圖：
3.5 Certificate Chaining and Key Infrastructure
3.5.2 AP Non-Trusted firmware updater download and its authentication by the Trusted world
Non-Trusted Firmware Updater職責是從外部接口加載完整的SoC固件到SoC的NVM中。外部接口可能是USB/UART/SD-MMC/NAND/NOR/Ethernet等；SOC固件包括SCP固件、AP固件、TOS、非安全世界固件等；SOC NVM包括NAND Flash等。
3.5.3 Firmware Table of Contents
3.6 Certificate Structure and Content
介紹證書結構及其內容。
3.7 Certificate Creation and Key Management
證書的創建和秘鑰管理。
2. ATF Trusted Board Boot
以下內容來源於：《Trusted Board Boot》。
8.1 Chain of Trust
CoT包含一系列默認可信的組件：
- ROTPK的SHA-256哈希。
- 運行在內置ROM上的BL1。
CoT的其他組件還包括：
- 符合X.509 v3標准的證書。
證書還可以增加附加信息來存儲其他COT所需信息。證書是自簽名的，所以不需要CA來進行認證。
證書分為：
- Key證書：認證給內容簽名的公鑰。
- Content證書：鏡像的哈希。鏡像的認證通過比較內容哈希和Content證書。
公鑰和哈希作為非標准擴展存在X.509 v3證書中。
實現CoT所使用的秘鑰：
- Root of trust key：用於給BL2簽名內容證書和可信秘鑰證書做簽名的私鑰。對應的公鑰是ROTPK。
- Trusted world key：用於給安全世界鏡像的秘鑰證書簽名的私鑰。公鑰保存於可信證書擴展域中。
- Non-trusted world key：用於給非安全世界鏡像的密鑰證書簽名的私鑰。公鑰保存於安全世界證書擴展域中。
- BL3X keys：對BL3X鏡像相應秘鑰證書進行簽名的私鑰。公鑰存於安全世界證書擴展域中。
如下證書用於對鏡像進行驗證：
- BL2 content Certificate：It is self-signed with the private part of the ROT key. It contains a hash of the BL2 image.
- Trusted key Certificate：It is self-signed with the private part of the ROT key. It contains the public part of the trusted world key and the public part of the non-trusted world key.
- SCP_BL2 key Certificate：It is self-signed with the trusted world key. It contains the public part of the SCP_BL2 key.
- SCP_BL2 content Certificate：It is self-signed with the SCP_BL2 key. It contains a hash of the SCP_BL2 image.
- BL31 key Certificate：It is self-signed with the trusted world key. It contains the public part of the BL31 key.
- BL31 content certificate：It is self-signed with the BL31 key. It contains a hash of the BL31 image.
- BL32 key Certificate：It is self-signed with the trusted world key. It contains the public part of the BL32 key.
- BL32 content Certificate：It is self-signed with the BL32 key. It contains a hash of the BL32 image.
- BL33 key Certificate：It is self-signed with the non-trusted world key. It contains the public part of the BL33 key.
- BL33 content Certificate：It is self-signed with the BL33 key. It contains a hash of the BL33 image.
8.2 Trusted Board Boot Sequence
BL1對BL2采取的步驟：
- BL1 loads and verifies the BL2 content certificate：
- BL1 loads the BL2 image：BL1加載BL2鏡像，並且計算BL2鏡像哈希，然后和證書中讀取的哈希進行比較。如果比較通過，則將執行權轉交給BL2鏡像。如何計算哈希？從哪個整數中讀取BL2鏡像哈希？
- BL2 loads and verifies the trusted key certificate：
針對SCP_BL2、BL31、BL32鏡像采取的步驟：
- BL2 loads and verifies the BL3x key certificate：使用Trusted world public key對證書簽名進行驗證。驗簽通過，BL2從證書中讀取並保存BL3x的公鑰。
- BL2 loads and verifies the BL3x content certificate：使用BL3x公鑰對BL3x content certificate進行驗簽。驗簽通過，BL2從證書中讀取並保存BL3x鏡像哈希。
針對BL33鏡像采取的步驟：
- BL2 loads and verifies the BL33 key certificate：BL2加載並驗證BK33 key證書。通過，BL2從證書中讀取並保存BL33公鑰。
- BL2 loads and verifies the BL33 content certificate：BL2加載並驗證BL33 content certificate。通過，BL2從證書中讀取並保存BL33鏡像哈希。
BL2對鏡像進行哈希校驗：
- BL2 calculates the hash of each image：BL2計算鏡像的哈希，並將其和從證書中讀取的哈希進行比較。如果哈希匹配，則驗證通過。
8.3 Authentication Framework
參考文檔：《Authentication Framework & Chain of Trust》
8.4 Certificate Generation Tool
當打開GENERATE_COT=1時，作為ATF編譯過程一部分，cert_create工具被編譯並運行。
cert_create以鏡像和PEM格式秘鑰作為輸入，生成DER格式證書來保證COT。生成的證書被作為fiptool輸入生成FIP。
cert_create使用OpenSSL SSL庫來生成X.509證書。cert_create對OpenSSL的要求是：OpenSSL >= 1.0.1。
cert_create編譯和使用參考：《Building the Certificate Generation Tool》。
8.5 Authenticated Encryption Framework
8.6 Firmware Encryption Tool
當DECRYPTION_SUPPORT != none時，encrypt_fw編譯和運行作為ATF編譯流程一部分。
encrypt_fw以原始鏡像作為輸入，生成加密鏡像並傳遞給fiptool生成FIP。所以FIP是先加密再做簽名。
encrypt_fw使用OpenSSL 1.0.1或更新庫進行加密操作。
encrypt_fw編譯和使用參考：《Building the Firmware Encryption Tool》。
3. 編譯支持Trusted Board Boot的FIP
參考文檔：《Building FIP images with support for Trusted Board Boot》。
Trusted Board Boot主要包括兩方面：鏡像驗證和固件更新。
編譯FIP和FWU_FIP需要支持如下特性：
3.1 實現mbedtls依賴的密碼庫和鏡像解析模塊
mbed TLS == 2.24.0。
3.2 編譯FIP配置選項
編譯FIP之前需要確保如下選項正確配置：
MBEDTLS_DIR=<path of the directory containing mbed TLS sources>
TRUSTED_BOARD_BOOT=1
GENERATE_COT=1
同時還需通過ARM_ROTPK_LOCATION指定ROPTK路徑：
- ARM_ROTPK_LOCATION=regs：ROTPK哈希從運行平台中獲取。
- ARM_ROTPK_LOCATION=devel_rsa：使用默認plat/arm/board/common/rotpk/arm_rotpk_rsa_sha256.bin哈希。如果指定了ROT_KEY，則強制生成新的哈希。
- ARM_ROTPK_LOCATION=devel_ecdsa：使用默認plat/arm/board/common/rotpk/arm_rotpk_ecdsa_sha256.bin哈希。如果指定了ROT_KEY，則強制生成新的哈希。
MBEDTLS_DIR=<path of the directory containing mbed TLS sources> \ make PLAT=<platform> TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 \ ARM_ROTPK_LOCATION=devel_rsa \ ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem \ BL33=<path-to>/<bl33_image> \ all fip
3.3 編譯FWU_FIP配置選項
參考文檔：《Firmware Update (FWU)》。
4. Authentication Framework & Chain of Trust
參考文檔：《Authentication Framework & Chain of Trust》
Authentication Framework需要滿足如下要求：
- 實現COT逐級認證和特定鏡像或證書的認證機制。
- 框架需要區分：
- 編碼和傳輸信息的機制，X.509 v3證書、哈希、NV Counters。
- 認證傳輸信息的機制，比如加密庫。
如下示意圖展示了Authentication Framework內部細節和COT概要機制。
+---------------+---------------+------------+
| 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 |
| |
+-----------------+
2.1 Framework design
2.1.1 Chain of Trust
COT是一系列從Root of Trust開始最終到一個鏡像的認證鏡像的過程。如下框圖展示了BL31鏡像如何滿足COT。
Root of Trust一般指的是ROTPK，其往往固化在芯片內部並不可修改。
+------------------+ +-------------------+
| 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) |
+------------------+ | |
+-------------------+
2.1.2 Image Types
COT中鏡像包括認證鏡像和數據鏡像。認證鏡像包含認證數據鏡像所需信息；數據鏡像包含二進制啟動文件，或任何其他數據。
2.1.3 Component responsibilities
對於每一個COT中的鏡像，需要執行如下操作來認證它：
- 靜態或運行時分配鏡像使用內存。
- 識別並加載鏡像到分配的內存中。
- 根據鏡像類型檢查其完整性。
- 根據鏡像所用密碼算法進行認證。
- 如果鏡像將用於認證其他鏡像，從中提取相關信息用於認證下一個鏡像。
2.1.3.1 TF-A Generic code and IO framework
GEN/IO用於初始化BL1/BL2開始的認證流程。對於任何一個需要認證的鏡像，GEN/IO通過認證模塊遞歸向上查找父鏡像，知道找到認證過的鏡像或者ROT。
GEN/IO使用IO框架加載鏡像，使用認證模塊參照COT要求從ROT到鏡像進行認證。
2.1.3.2 TF-A Platform Port
2.1.3.3 Authentication Module
2.1.3.4 Cryptographic Module
2.1.3.5 Image Parser Module
2.1.4 Authentication methods
2.2 Specifying a Chain of Trust
一個COT可以被一系列連接在一起的特殊排序的鏡像描述符。他們排列順序決定了他們認證順序。
每個鏡像包含一系列AM認證所需屬性。
2.3 Implementation example
5. 相關知識點
X.509 v3
X.509 是密碼學里公鑰證書的格式標准。
X.509 證書己應用在包括TLS/SSL（WWW萬維網安全瀏覽的基石）在內的眾多 Internet協議里。同時它也用在很多非在線應用場景里，比如電子簽名服務。
X.509證書里含有公鑰、身份信息(比如網絡主機名，組織的名稱或個體名稱等)和簽名信息（可以是證書簽發機構CA的簽名，也可以是自簽名）。對於一份經由可信的證書簽發機構簽名或者可以通過其它方式驗證的證書，證書的擁有者就可以用證書及相應的私鑰來創建安全的通信，對文檔進行數字簽名。
另外除了證書本身功能，X.509還附帶了證書吊銷列表和用於從最終對證書進行簽名的證書簽發機構直到最終可信點為止的證書合法性驗證算法。
X.509是ITU-T標准化部門基於他們之前的ASN.1定義的一套證書標准。
DER和PEM
DER - Distinguished Encoding Rules
PEM - Privacy Enhanced Mail
DER是常見的編碼規則，PEM是由DER衍生出的秘鑰文件格式。
DER 是典型的 Tag-Length-Value(TLV) 編碼方式，是 PKCS 密鑰體系常用的編碼。
DER 是 BER 的子集，編碼規則幾乎一樣，不過去掉了 BER 的一些靈活性，多了幾個限制：
- 如果數據長度在 0-127 之間，則 Length 必須使用第 1 種編碼方式。
- 如果數據長度 >= 128，則 Length 必須使用第 2 種編碼方式，且 Length 必須用最少的字節編碼，如果能用 2 字節的則不能用 3 字節。
- 數據要用明確長度的編碼方式，不支持 Length 的第3種編碼即未知數據長度+結束標記的方式。
注意：ASN.1 規定整型 INTEGER 需要支持正整數、負整數和零。BER/DER 使用大端模式存儲 INTEGER，並通過最高位來編碼正負數(最高位0為正數，1為負數)。 如果密鑰參數值最高位為 1，則 BER/DER 編碼會在參數前額外加 0x00 以表示正數，這也就是為什么有時候密鑰參數前面會多出1字節 0x00 的原因。
PEM(Privacy Enhanced Mail)： 因為 DER 編碼是二進制數據，早期的 Email 不能發送附件，也不方便直接傳輸二進制數據([原因])，因此密鑰文件通常會在 DER 編碼基礎上進行 Base64 編碼，這就是經常看到的密鑰文件格式 PEM。PEM 最早是用來增強郵件安全性的，不過沒有被廣泛接受，最后卻是在密碼學中得到了發揚光大，如 openssl 和 ssh-keygen 工具生成的公私鑰文件默認都采用 PEM 格式。需要注意的是，PEM 本身不是 ASN.1 的編碼規則，它只是 Base64-encoded DER。
6. 參考文檔：
《密碼學基礎1：RSA算法原理全面解析》、《密碼學基礎2：橢圓曲線密碼學原理分析》《密碼學基礎3：密鑰文件格式完全解析》