汽車電子軟體-車輛信息安全2

來自專欄汽車電子軟體設計4 人贊了文章

上次我們講過一次車輛信息安全，認為車輛信息安全總共4個layer，作為汽車嵌入式軟體開發工程師來說，對於ECU層級知道的更多點，也最感興趣一點，那今天就從ECU這個Layer來講一下車輛信息安全。

汽車ECU關注的方面：

• ECU不可被惡意刷寫；
• ECU不可被外界通過診斷或標定介面惡意更改策略；
• ECU的內存不可被外界訪問，需要保護起來；
• ECU不可被外界通過調試介面訪問或惡意更改；

對於ECU層級的Security，HSM很關鍵，HSM的全稱是Hardware Security Module，如下圖所示，左邊是我們熟悉的Tricore及相應的外設，右邊就是HSM，中間隔了一層Firewall，可以有效保護HSM。HSM本身有自己的內核，可以做一些加密解密運算，同時內部也有一些Module是做各種安全演算法的，比如ECC256，Hash演算法等，還有隨機數生成TRNG；另外HSM也有自己獨有的RAM和Flash，只有HSM的內核才可以訪問，Tricore是訪問不了的。有了HSM，我們可以將一些Key存儲在HSM的Flash，也可以通過HSM來進行加密或解密，這樣安全性會得到相應的保證。

ECU的工程應用：

1）刷新的安全性

目前汽車ECU使用的刷新協議都是UDS On CAN，那我們怎麼去保證刷新的安全性呢？

第一，我們可以使用27服務，來禁止未經授權的刷新，通過Seedkey的校驗方式來進行，這種SeedKey的校驗可通過HSM來進行，提高安全性；

第二，我們需要確保數據來源的可靠性，這個可以通過數字簽名的方式來進行保證；將事先將我們要刷入的軟體進行簽名，將簽名的文件和要刷入的軟體一起傳到ECU中，ECU只有完成了簽名認證，才會完成數據的刷寫，否則拒絕刷寫。

在這裡簡單提一下加密的原理：

當前比較流行的是非對稱加密，即存在公鑰和私鑰，兩者是一對的，私鑰要經過嚴格保存，公鑰可對外開放。根據接收者還是發送者擁有私鑰，有兩種應用場景：

第一種是私鑰在接收方手裡，這樣的話可以做到加密解密的作用，即發送方使用接收方給的公鑰加密報文，該報文發出去之後，其他人沒法查看，只有Bob使用它的私鑰可以解開，這樣就體現了秘密傳輸的作用了；

第二種是私鑰在發送方手裡，這樣的話就實現了簽名和認證的作用，即私鑰在發送方手裡，當接收者接收到這個報文時，可以使用手裡的公鑰進行解密，且手裡的公鑰只能解密相應的私鑰加密的報文，這樣可保證數據來源的可靠性。但是存在另一個問題，就是假如黑客給了一個公鑰給接收者，自己用對應的私鑰進行加密報文，並將密文發給接收者，接收者還是收到了不可靠的密文，為了解決這個問題，需要一個認證機構來證明對應的公鑰是可靠的，即發送方需向自己的公鑰發送給權利機關，權利機關會將公鑰和其他相關必要信息放在一起進行Hash計算，生成一個證書，這個證書就可以證明公鑰是可信的。

2）標定/診斷功能

標定、診斷是通過XCP、UDS的通信協議來實現的，可通過安全訪問來進行限制，與刷新的安全校驗原理類似；

3）通信功能

通常我們不會將傳輸的報文進行加密，因為汽車匯流排上CAN通信報文非常多，不可能對每幀進行加密，然後傳輸，再解密，可能會消耗很多計算資源。我們可使用在CAN報文的基礎上加上一段密文，我們稱之為MAC（Message Authentication Code，這段是基於要發送的報文，經過Hash運算得到的密文，採用對稱加密，即加密和解密使用的是同一把鑰匙），隨著報文一起發送出去，到接收方時，會使用秘鑰進行驗證，只有算出的Hash值與MAC一致，才認為該幀報文傳輸是正確的。（MAC的校驗也可通過HSM來進行）

而隨著MAC的需要，普通的CAN傳輸肯定滿足不了需求，因為普通的CAN每幀只有8位元組，如果除了MAC以外，實際傳輸的內容就會很少，這就影響了傳輸效率，所以CANFD應運而生。

4）Debug介面

Debug介面在ECU批產後，會使用相應話的配置初始化（比如IFX晶元可通過配置UCB的方式實現；ST晶元可通過DCF的方式來實現），將Debug保護起來，只有提供正確的Password才可解開Debug介面，進而可以對ECU進行調試。