隨著軟件定義汽車的發展，汽車逐步轉變為一個智能化、可拓展、可持續迭代升級的移動電子終端。為實現這一目標，整車在標準操作程序前便預埋了性能超前的硬件，并通過OTA在生命周期中逐步解鎖和釋放功能和價值。

由于OTA主要通過網絡連接升級，因此升級過程中存在一定的安全風險，例如在FOTA流程中存在傳輸風險和升級包篡改風險，如終端在升級流程中缺少驗證機制，黑客可通過網絡手段篡改升級包至車輛終端，進而篡改系統，造成行車安全等隱患。

那么汽車在OTA升級過程中如何保證安全性呢？今天，我們就先來聊一聊OTA過程中的確保傳輸安全的加密驗簽方案。

安全性需求

讓我們先來看看我們傳輸軟件數據過程中可能發生的四個主要問題：

1

竊聽

A向B發送的數據在傳輸中被C竊聽。

2

假冒

A以為向B發送了數據，然而B有可能是C冒充的，反過來毅然。

3

篡改

B確實收到了A發送的消息，但是消息中途被C進行了修改。

4

事后否認

B從A那里收到了消息，但是作為消息發送者A事后聲稱“這不是我發的消息“。

第一個存在的問題，比較簡單，運用“加密”技術就可以解決。

那么后面三個問題，該如何應對呢？這個就需要運用到數字簽名和驗簽機制了。

加密驗簽的安全流程設計

眾所周知，常用的加密方法包括非對稱加密和對稱加密，比如艾拉比OTA解決方案中，就可以根據車廠的要求采用對稱和非對稱的加密手段，以保證OTA升級過程中的安全。目前來說，對稱加密在安全方案中比較常見，這里不再贅述。以下對非對稱加密的安全流程設計做分享討論。

首先，非對稱加密算法需要包含一對公鑰、私鑰。假設A和B均準備好了一對公鑰、私鑰，同時A、B的公鑰已提前告知對方，而私鑰都僅自己可知。準備工作就緒后， A要給B發送軟件數據，加密驗簽流程如下：

第一步加密：A使用B的公鑰將要發送的明文加密，生成密文；

第二步加簽：A將密文通過算法生成摘要，并使用A的私鑰對摘要進行加密，即生成簽名值；

傳輸過程：A將密文及簽名值一同發送給B。

第三步驗簽：B將收到的密文通過相同的算法生成摘要，并使用A的公鑰對收到的簽名解密生成摘要，兩個摘要進行對比，若相同，則驗簽成功，若不同則驗簽失敗；

第四步解密：B將驗簽后的密文使用B的私鑰進行解密得到明文；

以上整個加密驗簽流程概括來說就是：公鑰加密，私鑰解密；私鑰簽名，公鑰驗證。

總結和思考

1.除了上述這種流程，是否可以設計成其他流程呢？

2.假如明文就是一些無規律的且不可破解的二進制流，那么加密步驟①是不是可以省去了呢？

3.假如加密步驟①使用對稱加密算法或者自定義的算法呢？

4.另外，對于簽名步驟②中的生成摘要，目前一般應用較多的就是MD5或哈希算法，摘要加密可使用RSA算法。那是否還有其他算法呢？

這些都留給朋友們來一起溝通和討論吧。

今天的OTA安全解決方案之加密驗簽就分享到這里了。如果你對OTA技術有任何疑問，歡迎添加下面OTA小助手微信進群討論。針對常見問題，我們將不定期召開專題討論，為大家打造一個開放的技術溝通平臺。

編輯：jq