圖 5-12 典型的HVIL連接器結構

2. 接插件在位檢測

對于接插件中包含通信信號的，可以通過通信信號適時與否來判斷接插件是否有問題。但是，對于某些系統(tǒng)中沒有通信信號的接插件，可以通過接插件在位檢測來實現(xiàn)診斷需求。一種方法是選取接插件公頭或者母頭最靠邊的兩個引腳，分別讓它們串聯(lián)一個電阻到地。然后在對應的母頭或者公頭的引腳上也串聯(lián)一個電阻到參考電壓，如圖5-14所示。采集這些引腳的電壓值，如果接插件松動，那么被采集的電壓會被拉到參考電壓。通過電壓的變化可以判斷接插件是否在位。

圖 5-13 HVIL 連接器的互鎖方案示意圖

#05

E2E(End-to-End) 保護是一種端到端的通信保護機制。這里的“端到端”既包括控制器與控制器(比如CAN/Ethernet)之間，也包括控制器內(nèi)部模塊與模塊(比如RTE模塊)之間。

注意，E2E 通常被認為屬于功能安全的范疇，而非信息安全的范疇，在傳輸中不加密，而是明文傳輸。E2E 主要是保證數(shù)據(jù)不被破壞，系統(tǒng)正常執(zhí)行。

AUTOSAR 提供了一系列E2E配置文件，每種配置文件都有特定的機制、參數(shù)和數(shù)據(jù)格式。設計人員需要根據(jù)信號數(shù)量的多少和安全要求的高低進行配置文件的選擇。舉例來說，對于ASILD 的長數(shù)據(jù)，OEM 通常會選擇配置文件4。但無論如何，大家都是在下面這幾種機制中進行選擇和組合。

• CRC:   發(fā)送方基于數(shù)據(jù)計算一組校驗碼，隨數(shù)據(jù)發(fā)送給接收方。

• 計數(shù)器：在每次傳輸請求時，發(fā)送方遞增計數(shù)，接收方檢查計數(shù)器值是否有遞增。

• 超時監(jiān)控：通過接收方計數(shù)器的值是否增加來最終確定。

• 數(shù)據(jù)ID：每個發(fā)送方及對應的接收方端口都有一個唯一的數(shù)據(jù)ID，用于CRC 計算。

有些初學者可能會以為CRC就是E2E，這里澄清一下，CRC 是一種方法，只是E2E 保護機制中的一種。

#06

還有一些硬件的功能安全無法套用上面的機制，或者說我們無法在常見的最佳實踐中找到答案。這時就需要安全工程師進行以下思考。

• 在硬件正常工作和不正常工作期間，整個電路會出現(xiàn)哪些不同的物理現(xiàn)象。通過監(jiān)控這些物理現(xiàn)象，可以側面對硬件器件進行監(jiān)控。

• 如果缺少硬件分析的能力，可以和硬件工程師一起，用示波器的探頭在PCB上找一找不同。比如需要對“一排并聯(lián)的用于產(chǎn)生特殊波形的電路中的輸出端電容”進行診斷， 由于這個波形很特別，如果要用高速ADC 進行監(jiān)控，代價非常大。但是由于已知：當輸出端的電容開路時，每次產(chǎn)生的能量值不變，總容值 C 減小，電壓V相應升高，這時可以用一個比較器去比對輸出端的電壓和預設的閾值，從而判斷輸出端的電容是否有故障。同時，這個比較電路可以診斷許多產(chǎn)生特殊波形電路中的元件。

#07

1. 安全硬件擴展

2006年，HIS 發(fā)布了一份文檔，描述了HIS 安全模塊標準的需求。該文檔內(nèi)容包含錯誤檢測、授權和真實性保護機制。ESCRYPT 進一步與奧迪、寶馬以及半導體供應商(如飛思卡爾，現(xiàn)在的NXP)  合作，將其發(fā)展成為一個開放標準，即SHE 標準，并于2009年4月公開發(fā)布。這個規(guī)范已被廣泛接受，許多針對汽車行業(yè)的微處理器都支持這個規(guī)范。

SHE(Secure  Hardware  Extension，安全硬件擴展)是對任何給定微控制器的片上擴展。它傾向于將對加密密鑰的控制從軟件領域轉移到硬件領域，從而保護這些密鑰不受軟件攻擊。 然而，它并不意味著要取代TPM 芯片或智能卡等高度安全的解決方案。

當前，硬件器件安全機制設計的主要目標如下。

• 保護加密密鑰免受軟件攻擊。

• 提供可信的軟件環(huán)境。

• 讓安全性只取決于底層算法的強度和密鑰的機密性。

• 實現(xiàn)分布式密鑰。

• 保持高靈活性和低成本。

SHE 基本上由三個構建塊組成：一個是加密密鑰和其他相應信息的存儲模塊，一個是塊密碼的實現(xiàn)模塊，一個是將各部分連接到微控制器CPU的控制邏輯模塊。SHE 可以通過幾種方式實現(xiàn)，例如有限狀態(tài)機或小型專用CPU 核心。

SHE 支持的功能如下。

1) AES: 對于數(shù)據(jù)的加密和解密，SHE 支持 ECB 模式和CBC 模式，具體參考NIST800_38A。 數(shù)據(jù)輸入、輸出和密鑰輸入以及任何中間結果可能不能被CPU 直接訪問，但必須由 SHE 的控制器邏輯根據(jù)策略授予訪問權限。

2) CMAC：MAC的生成和校驗必須按照NIST800_38B 定義的AES-128 作為CMAC 實現(xiàn)。

3) Hash：將 AES 作為分組密碼的Miyaguchi-Preneel 結構用作SHE中的壓縮函數(shù)。

4) PRNG/TRNG：用于生成偽隨機數(shù)或真實隨機數(shù)。

5) 安全存儲如下。

• NVM：證書和密鑰存儲在應用程序本身無法訪問的專用非易失性存儲器(NVM)  中，主ECU密鑰(由OEM設置，允許更改其他密鑰)、引導MAC密鑰(啟用特定引導請求并建立安全引導)、引導MAC  (用于引導代碼的身份驗證)和PRNG種子(PRNG的起始值)存儲在NVM中。一般用途的密鑰也可以存儲在NVM中。

• RAM：RAM 用于存儲RAM 密鑰(用于任意操作的臨時密鑰)、PRNG 密鑰和PRNG 狀態(tài)(保持PRNG 的狀態(tài))。

• ROM：ROM 用于秘密密鑰(導入/導出其他密鑰的唯一密鑰，必須在生產(chǎn)時使用片外 TRNG 創(chuàng)建)存儲和唯一密鑰(UID，用于驗證MCU 的唯一標識符)存儲。這兩個密鑰必須在生產(chǎn)過程中注入。

6) 安全啟動：上述功能在啟動時提供安全引導，確保程序的完整性和可靠性。

2. 硬件信息安全模塊

EVITA是歐盟在第七個研究和技術開發(fā)框架計劃內(nèi)共同資助的一個項目。它的目標是設計、驗證和原型構建安全的車載網(wǎng)絡，以保護安全相關組件不受篡改和敏感數(shù)據(jù)不受損害。因此，EVITA為基于V2X 通信的電子安全輔助設備的安全部署提供了基礎。

EVITA 專注于車載網(wǎng)絡保護，側重于保護車輛與外界的通信。

EVITA最高層級的安全目標如下。

• 防止未經(jīng)授權操作車載電子設備。

• 防止未經(jīng)授權修改車輛應用程序，特別是安全和移動商務應用。

• 保障車輛駕駛者的隱私信息。

• 保護車輛制造商和供應商的知識產(chǎn)權。

• 維持應用程序和安全服務的運作。

為了節(jié)約成本和提高靈活性，EVITA定義的不同等級的HSM 見表5-12。它們可以滿足不同的成本約束和安全需求。

• 完整HSM 保護車載域免受V2X 通信帶來的漏洞，這包括用于創(chuàng)建和驗證電子簽名的非對稱加密引擎，通常要求驗簽能力超過每秒2000次。完整HSM 提供了最高級別的功能、安全性，以及所有不同HSM 變體的性能保障。

• 中型HSM 用于保證車載通信安全。中型HSM 類似完整HSM，但微處理器性能較差且不包含非對稱加密硬件引擎。然而，它能夠在軟件層面執(zhí)行一些時間優(yōu)先級不那么高的非對稱加密，例如建立共享秘密。

• 輕型HSM用于確保ECU與傳感器以及執(zhí)行器之間的通信，僅包含對稱加密引擎和I/ O組件，以滿足成本和效率的需求。

圖5-15展示了在汽車車載網(wǎng)絡中，使用三類HSM 保護其安全關鍵組件的示例。僅靠一塊 HSM 保護與外界的無線通信是不夠的，因為系統(tǒng)的行為還依賴于從車輛內(nèi)其他組件接收到的消息。如果這些組件沒有得到充分保護，攻擊者就可能利用這些漏洞進行攻擊。

表 5-12 EVITA定義的不同等級的HSM

圖 5-15汽車車載網(wǎng)絡中不同HSM 方案的示例

3. 可信執(zhí)行環(huán)境

OMTP(Open  Mobile  Terminal  Platform) 于2006年提出了一種雙系統(tǒng)解決方案，即在同一個智能終端下，除了多媒體操作系統(tǒng)外，再提供一個隔離的安全操作系統(tǒng)。這個運行在隔離硬件之上的安全操作系統(tǒng)專門處理敏感信息，以保證信息的安全。該方案即可信執(zhí)行環(huán)境(Trusted  Execution  Environment，TEE) 的前身。

基 于OMTP 的方案，ARM公司于2006年提出了一種硬件虛擬化技術TrustZone及其相關硬件實現(xiàn)方案。TrustZone 是支持TEE技術的產(chǎn)品，是通過ARM架構安全擴展引入的，而ARM也成 了TEE技術的主導者之一。

GlobalPlatform(全球最主要的智能卡多應用管理規(guī)范的組織，簡稱GP)  從2011年起開始起草制定相關的TEE規(guī)范標準，并聯(lián)合一些公司共同開發(fā)基于GP TEE標準的可信操作系統(tǒng)，如 圖5-16所示 。因此，如今大多數(shù)基于TEE  技術的Trust OS都遵循了GP 的標準規(guī)范。

圖 5-16  基于TEE 標準的可信操作系統(tǒng)解決方案示意圖

TEE 通常用于運行高安全操作、保護敏感數(shù)據(jù)、保護高價值數(shù)據(jù)等。

• 高安全操作：如安全鍵盤密碼輸入、指紋輸入、用戶認證、移動支付。

• 保護敏感數(shù)據(jù)：如用戶證書私鑰的存儲、指紋數(shù)據(jù)存儲。

• 保護高價值數(shù)據(jù)：如DRM (數(shù)字版權保護)等。

與 TEE 相對應的是REE(Rich  Execution  Environment)，一 般稱TE和REE 為安全世界和非安全世界。Linux運行在非安全世界上，但某些對安全性要求較高的操作，例如指紋比對、支付時使用私鑰簽名等，需要在安全世界中進行。安全世界和非安全世界通過一種被稱為Monitor  Mode的模式進行轉換。

4. 可信安全模塊

(1) 什么是TPM

TPM(Trusted  Platform  Module，受信任的平臺模塊)是加密協(xié)處理器，其中包含隨機數(shù)生成、加密密鑰的安全生成，以及它們的使用限制功能。它還包括諸如遠程證明和密封存儲等功能。TPM 規(guī)范由受信任的計算組 (TCG)  制定并公開發(fā)行。最新版本TPM 2.0(2014年10月發(fā)布)主要對規(guī)范進行了重新設計。該版本添加了新的功能并修復了TPM 1.2版本的缺陷。

(2) 為什么選擇TPM

采用TPM的計算機可以創(chuàng)建加密密鑰并對其加密。這樣，加密密鑰只能由TPM 進行解密。此過程(通常被稱為封裝或綁定密鑰)可以幫助保護密鑰，避免泄露。每個TPM 都有一個主封裝密鑰(稱為“存儲根密鑰”)，它存儲在TPM 的內(nèi)部。在TPM中創(chuàng)建的密鑰的隱私部分從不暴露給其他組件、軟件、進程或者人員。

采用TPM 的計算機還可以創(chuàng)建一個密鑰(該密鑰不僅可以被封裝，還可以綁定到特定平臺)。只有當平臺度量的值與創(chuàng)建該密鑰時的值相同時，才能解鎖這種類型的密鑰。此過程稱為將密鑰封裝到TPM。解密過程被稱為“解封”。TPM 還可以對在TPM 外部生成的數(shù)據(jù)進行封裝和解封。使用這種封裝的密鑰和軟件(例如BitLocker)，可以鎖定數(shù)據(jù)，直到其符合特定的硬件或軟件條件為止。

借助 TPM，可保持密鑰對的私鑰部分獨立于操作系統(tǒng)控制的內(nèi)存。我們可以將密鑰封裝到 TPM 中，并且在解封并釋放該密鑰以供使用之前，根據(jù)系統(tǒng)的狀態(tài)提供某些保證。因為 TPM 使用自身的內(nèi)部固件和邏輯電路來處理指令，所以它不依賴于操作系統(tǒng)，也不會受操作系統(tǒng)或應用程序中可能存在的漏洞影響。

(3) TPM 標準

TPM 規(guī)范自推出以來，經(jīng)過多次版本迭代，中間產(chǎn)生了ISO/IEC 11889—2009(TCG 1.2) 以 及ISO/IEC 11889—2015(TCG 2.0) 兩個國際標準。該規(guī)范定義了TPM 的架構、結構、命 令與支持途徑等內(nèi)容。

在TPM 中，“可信”指的是確定身份的可預期行為。具體來說，TPM 提供的功能包括基于信任的引薦、認證、測試與鑒證、存儲空間的加密與保護、完整性測量與報告等。

TPM 規(guī)范對加密算法、引擎、隨機生成器、管理及授權、遠程證明等內(nèi)容進行了定義，并定義了軟件接口 。TPM 典型架構如圖5-17所示。

●非易失內(nèi)存可由系統(tǒng)芯片提供，數(shù)據(jù)在受保護的情況下來往于非易失內(nèi)存。此種情況下，TPM 中保護非易失內(nèi)存數(shù)據(jù)副本

TPM1.2  版本主要解決以下問題。

• 設備識別 。

• 密鑰安全生成 。

• 密鑰安全存儲 。

• NVRAM 存儲 。

• 設備健康證明 。

TPM 2.0 版本還拓展了以下功能。

• 算法靈活性。

• 增強授權。

• 密鑰快速加載。

• 非脆弱性PCR。

• 靈活管理。

• 按名稱識別資源。

車規(guī)級TPM 芯片的應用方案可參考圖5-18。

圖 5-18  車規(guī)級 TPM 芯片的應用方案

SLI9670是一款經(jīng)過質量強化的 TPM，在智能汽車中有特殊用途，基于使用了先進硬件網(wǎng)絡安全技術的防篡改安全微控制器。作為交鑰匙解決方案，它根據(jù)最新的TCG 系列2.0規(guī)范，閃存了安全編碼的固件，提供豐富的安全功能集，如密鑰管理、身份驗證、簽名功能(簽名/驗證)、加密/解密、安全日志記錄和安全時間。 SLI  9670符合汽車AEC-Q100 標準，是遠程信息處理、網(wǎng)關、多媒體主機和其他安全要求很高的ECU 中汽車應用的理想解決方案。 該TPM 還根據(jù)通用標準EAL4+ 進行了安全認證。

TPM就像門衛(wèi)一樣，特別保護車輛的外部接口，例如車載信息娛樂系統(tǒng)或遠程信息處理單元中的接口。它可檢查數(shù)據(jù)發(fā)送方和接收方的身份，例如制造商的后端服務器，也可對數(shù)據(jù)進行加密和解密，并幫助確保只有駕駛員或制造商真正想要的數(shù)據(jù)才能進入汽車。

功能安全所需的加密密鑰存儲在TPM 中，就像存儲在保險箱中一樣。

英飛凌在經(jīng)過特殊認證的安全環(huán)境中導入初始密鑰。由于所有其他密鑰都可以在TPM內(nèi)生成、使用和存儲，因此它們不必離開TPM，從而可以防止被網(wǎng)絡監(jiān)控。TPM 還可以抵御物理攻擊，即使有人從車上取下芯片，這些密鑰也不會被讀取。

TPM 的優(yōu)勢如下。

• 基于市場領先的安全專業(yè)知識的高端防篡改安全解決方案，保護最敏感的資產(chǎn)(密鑰、IP、數(shù)據(jù)和業(yè)務案例)。

• 基于經(jīng)驗證的技術降低安全風險(標準化和市場認可的安全解決方案，TPM2.0 預先編程了豐富的安全功能)。

• 由于提供了廣泛的集成安全功能(如專用密鑰管理)，可隨時使用，因此具有高度靈活性。

• 安全環(huán)境中的密鑰注入實現(xiàn)了物流鏈的成本節(jié)約。

• TPM 固件的可更新性實現(xiàn)了長期的加密靈活性和可持續(xù)性。

• 通過可用的開源驅動程序(例如 Linux 驅動程序)，實現(xiàn)了簡單且經(jīng)濟高效的系統(tǒng)集成。

未來信息的流動需要交換大量數(shù)據(jù)。智能汽車將實時交通信息發(fā)送到云端，或從制造商 處無線接收更新，以經(jīng)濟有效的方式快速更新軟件。無論是汽車制造商還是汽車中的各個組件，它們數(shù)據(jù)的發(fā)送器和接收器都需要使用加密密鑰進行身份驗證。這些關鍵密鑰在OPTIGA TPM 中像在保險庫里一樣受到特別保護，不會受到邏輯和物理攻擊。

此外，將初始密鑰結合到車輛中對于智能汽車制造商來說是特別敏感的時刻。使用TPM 時，此步驟可在英飛凌認證的生產(chǎn)環(huán)境中執(zhí)行，之后，密鑰被保護，不再需要在全球分布的價值鏈的各個階段采取特殊的安全措施。

TPM 同樣生成、存儲和管理用于車輛內(nèi)通信的其他安全密鑰。它還可用于檢測車輛中的故障或被操縱的軟件和組件，并在發(fā)現(xiàn)問題的情況下由制造商啟動故障排除機制。

雖然車輛的平均使用壽命為12至15年，但安全功能和算法仍在不斷開發(fā)和增強。TPM 的固件可以通過遠程訪問進行更新，因此它提供的安全機制(包括加密機制)可以持續(xù)更新。

5. 防側信道攻擊

(1) 側信道攻擊概念

側信道攻擊是利用計算機不經(jīng)意間釋放出的信息(如功耗、電磁輻射、電腦硬件運行聲等)進行破譯的攻擊模式。側信道攻擊是一種硬件功能安全攻擊類型，主要通過非預期的信息泄漏來間接竊取信息。

圖5-19展示了一個側信道攻擊的例子。

圖 5-19 側信道攻擊的例子

側信道攻擊涉及以下幾方面。

• 功耗方面：所有電子設備都通過電源軌供電。在基于功耗的側信道攻擊中，攻擊者會在設備運行期間監(jiān)控其電源軌，以獲取電流消耗或電壓波動，從而竊取信息。

• 電磁 (EM) 輻射方面：正如法拉第定律所定義的，電流會產(chǎn)生相應的磁場。基于EM 的側信道攻擊是通過監(jiān)控設備在運行期間發(fā)出的EM輻射來竊取信息。

• 時序方面：在加密實現(xiàn)中，不同的數(shù)學運算可能需要不同的計算時間，具體取決于輸入、鍵值和運算本身。基于時序的側信道攻擊是試圖利用這些時序變化來竊取信息。

(2) 側信道攻擊的防御對策

側信道攻擊的本質是利用密碼實現(xiàn)過程中產(chǎn)生的依賴于密鑰的側信息來實施密鑰恢復攻擊。因此，防御對策的核心是減弱甚至消除這種側信息與密鑰之間的直接依賴性。實際上，常見的防御對策可以分為掩碼對策和隱藏對策兩種。具體來說，掩碼對策借助秘密共享和多方安全計算，通過引入隨機數(shù)將密鑰分解為多個分組，從而消除側信息與密鑰的依賴性，增強抵抗側信道攻擊的能力；隱藏對策則采用平均化“0”和“1”對應側信息的差別，降低通過側信息區(qū)分對應數(shù)據(jù)的可能性，即降低數(shù)據(jù)的可區(qū)分度，以抵抗側信道攻擊。此外，通過在密碼實現(xiàn)中插入隨機偽操作或者增加噪聲，可以將有用信息“淹沒”在噪聲中，從而提高密碼安全性。

總體而言，兩種防御對策適用于不同場景。掩碼對策易于在密碼算法級進行實現(xiàn)，更易于實現(xiàn)；而隱藏對策通常只能在硬件層進行實現(xiàn)，需要改變硬件實現(xiàn)結構，因而較難實現(xiàn)。此外，兩種防御對策可以組合使用，以便最大限度地提高密碼安全性。

6. 安全啟動

安全啟動也叫 Verify  Boot，就是在軟件安全啟動過程中，前一個部件驗證后一個部件的數(shù)字簽名，驗證通過后，運行后一個部件。

網(wǎng)絡設備的安全性嚴重依賴于設備上運行軟件的完整性。通常，我們使用信任鏈來確保軟件的完整性。在安全啟動期間，每個階段實行前都會檢查下一個階段。這個過程中有一個特例，即在這一步之前沒有任何東西可以進行任何檢查，這一階段被稱為“信任根”。

在可信計算體系中，建議信任先擁有可信根，然后建立一條可信鏈，再將信任傳遞到系統(tǒng)的各個模塊，從而實現(xiàn)整個系統(tǒng)的可信。

安全啟動的原理就是“硬件信任錨+信任鏈”。

目前，安全啟動基本上是對安全要求比較高的場景中芯片的必備功能。

(1) MCU 安全啟動

在 MCU 中一般采用OTP(One  Time  Programming) 的方式去實現(xiàn)信任根。任何軟件模塊在校驗失敗后都應該禁止該軟件運行。

SHE(Secure  Hardware  Extension，安全硬件擴展規(guī)范)中定義了安全啟動流程，如圖5-20所示。

安全啟動流程如下。

1) MCU 復位后，CPU啟動并運行安全啟動程序。

2) 安全啟動程序來驗證應用程序A：

① 安全啟動程序讀取安全啟動MAC 密鑰，計算應用程序A 的 CMAC 值 ；

② 安全啟動程序比較確認計算結果和應用的CMAC 值。

3) 如果步驟2驗證通過，則CPU 運行用戶程序A,  并接著驗證應用程序B。

4) 如果步驟3的驗證通過，則CPU 執(zhí)行應用程序B。

(2) SoC 安全啟動

由于操作系統(tǒng)啟動時可能需要多級啟動鏡像，只要其中任意一級鏡像未執(zhí)行安全啟動流程，其后的所有鏡像實際上都是不可信的。操作系統(tǒng)安全啟動流程示意圖如圖5-21。

圖 5-20 安全啟動流程

圖 5-21 操作系統(tǒng)安全啟動流程示意圖

因此，安全啟動需要建立安全啟動的信任鏈。在安全啟動流程中，每一級鏡像都由其前一級鏡像執(zhí)行合法性驗證。這樣，只要保證第一級鏡像是合法的，那么第二級鏡像的合法性就由第一級鏡像保證，第三級鏡像的合法性由第二級鏡像保證。如此，整個啟動流程的信任像鏈條一樣連接起來，最終保證整個系統(tǒng)的可信性。

(3) 安全啟動的信任根

由于信任鏈建立流程中，鏡像合法性是由其前級鏡像驗證的，那么第一級鏡像的合法性如何保證呢?

我們知道，ROM 是一種只讀存儲器，它只能被編程一次且內(nèi)容在編程后不能被再次更改。因此，如果在SoC內(nèi)部集成一片ROM，并在芯片生產(chǎn)時將第一級啟動鏡像刷到這塊ROM 中，那么就能保證它是可信的。這也是現(xiàn)代 SoC 的普遍制作方法。

由于SoC 可能會支持不同的啟動方式，如XIP 啟動可以直接從外部的NOR  Flash 開始啟動。因此，在ROM中集成BootROM鏡像之后，我們還需要保證芯片每次啟動時都必須從BootROM開始執(zhí)行，否則攻擊者可能通過XIP 繞過整個安全啟動流程。一般情況下，XIP 啟動模式在調試階段用于問題定位。因此，在產(chǎn)品調試完成、安全啟動之前，必須關閉該模式。通常，這可以通過OTP或EFUSE中的特定位實現(xiàn)。

(4) 鏡像簽名和驗簽流程

制作鏡像簽名的基本流程如圖5-22所示。

1 ) 使用Hash算法生成鏡像的Hash 值 hash(image)。

2 ) 通過鏡像發(fā)布者的私鑰，使用非對稱算法對鏡像的Hash 值執(zhí)行簽名流程，并生成其簽名值sig(hash)。

3 ) 將鏡像的Hash值、簽名值與鏡像一起發(fā)布，在芯片啟動時可通過圖5-23所示流程驗證鏡像合法性。

圖 5-22 制作鏡像簽名的基本流程

圖 5-23 驗證鏡像合法性流程

上述流程過程如下。

1) 使用非對稱算法的公鑰和簽名值，對鏡像的Hash 值進行驗簽。若驗簽通過，則可進一步校驗鏡像完整性；否則，啟動失敗。

2) 若驗簽通過，則重新計算鏡像的Hash 值hash(image)',  并將其與原始 Hash 值 hash(image)   比較，若相等則表明鏡像的完整性驗證通過，否則啟動失敗。

(5)  公鑰保護

由于驗簽操作依賴于公鑰，若設備上的公鑰被攻擊者替換成他們自己的，那么攻擊者只需用與其匹配的私鑰偽造鏡像簽名即可。因此，我們必須要保證設備上的公鑰不能被替換。

一 般，SoC芯片內(nèi)部會含有若干OTP或EFUSE空間，這些空間只能被編程一次，且在編程后不能被再次修改。

將公鑰保存到OTP 或EFUSE中，可以很好地保證其不可被修改。由于OTP 空間一般較小，而像RSA 之類的公鑰長度卻較長，例如 RSA 2048的公鑰長度為2048bit 。為 了 節(jié) 約OTP 資源，通常在OTP 中只保存公鑰的Hash 值 ( 如sha256 的 Hash 值長度為256bit)，而將公鑰本身附加到鏡像中。