DoIP規(guī)范

距離上一篇DoIP文章“DoIP測試開發(fā)實踐”已經(jīng)過去兩年了，當時使用的規(guī)范是ISO 13400-2 2012版，隨后新版規(guī)范13400-2 2019版正式釋放，不過時至今日大部分OEM的以太網(wǎng)診斷刷寫規(guī)范依然參考2012版本。DoIP協(xié)議大家已經(jīng)非常熟悉，雖然對于以太網(wǎng)內(nèi)部節(jié)點的DoIP策略各個主機廠需求不盡相同（比如有的要求內(nèi)部節(jié)點支持部分DoIP報文、有的要求支持完整DoIP協(xié)議，還有的要求支持自定義DoIP報文），但對于邊緣節(jié)點的要求基本符合2012版DoIP規(guī)范，那么，2019版的DoIP規(guī)范有什么特殊定義呢？

ISO 13400-2 2019版

2019版規(guī)范相較于2012版主要的變化點：

（1）更新文檔結構：增加“內(nèi)部診斷儀“概念，完善相關細節(jié)描述（如Tester可使用Alive Check Response報文來維持DoIP session）等。

（2）增加TLS（Transport Layer Security）內(nèi)容。

本文將主要介紹TLS協(xié)議，篇幅有限，具體的協(xié)議細節(jié)建議參考相關標準：

▲TLS1.2 IETF RFC 5246

▲TLS1.3 IETF RFC 8446

TLS簡介

TLS Transport Layer Security，由于基于TCP協(xié)議傳輸數(shù)據(jù)時，數(shù)據(jù)包可能被其他人截取、篡改，這給網(wǎng)絡信息安全帶來了極大的挑戰(zhàn)。基于此問題，網(wǎng)景公司提出SSL協(xié)議，IETF在標準化SSL協(xié)議時，將其命名為TLS，也就是說TLS屬于SSL升級版。TLS借助密碼學中的非對稱加密和對稱加密來協(xié)商密鑰以及應用數(shù)據(jù)加密，防止數(shù)據(jù)泄露以及篡改，通過證書機制做身份驗證，防止第三方偽造通信節(jié)點。

TLS組成

TLS協(xié)議是由TLS記錄協(xié)議（TLS record Protocol）和TLS握手協(xié)議（TLS handshake protocol）兩層協(xié)議組成的，其中TLS握手協(xié)議又分為握手協(xié)議、密碼規(guī)格變更協(xié)議、警告協(xié)議、應用數(shù)據(jù)協(xié)議。

握手協(xié)議負責在客戶端和服務器之間協(xié)商密碼算法和共享密鑰，包括證書的認證操作。密碼規(guī)格變更協(xié)議負責向通信對象傳達變更密碼方式的信號，警告協(xié)議負責在發(fā)生錯誤時將錯誤傳達給對方，應用數(shù)據(jù)協(xié)議將應用數(shù)據(jù)傳達給通信對象的協(xié)議，TLS記錄協(xié)議負責消息的壓縮、加密以及數(shù)據(jù)的認證。

基于TLS的DoIP會話流程

對于支持基于TLS的節(jié)點，DoIP安全會話流程如下圖：

出自ISO 13400-2 2019版

（1）完成物理連接以及車輛發(fā)現(xiàn)流程

（2）建立TCP連接（注*端口號3496）

（3）完成TLS握手流程

（4）路由激活、診斷數(shù)據(jù)交互(已被加密)

基于TLS的DoIP數(shù)據(jù)流

使用Vector公司CANoe軟件仿真基于TLS的DoIP通信，數(shù)據(jù)流如下圖：

對于支持安全DoIP會話的節(jié)點，由于診斷儀跳過TLS握手協(xié)議，直接發(fā)送路由激活請求，DoIP節(jié)點返回路由激活應答碼為0x07的路由激活響應報文，路由激活失敗，如下圖：

將數(shù)據(jù)保存重新導入CANoe回訪數(shù)據(jù)，由于CANoe未知對稱加密密鑰，所以無法解析數(shù)據(jù)。

基于TLS的DoIP測試要點

針對支持TLS的DoIP節(jié)點，相應測試用例也需同步增加，如TLS-DoIP流程正向測試、TLS-DoIP端口號測試、握手協(xié)議跳過測試，逆向測試等，該部分測試就基于CANoe的CAPL腳本定制開發(fā)實現(xiàn)。

總結與思考

鑒于TLS協(xié)議的安全性、可識別性和一致性，TLS目前在IT行業(yè)被廣泛使用，特別是HTTPS協(xié)議。在汽車行業(yè)，基于TLS的DoIP協(xié)議后期可能更多應用于OTA以及無線刷寫場景，以增加數(shù)據(jù)傳輸?shù)陌踩浴?/p>

但是DoIP引入TLS有些問題仍需要考慮，首先，診斷內(nèi)容需要經(jīng)過對稱加密算法加密，即只能被通信雙方解析，第三方想要解析數(shù)據(jù)必須知曉二者之間的密鑰，也就是說測試工程師若分析一段基于TLS的DoIP數(shù)據(jù)，必須從診斷儀獲取密鑰，所以獲取密鑰的方式以及便利性需要評估。其次，診斷數(shù)據(jù)傳輸基于TCP協(xié)議，ISO 14229-5規(guī)范定義編程模式的進入或退出以及ECUReset會導致TCP重連，對于診斷協(xié)議測試，控制器可能會不斷地進入退出編程模式以及執(zhí)行ECU HardReset，在此期間診斷儀和控制器間的密鑰可能會隨之變化，那么后期測試分析如何解析整段數(shù)據(jù)？當然以上只是個人看法，網(wǎng)絡安全重要性不言而喻，新特性的引入需結合應用場景迭代、優(yōu)化。為支持OTA和遠程診斷，對應技術的IT化趨勢比較明顯，誰將勇立潮頭，且看風云變幻。

診斷技術的IT化 圖片來源：網(wǎng)絡

北匯信息時刻關注汽車電子的前沿技術，提供交鑰匙的測試解決方案，包括：設計需求規(guī)范的審核、測試規(guī)范/用例開發(fā)、測試腳本/工程的實現(xiàn)和測試實施服務。

注：文中部分圖片來源于Vector。