作者 |李偉 上海控安安全測評中心安全測評部總監

來源 |鑒源實驗室

引言：第三篇(車載ECU嵌入式設備的診斷測試 - 服務)中我們已經把UDS的相關知識給大家做了介紹，主要講解CAN通訊的地址和尋址、UDS的請求和響應數據幀、多幀數據的結構、部分UDS服務介紹，以及測試測試設計的注意事項說明。本篇以及后續兩篇將會對UDS中最常用的服務進行詳細介紹。本文首先對會話控制請求服務$10和安全接入請求服務$27進行介紹。

01

$10會話控制請求服務

ECU在正常工作時會處于某一個會話模式下，上電后會自動進入默認會話模式，所以ECU啟動后我們不需要輸入$10 01來進入該會話模式。ECU的不同會話模式間存在一定的狀態轉換關系規則。

初次接觸會話控制模式可能不太理解這個服務的含義和用途，我們通過一個例子來進行類比。例如：我們將ECU之間的通訊類比成不同人員之間的對話。兩個人在公共場所暢所欲言，隨意討論非私密性的話題，這個場景類似默認會話，不會對安全性有要求，無需刻意尋找專門使用場所，即不需要專門會話控制進入此模式，上電即默認進入。如果兩人想討論隱秘點的話題，不想其他不相關人員知道，于是換個環境，從公共場所進入了單獨的會議室，這個過程可以類比成從默認會話進入了擴展會話，進入會議室后為了確認對方是本人沒被冒充，進行識別鑒權詢問口令“天王蓋地虎”，查看對方能不能答出“小雞燉蘑菇”，認證鑒權的這個附加過程就屬于跟$10服務配合使用的安全接入請求服務$27，溝通結束退出會議室回到公共區域，這個過程就是從擴展會話退出到默認會話的過程。大家可能有疑問為何沒提及編程會話，這個模式我們會另外講解。

1.1會話模式間的轉換

前面的例子中我們可以看到不同會話模式間的切換存在一定的邏輯關系。下圖顯示的就是一個不同會話間轉換示例圖，需要注意的是不同項目中對于進入編程會話通常會有不同的設計要求，具體項目中會話間跳轉關系必須依據項目的規范文件。

圖 1

1）默認會話

設備上電后自動進入默認會話模式，從圖中我們可以看出在默認會話模式下的切換關系。

本模式重新進入：可以通過$10 01再次進入默認會話，通過$11 01、$11 03復位服務重啟進入默認會話。

本模式進入其他模式：默認會話模式可以通過$10 02進入編程會話模式，在有些項目中默認會話是不能直接進入編程會話模式，具體項目中是否能夠支持需要查閱項目產品的診斷技術規范；默認會話模式下還可以通過$10 03進入擴展會話模式。

2）編程會話

啟動編程會話ECU會進入boot模式，進入boot模式后ECU可以進行固件的更新。boot的更新可以通過Jtag接口使用工具進行燒錄，相對來說Jtag接口的權限等級比較高，可以通過工具直接修改存儲空間中對應地址的數據信息。實際項目會使用CAN網絡進行軟件刷寫，商用階段去除Jtag接口，這樣處理的話安全性會得到一定保障。同樣的在boot模式下可以刷寫固件，那很多診斷服務在boot下也可以正常執行，如配合刷寫的$11、$22、$2E、$31、$28、$34、$36、$37、$85等服務。

本模式重新進入：處于編程會話模式下，可以通過$10 02再次進入編程會話。

本模式進入其他模式：編程會話狀態下可以通過$10 01進入默認會話，通過$11 01服務復位ECU來進入默認會話；編程會話不能進入擴展會話模式。

3）擴展會話

某些服務需要擴展會話的支持才能執行，擴展會話下如果不配合使用$3E服務，ECU會在數秒后自動退出擴展會話模式進入到默認會話模式。

本模式重新進入：處于擴展會話模式下，可以通過$10 03再次進入擴展會話。

本模式進入其他模式：在不使用$3E服務保持會話時，可以通過超時自動退出到默認會話模式，可以通過$10 01進入默認會話，通過$11 01、11 03服務復位ECU來進入默認會話；在某些項目中僅支持$10 03擴展模式下，才能進入$10 02編程會話。

1.2$10服務請求報文

$10服務的請求報文格式總體上跟上篇中描述服務發送報文內容一致。子服務通常是前文講的01默認會話、02編程會話、03擴展會話，當然規范中還存在00保留字段、04安全系統診斷會話、05-3F保留、40-5F主機廠自定義字段、60-7E零部件供應商自定義字段等等。實際上主機廠可以根據項目情況進行高自由度的內部自定義，因為這些定義的范圍都只是在當前項目適用，為了設計上的高復用性和減少設計研發工作量，要適當考慮自定義部分的占比。發送報文幀結構如下圖：

圖 2

舉例，$10服務的請求報文通常為：$10 01、$10 02、$10 03，當然根據項目實際情況可以進行自定義子服務。

1.3$10服務響應報文

$10服務的響應報文格式總體上跟上篇中報文發送內容格式一致。正響應報文的首字節服務號根據協議變為$50，第二字節對應請求報文的子功能。第3至4字節屬性字段是跟ECU收到報文后發送第一幀響應報文間隔時間相關的計時器設置數值，第5至6字節是NRC中0x78否定響應報文發送和下一個消息發送間隔時間相關的計時器設置數值。響應報文幀的結構圖如下所示：

圖 3

舉例，$10服務的響應報文通常為：$50 01、$50 02、$50 03。

$10服務的否定響應格式，可以參考上篇文章服務響應總體中負響應部分介紹，所有UDS服務的負響應故障代碼表在項目中均是通用的。

02

$27安全控制服務

在本篇當中，我們之所以把這兩個服務一起來進行介紹，是因為通常$27服務使用的前提就是先進入$10服務的擴展會話，反過來講$10服務很少單獨使用，一般都是跟$27服務配合先完成安全驗證，然后其他服務才能在一定的會話模式和安全接入等級中正常使用。我們在前篇介紹過主機廠和零部件廠商可以通過不同的UDS服務對ECU執行很多操作，這些操作有的會修改ECU配置，有的可以重啟設備，有的可以讀取信息等等。顯而易見的是，不同操作失誤造成的后果嚴重程度是不一樣的，因此通過安全認證就很有必要。我們通常把默認狀態下的ECU叫做鎖定狀態（Locked），成功執行完成$27服務后的狀態叫做解鎖（Unlock），只有在解鎖狀態下才能進行數據寫入、修改等等操作。

每次$27服務的安全認證過程在Tester和ECU間會有兩輪的信息報文交互，大體的交互過程如下圖所示：

圖 4

2.1 請求報文

$27服務請求報文格式總體上跟上篇中UDS請求報文介紹一致，在交互過程圖中我們可以看到$27服務發送了2次請求報文。

1）Seed請求報文

$27服務開始時，第1條發送報文是用于向ECU請求獲取seed，seed通常由ECU根據算法隨機生成（不會是固定數值）。Tester獲取到seed后根據定義的算法算出key。$27服務根據項目診斷規范要求通常會有幾個不同的安全級別（一般3個足夠了），不同級別的區分通過報文第2字節子服務，即上圖中2n-1字段來定義，通常有0x1、0x 3、0x 5、0x 7-0x 41（奇數）都可以由主機廠根據實際情況自定義選擇，后面的0x43-0x7F很多用于預留，當然主機廠想用于自定義也不是不可以。

舉例，本報文通常有$27 01、$27 05 、$27 09等等用于不同級別安全認證服務。具體安全等級個數和對應的子功能號均根據項目實際情況可以自定義實現。

2）Send key報文

$27服務的第2條發送報文是用于將計算好的key發送給ECU，key的計算都是基于和ECU使用的相同算法，以及ECU發出的seed。報文的第2字節子功能值跟第一條請求報文相關，通常是第1條報文子功能值加1，所以本報文的子服務為偶數。報文第3至6字節即為附帶的key。

舉例，本報文通常有27 02 XX XX XX XX、27 06 XX XX XX XX、27 0A XX XX XX XX。

2.2 響應報文

與請求報文相對應，$27服務的響應報文也為2條。響應報文的格式整體上跟上篇文章介紹的響應報文格式一致。

1）Send seed響應報文

$27服務ECU的第1條響應報文目的是向Tester發送seed，seed是一串隨機數，長度由具體項目規范確定，seed的產生是ECU根據內置的算法隨機產生的。ECU將seed發送給Tester時，本身也會根據seed值通過算法得出key值。

舉例，本報文通常有67 01 XX XX XX XX、67 05 XX XX XX XX、67 09 XX XX XX XX。

2）解鎖確認報文

解鎖成功正響應報文，$27服務ECU的第2條響應報文，是ECU根據Tester發送過來的key，對比本身基于同樣seed，同樣算法計算出的key值，在兩個key值相等的情況下，ECU通過安全認證服務，向Tester發送正響應，通知進入解鎖狀態成功。

舉例，本報文通常有$67 02、$67 06、$67 0A。

3）負響應

負響應的報文格式可以參考上篇的相關章節，負響應NRC代碼表一般在項目中是通用的。

03

總結

$10服務和$27服務通常是配套使用的。

通過上面的描述我們可以看到$27服務用來做安全等級認證，有幾個關鍵的要點。一是seed計算，因為seed用于不同安全等級的key計算，且必須做好一定強度的防破解設計，所以通常情況下都會根據當前時間結合其他固定值，通過內部設計的算法來計算獲得一串偽隨機數，將這串偽隨機數作為seed使用。二是key的計算方法，對應不同的安全認證等級，基于seed來計算key，算法在加密復雜度和數據交換速度之間做衡量。

用于$27服務認證的這套算法屬于主機廠的秘密等級較高的信息，主機廠對零部件供應商釋放時通常是以DLL庫文件的方法進行發布，并釋放調用方法的接口。

04

測試要點

對于$10服務的測試注意點在于：

·不同模式間的轉換實現是否跟規范要求一致；

·其他服務在不同狀態下的支持情況是否符合規范要求。

對于$27服務的測試注意點在于：

算法本身及dll文件一般都經過網絡架構組內部測試才發布，不需要過多關注，需要測試注意的是零部件廠商對于key的計算，在項目初期經常會碰到大小端和移位導致的同樣算法key不一致的情況。

審核編輯 黃昊宇