一、 綜述
??在車輛ECU中總是有一些密鑰或重要數據需進行機密性保護,但因產品選型、成本等考慮,導致一些ECU的芯片不支持硬件安全模塊(例如HSM、TEE等)。此時,為保障數據的機密性,可考慮通過軟件實現數據的安全存儲:將需保護的數據加密后存儲到NVM中。
二、方案
2.1 方案概述
??對業務數據使用AES-256算法(AES-256算法使用的密鑰稱為保護密鑰)進行加密,隨后將加密后的業務數據密文存儲在NVM中。此時將對業務數據的保護轉換對保護密鑰的保護,后續只需保障保護密鑰不被泄露和被篡改,即可保障業務數據的安全性。方案通過特定的密鑰派生算法,基于種子,生成保護密鑰。
??將種子拆分成多份的主要目的是提升攻擊者通過逆向方法獲取保護密鑰的難度。在攻擊者對編譯后的Image進行靜態分析時,可有效提升分析難度,避免通過掃描String字符串方式直接獲取到保護密鑰。
- 密鑰派生算法:可使用PBDKF2、Bcrypt、Scrypt等,實際可集合具體場景確定。本文后續以PBKDF2舉例
- 種子:可使用多種形式的種子或互相結合形成種子
-
- 保存在NVM中的隨機數
-
- 硬編碼在代碼中的固定值
-
- 讀取芯片特征值,例如芯片ID
-
- OTP中存儲的值
-
??總體流程如下:
2.2 保護密鑰生成
??將業務數據進行加密存儲后,即可使用把對業務數據的保護轉換為對保護密鑰的保護。為提升保護密鑰的安全性,需僅在需要保護密鑰時,基于特定種子進行生成,避免保護密鑰長期直接存在于ECU中。保護密鑰生成流程如下:
- 通過第一個種子和salt(salt也可以理解為1個種子,salt值可使用和種子相同的方式選擇),使用密鑰派生算法PBKDF2-HMAC-SHA256生成32字節的派生密碼;
- 以步驟1中生成的派生密碼和第二個種子為基礎,使用密鑰派生算法PBKDF2-HMAC-SHA256進行運算,得到32字節的派生密碼;
- 以步驟2中生成的派生密碼和第三個種子為基礎,使用密鑰派生算法PBKDF2-HMAC-SHA256進行運算,得到32字節的派生密碼,即為最終的保護密鑰;
保護密鑰生成過程應封裝為一個函數,便于后續初始化和運行階段直接調用。通過調用保護密鑰生成函數,可直接獲得保護密鑰。
2.3 數據場景
??業務數據使用需考慮兩種場景
-
- 數據預置且不修改:對于預置數據需手動在PC等環境中實現保護密鑰生成和業務數據加密過程,得到業務數據明文。隨后將此業務數據密文寫入NVM或硬編號在代碼中。ECU只需要執行解密過程即可
-
- 動態寫入數據:通過產線或運行時寫入,例如VIN、UDS 2E等服務。當ECU接收到此數據后,調用加密過程進行加密,得到業務數據密文并寫入NVM。當ECU需要使用時,調用解密過程進行解密,即可得到業務數據明文以進行使用。此場景需考慮對寫入前的默認值保護,若默認值無需保護,則默認值可明文寫入NVM。否則需按照“數據預置且不修改”中方式在ECU外部先將業務數據明文轉換為業務數據密文。
2.3.1 數據為預置且不修改
??此類數據需在ECU外部實現加密過程,ECU僅實現解密過程。加密后的業務數據密文可考慮硬編碼在代碼或寫入NVM中。當ECU使用時,讀取硬編碼或NVM中的業務數據密文,隨后生成保護密鑰并調用AES解密,獲得業務數據明文。總體流程如下圖
2.3.2 動態寫入數據
2.3.2.1 默認值無需保護
??當默認值無需保護時,NVM存儲的默認值應為明文,當前業務數據應寫入到1個結構體中,結構體可定義如下:
struct bussiness_data {unsigned int flag;// 指明bu_data數據是類型,0:明文存儲,other:密文存儲unsigned char bu_data[N];//具體長度需結合業務數據確定,需注意AES加密需填充,此處長度需為填充后的長度
};
-
- 寫入默認值:當業務數據為默認值時,flag需置為0,bu_data中保存業務數據默認值的明文。默認值結構體跟隨軟件包等刷入ECU NVM特定區域。
-
- 寫入有效數據:當需要寫入有效的業務數據時,通過UDS、刷寫等方式,此時ECU接收到的為業務數據的明文,ECU需調用AES加密算法,生成業務數據密文,生成業務數據密文后及時銷毀保護密鑰。設置存儲結構體,flag值為1,bu_data為業務數據密文,并將結構提供更新到NVM中(覆蓋默認值)。
-
- 當ECU使用業務數據時,首先讀取NVM中存儲的業務數據結構體,并判斷flag值,若值為0,則直接讀取bu_data用于業務場景使用。若flag值為1,讀取bu_data后,使用AES進行解密,獲得業務數據明文,用于業務操作場景,業務操作使用完成后,需立即銷毀DDR中的保護密鑰。
2.3.2.2 默認值需保護
??當默認值需保護時,NVM存儲的默認值也需要為密文。總體流程如下:
-
- 寫入默認值:當業務數據為默認值時,需在ECU外部環境中實現密鑰保護和加密算法,將默認值轉換為密文,并隨軟件包刷寫等方式,同步存儲到NVM特定區域中。
-
- 寫入有效數據:當需要寫入有效的業務數據時,通過UDS、刷寫等方式,此時ECU接收到的為業務數據的明文,ECU需調用AES加密算法,生成業務數據密文,生成業務數據密文后及時銷毀保護密鑰。并將業務數據密文更新到NVM中(覆蓋默認值)。
-
- 當ECU使用業務數據時,讀取NVM中的存儲的業務數據密文,使用AES進行解密,獲得業務數據明文,用于業務操作場景,業務操作使用完成后,需立即銷毀DDR中的保護密鑰。
三、優化
??具體項目中需結合實際使用場景,確定業務數據明文是常駐內存還是每次使用時解密。若對使用頻繁或對性能有要求(例如SecOC密鑰等),則業務數據明文可常駐內存。否則,建議選擇更安全的每次使用時解密。
四、擴展
4.1 AES算法
??本方案對業務密鑰進行加解密的算法為AES-256,使用CBC模式。CBC的IV可和種子一樣選擇不同的方式。
4.2 PBKDF2算法
??本方案選擇密鑰派生算法PBKDF2。PBKDF2算法為一種密鑰派生算法,PBKDF2算法主要用在防止暴力破解場景,通過增加單次迭代的時間,使暴力破解時間成倍增長,從而提升暴力破解成本。但本方案并不使用此特性,本方案主要目的在通過一組種子作為輸入,生成一個關聯的派生密鑰,作為保護密鑰。當種子固定時,通過PBKDF2算法生成的保護密鑰必定固定。
??PBKDF2算法涉及參數如下:
- 鹽值:32字節長度,可預定義好并硬編碼到代碼中,也可像選擇種子一樣選擇一個salt。
- 迭代次數:2次。因本項目不使用防止暴力破解特性,故次數并不影響安全性,結合效率考慮。需集合實際項目性能,調整次數。
- 偽隨機函數:HMAC-SHA-256算法
- 輸出密鑰長度:32字節
4.3 種子選擇
??種子可以由多種來源,若從穩定性角度考慮,使用硬編碼種子最穩定,若需要一機一密等場景,則可使用芯片ID或者隨機數,實際使用選擇種子時應結合具體場景選擇合適的種子。