1. 背景簡介

汽車芯片信息安全的必要性

1. 早期由于ECU本身設計的資源有限，信息安全考慮的也比較少，導致自身的防護能力很弱，容易導致黑客攻擊。隨著智能車技術的發展，雖然芯片的數據處理能力不斷提升，如果芯片自身的安全防護能力過于薄弱，將導致芯片運行的固件也很容易受到攻擊，比如固件篡改，敏感信息（如密鑰等）泄露。

2. 隨著智能車技術的不斷發展，越來越多的政府，行業組織的最佳實踐也明確提出智能車的安全需要構建在安全的芯片基礎上，比如EVITA、GSMA關于汽車安全的要求，HSM已成為智能車的安全基礎，成為行業默認的標準。

3. 智能車功能安全（Safety）和信息安全（Security）在設計階段也有沖突的地方，比如過度基于軟件實現的安全特性，會導致控制指令的延時，影響功能安全特性的實現。因此為了提升產品的性能，以及Safety和Secuirty的強隔離，也必然會要求將更多的信息安全特性集成到芯片里，或者基于芯片的能力來實現。

2. 芯片安全知識圖譜

芯片安全圖譜的兩個維度：

1. 一個維度是芯片自身的安全防護能力，比如能抵抗物理侵入式、半侵入式物理攻擊；能檢測和防御故障注入攻擊；以及耳濡目染的側信道攻擊。這就像是一輛坦克自身厚重的鋼板，能抵擋普通子彈和炸彈的攻擊。物理攻擊需要較強的專業能力，比如借助專用的測試儀器，以及可以近距離接觸的物理設備。

2. 另外一個維度是基于芯片的安全服務，比如芯片直接固化的密碼類算法，密鑰管理機制，真隨機數生成器，PUF等機制。

汽車芯片信息安全知識圖譜V1.0

3. 常見的芯片攻擊手段

3.1 側信道攻擊

a）概念：利用設備的接口對芯片進行電磁和功耗的分析，無需對芯片進行破壞

b）常見測評、攻擊類型：時間分析、功耗分析，電磁輻射分析，光子分析

c）適用對象：集成電路/芯片、智能卡、智能門鎖、物聯網終端、車載電子等產品

d）防護原理：消除和降低側信道信息與密鑰的相關性，常用手段：

- 掩碼技術：引入隨機掩碼，平衡“0”和“1”分布。

- 隱藏技術：平均化側信道信息，降低數據的可區分度

- 混淆技術：降低信噪比（有效側信道信息）如使用隨機時鐘等，增加側信道分析難度。

3.2 故障注入攻擊

利用故障（電壓、時鐘等）引起電路出現異常，根據異常信息分析芯片內部的敏感信息；或者直接利用引起電路的異常來改變程序運行等。

常用測評/攻擊類型：電壓注入、時鐘注入、電磁注入、溫度注入，激光注入。

案例：故障注入攻擊導致安全啟動被成功繞開

（參考Source：樂鑫發布關于故障注入和安全啟動的安全性公告 （CVE-2019-15894））

故障注入攻擊的防護技術：

- 傳感器：專用傳感器（電壓、頻率、溫度等）對電壓、時鐘故障可以起到檢測和告警作用

- 邏輯&時鐘冗余：邏輯冗余分為面積冗余和時間冗余。面積冗余是指多分計算邏輯各計算一次，最終對比各個計算邏輯的結果來檢查是否有故障注入；時間冗余是指一份計算邏輯計算多次，比較多次的結果來檢查是否有故障注入。

- 金屬外殼&特殊封裝：通過金屬外殼，可以對激光故障注入，電磁故障注入等手段具有一定的抑制作用

- 邏輯深埋：將關鍵電路邏輯部署在芯片內層，而不是直接部署在芯片表層，使得故障注入的難度增加

- CRC校驗

3.3 物理攻擊

a）概念：去除芯片封裝，對內部電路進行電接觸，結合其他攻擊手段獲取保存在芯片內部的敏感信息

b）常見攻擊類型：FIB電路修改/探針攻擊、單板級走線篡改/探聽、整機攻擊。

c）防護技術：

- Passive shield：被動屏蔽層，例如在芯片表面構建鈍化層，金屬屏蔽層，增加攻擊者解封裝難度

- Active shield：主動屏蔽層構建一個電路檢測網，覆蓋在關鍵電路表面檢測電路一旦有損壞，就會發出告警

- 特殊封裝：對電路（芯片）采用特殊封裝

- 信號完整性、機密性保護等： 針對單板走線篡改&竊聽總線探針竊聽&篡改等，通過對信號完整性和機密性進行保護來應對此類攻擊

4. 驗證輔助的安全特性

1. Hardware Trust Anchor（HTA）

- 以軟件無法操作的方式保護敏感數據

- 提供加解密功能

2. HTA不同標準：

- SHE

- HSM

- TPM

3. Evita Full-Medium-Light與SHE差異

以下為詳細的案例介紹。

4.1 NXP高級加解密引擎

（1）架構與功能描述：

（2）核心能力：

1） 滿足HSM Full等級；

2） 芯片內支持4個并發加解密任務（job），每個任務帶有資源ID、TZ（Trustzone標記）和任務ID，并能和Trustzone機制配合使用，具有很強的權限控制能力。

4.2 專用算法密碼引擎

（1）NXP針對Flash讀寫直接加解密引擎-Bus Encryption Engine， BEE

BEE 邏輯架構圖

總線加密引擎（BEE）被實現為實時解密引擎，用于CPU直接讀取并同時解密Flash（FlexSPI接口）中的數據。BEE的主要功能是：

- 即時AES-128解密，支持ECB和CTR模式

- 別名內存空間支持。重新映射最多兩個單獨的區域

- 針對這兩個區域的獨立AES密鑰管理

- 基于安全標簽的非安全訪問的過濾

- 非法訪問檢查和過濾

（2）NXP 針對RAM在線加解密引擎-Inline Encryption Engine

支持的功能：

- AES-XTS模式下的DDR加密和解密

- QSPI閃存解密，在AES-CTR模式下

- /O DMA直接加密的存儲和檢索（AES CTR 128）

- 多核資源域分離

- 使用專用總線安全地加載片上密鑰

- 差分功率分析（DPA）電阻

- 檢測物理篡改并響應

4.3 小結

1. SHE規范奠定了汽車安全基礎，引入了汽車可配置的安全子系統概念

2. EVITA的HSM規范擴展了SHE，并采用了Full，Medium、Light三種規格，從而滿足更多場景的要求

3. 如今，OEM正在創建自己的技術規范，包括SHE、EVITA和FIPS 140-2的某些方面，以及區域/行業性特殊要求（比如支持國密算法）

4. 還有一些廠商定義特定的輕量級加密引擎，比如NXP的IEE、BEE、PRINCE算法等

5. 啟動安全

先講一個概念：信任鏈 （chain of trust）

在可信計算體系中，建議信任需要先擁有可信根（Root of Trust），然后建立一條可信鏈（chain of Trust），再將信任傳遞到系統的各個模塊，之后就能建立整個系統的可信。

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

網絡設備的安全性嚴重依賴設備上運行軟件的完整性，通常使用信任鏈確保軟件完整性，啟動期間每個階段在執行前檢查下一個階段，如下圖所示，這個過程有一個特例，這一步之前沒有任何東西可以進行任何檢查，此階段稱為信任根（Root of Trust）。

5.1 安全啟動

安全啟動（Secure Boot）：安全啟動也叫Verify boot，就是在啟動過程中，前一個部件驗證后一個部件的數字簽名，驗證通過后，運行后一個部件。

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

5.2 可信啟動

可信啟動（Trusted Boot）：也稱為Measure boot，就是在啟動過程中，前一個部件度量（計算HASH）后一個部件，然后把度量值安全保存下來，比如放到一個集中的部件（或云端），設備啟動后的一致性（完整性）的校驗由集中的部件負責完成。

擴展：在IoT領域，以微軟為主推出了輕量級的類TPM技術-DICE，就使用了基于硬件信任錨的可信啟動方式。

5.3 加密啟動

顧名思義，就是存儲在flash中的image是密文，啟動過程中會解密在啟動，下圖是NXP加密啟動的流程圖：

注：

1.加密啟動過程本身沒有信任鏈的構建過程

2.安全啟動（Secure boot）、可信啟動（Trusted boot）和加密啟動（Encryptedboot）三種啟動方式并不是互斥的，可以結合實際應用場景、性能要求結合起來使用。比如安全啟動（Secure Boot）和加密啟動（Encrypted boot）相結合，既可以確保啟動過程系統軟件的一致性（沒有加載被篡改過的軟件系統），又能確保Flash中的軟件image不被逆向破解（因為image已被加密）

3.需要注意的，如采用加密啟動，可以借助前面講的IEE硬件加密引擎，就可以顯著提升解密性能，從而提升啟動啟動。

6. 安全存儲

6.1 OTP存儲器

一次性可編程存儲器（On Chip One Time Programmable ROM， On-Chip OTP ROM）OTP存儲器，也稱為eFuse，是芯片中特殊存儲模塊；字段中的任何eFuse位都只能從0編程為1（融合），但是讀取操作沒有限制。OTP在安全中的應用一般可以存放一些固定不變的值，比如：

每個設備唯一的根密鑰（Master Key）

設備唯一ID（Device Unique ID）或者MAC 地址

一些安全配置或者秘密值（軟件的Hash值，啟動模式等）

下面簡單介紹一下OTP和Secure Boot的配合案例，在一些低端設備，限于成本和性能等原因，會采用對稱加密的方式來驗證啟動過程bootloader image合法性，那又是如何做到的呢？

芯片第一次 boot 時，軟件 bootloader 根據以下步驟使能 Secure boot：

（1）硬件產生一個 secure boot key，將這個 key 保存在 efuse 中，利用這個 key、一個隨機數 IV 和 bootloader image 計算出 secure digest。

（2）securedigest 與隨機數 IV 保存在 flash 的 0x0 地址，用于在后續 boot 時驗證 bootloader image 是否被篡改。

（3）bootloader通過燒寫 efuse 中的 ABS_DONE_0 永久使能 secure boot。

（4）芯片在后面的 boot 中，ROM bootloader 發現 efuse 中的 ABS_DONE_0 被燒寫，于是從 flash 的地址 0x0 讀取第一次boot 時保存的 secure digest 和隨機數 IV，硬件使用 efuse 中的 secure boot key 、隨機數 IV 與當前的 bootloader image 計算當前的 secure digest，若與 flash 中的 secure digest 不同，則 boot 不會繼續，否則就執行軟件 bootloader。

（5）軟件 bootloader 使用 bootloader image 中保存的公鑰對 flash 中的 partition table 和 app images 簽字進行驗證，驗證成功之后才會 boot 到 app 代碼中。

第一次boot時secure boot與flashencryption的生效過程如下圖所示，圖中藍色框是 secure boot 的步驟，綠色框是 flash encryption 的步驟：

后續 boot 時流程圖如下，圖中綠色框中的步驟會執行解密，解密是由硬件自動完成：

Source：https://www.cnblogs.com/aaronLinux/p/9198725.html

6.2 Flash空間保護機制

Flash空間保護主要是Flash某些區域設置只讀或者只寫，防止非法訪問和篡改。Flash保護區域的數量和大小會根據Flash的類型和該Flash塊的大小而有所不同。主要的應用場景有：

保護包含代碼的閃存的所有區域，以保護應用程序本身不被覆蓋。用于存儲數據的閃存區域將不受保護。

保護向量表和駐留在閃存中的引導加載程序應用程序，并使其余閃存不受保護。這將防止意外刪除引導加載程序，但閃存的其他部分仍未受保護，以允許引導加載程序執行固件更新。

下面以NXP Flash的空間保護機制為例做個簡要說明：

有個flash存儲空間保護寄存器，FPROT0–FPROT3，默認值由應用程序image根據在flash配置字段中編程的值來確定。FPOROTn- 四個寄存器保護Flash 的32區域。

Source： https://www.nxp.com/docs/en/application-note/AN4507.pdf

6.3. 內存的保護機制：

目前操作系統也可以設置一些區域的不可讀或者寫的機制，也有芯片級內存保護機制，下面仍然以NXP芯片為例。

安全存儲區具備嚴格的訪問控制機制，安全存儲區域具備Domain ID，權限級別（TZ or NS）和權限列表（Permissions），只有硬件訪問時具備這些能力的訪問才能訪問成功，否則會失敗，這個是完全硬件級的訪問控制，可以和Trust Zone和業務的訪問控制權限等配合使用。

Source： i.MX 8Security Overview

7. FOTA（Firmware over the air）

能夠對汽車執行現場軟件更新的優勢已得到充分確立：它將為制造商節省資金，使關鍵錯誤得以立即修復并在其生命周期內隨時向汽車添加引人注目的新功能。理想情況下，對車輛操作至關重要的更新應在后臺無縫且不可見地進行。

上圖顯示了關鍵組件，這些組件將更新文件從OEM服務器獲取到車輛中的特定ECU。通過蜂窩網絡在單個車輛和服務器之間建立安全連接。這樣就可以將新的，更新的固件安全地發送到車輛的Telematics Unit，然后再發送到OTA Manager。OTA管理器管理車輛內所有ECU的更新過程。它控制固件更新到ECU的分配，并告訴ECU何時執行更新。

這在需要同時更新多個ECU的情況下非常重要。為涉及多個ECU的車輛添加新功能。更新過程完成后，OTA管理器將向OEM發送確認。

可以在運行OTA Manager的ECU上安裝外部NAND閃存，以存儲固件更新，直到需要它們為止。外部閃存還可以用于存儲其他車輛ECU的固件備份副本，如果ECU更新出現重大故障，則可以調用該備份副本，從而使ECU沒有任何可用的固件。這些備份副本將通過加密和身份驗證保護來保護，以防止在存儲在外部存儲模塊中的同時對固件進行任何篡改。

OTA管理器包含車輛內每個ECU的表格，其中包括序列號和當前固件版本等信息。這樣，OTA Manager可以驗證到達的固件更新，并確保已授權將其用于該車輛。如果要更新的ECU不具有安全功能，則OTA管理器還將負責解密和驗證傳入的更新。

7.1 ECU的更新過程

完整二進制文件：新固件完整發送。這具有不依賴于先前固件的優點，從而即使先前版本已損壞也可以進行更新。該方法的兩個缺點是傳輸二進制文件所花費的時間以及在接收方ECU中存儲二進制文件所需的空間。許多傳統的ECU在CAN總線上的典型速度為500kbit/ s。

差異文件：在服務器上，OEM將新固件與以前的版本進行比較，并創建一個“差異”文件，其中包含它們之間的差異列表。

根據更改的數量，此文件通常是：

“ A / B”方法（“A/B” approach）：這會使每個ECU上的閃存數量增加一倍，以便它可以在“主”閃存中包含當前固件，并在“第二”閃存中具有用于全新版本的空間。從最終用戶的角度來看，這種方法是理想的，因為ECU可以使用主存儲器保持正常運行，而新固件可以在后臺寫入輔助存儲器。更新完成后，ECU在方便的時間使用新更新的固件（在輔助閃存塊中）（例如，在下次啟動時，也可以等待將開關與要更新的其他ECU進行同步） 。由于始終有可用的固件，因此沒有將ECU置于不可操作狀態的危險，因為始終可以立即“回滾”到先前的可用固件。一個明顯的缺點是在MCU上實現兩倍于執行閃存的成本。

“就地”方法（“In place” approach）：在這種情況下，設備上僅存在固件的一個版本，并且作為更新的一部分擦除并編程了各個塊。當ECU處于正常運行狀態時，更新無法運行-這意味著車輛將在一段時間內無法運行。該時間段主要由重新編程ECU Flash所需的時間決定。車輛中的主要ECU（如發動機控制器）將具有數MB的閃存，如果需要對完整的固件進行重新編程，則可能需要數十秒的時間才能完成。對于OEM廠商來說，這是一個挑戰-客戶是否會接受這樣的事實，即他們無法在長達一分鐘的時間內啟動引擎。A / B方法的增加成本必須與“就地”方法給客戶帶來的不便之間進行權衡。由于“就地”方法中僅存在固件的一個版本，因此更新過程中的錯誤或重置可能很難從中恢復，并且如果未仔細處理，則可能導致模塊（以及汽車）不再功能正常運行，直到在車庫對其進行更新之前，車輛無法使用。

8. 安全診斷（Secure Debug）

現代處理器配備了基于硬件的調試功能，以促進片上調試過程。

-例如，硬件斷點和基于硬件的跟蹤。

-通常需要電纜連接（例如JTAG ［1］）才能使用這些功能。

如果診斷過程沒有合適的安全機制，很容易被黑客利用，如下圖所示：

安全JTAG模式通過使用基于挑戰/響應的身份驗證機制來限制JTAG訪問。檢查對JTAG端口的任何訪問。只有授權的調試設備（具有正確響應的設備）才能訪問JTAG端口。未經授權的JTAG訪問嘗試將被拒絕。此功能需要支持基于質詢/響應的身份驗證機制的外部調試器工具（例如Lauterbach Trace32，Arm?RVDS / DS5調試器等）。通常在設備制造期間而不是在開發板上啟用安全JTAG模式。目前很多芯片廠商都提供自己的安全診斷方案，下面僅以NXP為例：

1.用戶通過JTAG接口請求調試

2.SOC以芯片唯一ID響應

3.服務器找到相應的秘密（TZ或normal world）

4.用戶通過JTAG界面提交秘密

5.安全的JTAG模塊將密鑰與預先配置的密鑰進行比較

6.如果匹配，則啟用調試（對于TZ或normal world）

注：

1. 這里的安全診斷是針對芯片的調測，不要跟測試設備通過OBD口和車內ECU進行通訊爭端協議（UDS）進行混淆了。

2. 從安全角度通常建議設備真正投入使用時，應關閉芯片的JTAG口或者其他類型的調測端口。

9. 安全運行環境

安全運行環境主要是指芯片向OS和APP提供安全的隔離的計算環境，以及配套的虛擬機管理程序或者SDK，通常包括芯片計算多分區（Multi Partitions）機制和可信計算環境（Trust zone）

1.ARM Trustzone + 虛擬化

（1）Arm V8.4架構開始引入了Secure EL2擴展，在Secure 世界中增加了對虛擬化的支持。這使得可以在非安全狀態下進行虛擬化的功能進入安全狀態。虛擬化的一個關鍵特性是增加了虛擬機管理程序控制兩階段的地址翻譯過程（如下圖）。

（2）Secure EL1中安全分區具有隔離的地址空間，其他安全分區無法訪問此空間，是一個沙箱環境。

（3）使用Secure EL2安全分區來實現安全世界的虛擬機，安全分區管理器：EL3和Secure EL2中通用的固件負責管理這些安全分區，這里的關鍵組件是安全分區管理器（SPM）

2. 系統資源隔離（以NXP的XRDC特性為例）

1） 什么是分區：

資源集合（主/從外圍設備，內存區域）

具有域ID和安全屬性

內核，外圍設備和內存可以屬于多個分區

2） 分區的工作原理：

系統控制器將外圍設備和內存區域提交到特定域中（這是客戶定義的）

域之間的任何通信都必須使用消息傳遞協議

如果某個域外設試圖非法訪問其他域，則會發生總線錯誤

3） 分區的好處：

非法訪問時報告立即的，有助于在投入實際應用之前發現難以追查資源競爭問題（又名沙盒方法）

提供成品的安全性：保護系統關鍵的SoC外設免受不太信任的應用程序的攻擊

注：限于篇幅，本文沒有講述Trustzone 技術本身，這方面的技術在網上有大量的論述，本文不再重復。

3. 多核虛擬化

目前很多車載ECU具有多核，每個核可以根據實際需要運行不同ASIL等級的應用程序，也可以把Security和Safety應用嚴格隔離開，或者通過虛擬化技術運行不同的操作系統等。因此多核虛擬化技術應用也會越來越多。第一節講的ARM Trustzone最近的架構已經支持虛擬化技術，下面是NXP虛擬化技術的一個例子

10. 總結

1.芯片的安全為什么這么重要？

最重要原因是汽車容易近距離和物理接觸，所以黑客可以較容易實施物理攻擊，如果沒有安全的芯片設計，很難保障整車的安全。比如密鑰和隱私數據的盜取，篡改等；同時行業標準，整車性能要求也促使大家不得不把更多安全功能建立在芯片安全輔助的基礎之上。

2.汽車芯片級安全技術層次以及各技術之間的關系

2.1首先要關注芯片自身的物理安全能力，汽車芯片必須能抵抗一定級別的物理攻擊，比如黑客可以利用側信道攻擊獲取芯片內部的密鑰信息，一旦獲取密鑰，就可以成功突破車內其他部件，甚至突破一批汽車的安全控制措施，因為目前很多車型是使用相同密鑰的，安全強度低。

2.2 汽車汽車智能化和網聯化的加強，從封閉的安全世界走向了一個相對開放的危險世界。那么整車的信任源在哪里？因為沒有信任源，整車的信任體系就無法建立起來。這個時候我們就要求車內核心的芯片自身必須嵌入信任根或者引入第三方TPM芯片，確保上電的“第一行代碼就是完全可信的，由此通過安全啟動，構建整車的信任鏈。

2.3 有個信任根，就需要關注安全存儲。汽車的密鑰，設備的唯一身份，以及一些特殊的安全度量值（比如軟件hash），安全配置等，都需要安全的存儲機制，確保黑客看不見，拿不走，改不了，這類安全技術比如OTP，PUP，芯片級訪問控制等。

2.4. 有個硬件層面的安全底座，就要考慮上層應用的安全機制，尤其是安全隔離。現在ECU計算能力的增強，運行的功能越來越集中，就需要考慮功能之間的隔離，確保一個功能被黑客攻破，讓攻擊不能蔓延開，從而不會影響其他功能的正常運行，因此就出現了各種安全運行的機制，比如trust zone，虛擬化技術，運行期內存一致性檢查技術，控制流一致性（CFI）技術等

2.5.另外還有一些特殊場景的安全，比如內置數字版權技術，芯片安全調測技術，固件安全刷寫等場景，都需要考慮安全性，否則都會帶來嚴重后果。

最后，我們需要強調的是，沒有一個單點安全技術可以包治百病，安全沒有“銀彈”，必須確保各個芯片設計，軟件設計，系統設計各環節的安全。從威脅分析入手，再基于成本，功耗，基礎設施配套情況等來綜合設計系統的安全機制。

責任編輯：haq