DoIP規(guī)范

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

ISO 13400-2 2019版

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

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

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

本文將主要介紹TLS協(xié)議，篇幅有限，具體的協(xié)議細(xì)節(jié)建議參考相關(guān)標(biāo)準(zhǔn)：

▲TLS1.2 IETF RFC 5246

▲TLS1.3 IETF RFC 8446

TLS簡(jiǎn)介

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

TLS組成

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

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

基于TLS的DoIP會(huì)話流程

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

出自ISO 13400-2 2019版

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

（2）建立TCP連接（注*端口號(hào)3496）

（3）完成TLS握手流程

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

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

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

對(duì)于支持安全DoIP會(huì)話的節(jié)點(diǎn)，由于診斷儀跳過(guò)TLS握手協(xié)議，直接發(fā)送路由激活請(qǐng)求，DoIP節(jié)點(diǎn)返回路由激活應(yīng)答碼為0x07的路由激活響應(yīng)報(bào)文，路由激活失敗，如下圖：

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

基于TLS的DoIP測(cè)試要點(diǎn)

針對(duì)支持TLS的DoIP節(jié)點(diǎn)，相應(yīng)測(cè)試用例也需同步增加，如TLS-DoIP流程正向測(cè)試、TLS-DoIP端口號(hào)測(cè)試、握手協(xié)議跳過(guò)測(cè)試，逆向測(cè)試等，該部分測(cè)試就基于CANoe的CAPL腳本定制開(kāi)發(fā)實(shí)現(xiàn)。

總結(jié)與思考

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

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

診斷技術(shù)的IT化 圖片來(lái)源：網(wǎng)絡(luò)

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

注：文中部分圖片來(lái)源于Vector。