詳解汽車(chē)數字鑰匙（Digital Key）規范

1. 3C數字鑰匙規范簡(jiǎn)介

CCC（Car Connectivity Consortium）車(chē)聯(lián)網(wǎng)聯(lián)盟是一個(gè)致力于制定智能手機到汽車(chē)連接解決方案標準的全球跨行業(yè)組織。2021年7月CCC將UWB定義為第三代數字鑰匙的核心技術(shù)，并發(fā)布CCC R3（第三代數字鑰匙）規范。

CCC R3是基于NFC/BLE/UWB作為基礎的無(wú)線(xiàn)電技術(shù)的使用，該系統采用非對稱(chēng)密碼技術(shù)對車(chē)輛和設備進(jìn)行相互簽名認證，且只對已知車(chē)輛顯示身份，只有使用和車(chē)輛存儲的公鑰相對應的私鑰簽名計算，車(chē)輛才能進(jìn)行解閉鎖、啟動(dòng)發(fā)動(dòng)機等功能。R3可以兼容R2（第二代數字鑰匙），R1（第一代數字鑰匙）是獨立于R2、R3進(jìn)行部署。

在成功完成車(chē)主配對后，車(chē)主每次攜帶設備靠近車(chē)輛Approach前，應執行最低安全測距流程（UWB的工作內容），以建立安全測距，然后才能啟動(dòng)Approach，如迎賓、Lock、Unlock功能；一旦建立了安全測距和設備本地化，車(chē)輛可以根據其策略或要求決定啟動(dòng)上述行動(dòng)。在建立安全測距之前需要URSK（UWB測距密鑰），車(chē)輛可以有一個(gè)預先派生的URSK或根據需要派生一個(gè)新的URSK。URSK的機密性和完整性應在URSK的整個(gè)生命周期內得到保護。

2. DK（數字鑰匙）系統架構

2.1 DK體系架構

DK體系架構各個(gè)流程的說(shuō)明如下：

1. 車(chē)輛通過(guò)線(xiàn)路1遠程連接到車(chē)輛云端，此鏈路提供安全的通信通道，并由車(chē)輛云端安全控制；

2. 車(chē)輛配備了NFC（線(xiàn)路3/4）、BLE（線(xiàn)路11）、UWB（線(xiàn)路12）模塊，可與設備通信以進(jìn)行車(chē)主配對；

3. 所有合格的設備都有一個(gè)經(jīng)過(guò)認證的SE以及NFC功能，使設備與車(chē)輛能夠進(jìn)行通訊，其中NFC功能是必須的，保證手機在沒(méi)電的情況下依舊可以靠NFC對車(chē)輛的一些操作；

4. 車(chē)主設備通過(guò)線(xiàn)路2、線(xiàn)路6、線(xiàn)路8、線(xiàn)路7與車(chē)主設備云端、好友設備云端、好友設備進(jìn)行通信分享鑰匙給好友設備，對好友設備進(jìn)行車(chē)主可設置的訪(fǎng)問(wèn)配置文件、終止分享的DK；好友設備可以使用車(chē)主分享的DK，但不能向其它設備分享車(chē)主的的鑰匙；

5. 車(chē)主設備通過(guò)線(xiàn)路2與車(chē)主設備云端通信，好友設備通過(guò)線(xiàn)路7與好友設備云端通信。車(chē)主設備/好友設備也可以通過(guò)線(xiàn)路10/線(xiàn)路9直接與車(chē)輛云端通信；

6. 車(chē)主設備和好友設備可分別通過(guò)各自的設備云端線(xiàn)路2/線(xiàn)路6、線(xiàn)路7/線(xiàn)路8直接與車(chē)輛云端通信；線(xiàn)路6/線(xiàn)路8用于交換車(chē)輛和車(chē)主/好友設備云端的證書(shū)，實(shí)現鑰匙分享、跟蹤、終止、通知、認證的功能；

7. 設備云端負責管理DK的生命周期（數據的周期），并分別通過(guò)線(xiàn)路2/線(xiàn)路7更新、刪除、暫停、恢復車(chē)主/好友設備中的證書(shū)；它可在設備丟失不可用時(shí)讓其鑰匙功能失效或恢復功能正常；

8. 車(chē)輛云端負責管理用戶(hù)賬戶(hù)和ID&V（識別和驗證用戶(hù)身份）；它還通過(guò)線(xiàn)路5連接到KTS，以注冊車(chē)輛所有的已頒發(fā)的DK，從而保留存儲信息的隱私。

2.2 設備端DK架構

03 NFC數字鑰匙

NFC鑰匙即第一代數字鑰匙，通過(guò)NFC卡片，實(shí)現車(chē)輛的解鎖、閉鎖和啟動(dòng)等功能。目前除了像特斯拉、極氪等車(chē)型的卡片鑰匙，帶NFC功能的手機和手表也逐漸成為進(jìn)入車(chē)輛的新型車(chē)鑰匙。

NFC通信實(shí)現的主要功能如下：

手機第一次配對和分享鑰匙時(shí)，用來(lái)作為設備和車(chē)輛通過(guò)OOB（帶外配對方法）配對來(lái)交換數據的通道；

在手機沒(méi)電、BLE和UWB均不能正常工作的情況下，可以通過(guò)車(chē)門(mén)和控制臺的NFC模塊來(lái)解閉鎖，以及啟動(dòng)車(chē)輛。

車(chē)輛和車(chē)輛的NFC接口需符合《NFC模擬技術(shù)規范》的輪詢(xún)器要求，可支持NFC-A、NFC-B、NFC-F技術(shù)。

設備端的NFC接口應符合監聽(tīng)設備的需求，當電池低電量時(shí)，保證NFC還可以使用。

4. BLE數字鑰匙

藍牙鑰匙即第二代數字鑰匙，通過(guò)藍牙通信技術(shù)和車(chē)輛進(jìn)行連接，實(shí)現鑰匙定位、無(wú)鑰匙進(jìn)入、無(wú)鑰匙啟動(dòng)、遠程控制等功能。

BLE、SE、UWB是第三代數字鑰匙解決方案的核心。其中鑰匙定位升級為UWB技術(shù)實(shí)現，而設備和車(chē)輛之間的安全數據仍通過(guò)藍牙技術(shù)進(jìn)行通信，從而使SE能夠通過(guò)安全通道與車(chē)輛提供相互身份驗證和數據分享。

BLE配對流程

藍牙鑰匙和車(chē)端之間的藍牙配對包含三個(gè)連接流程，其中使用BLE OOB配對建立車(chē)主配對連接的流程如下：

1) 首先是設備藍牙鏈路層連接：

車(chē)輛主機開(kāi)始發(fā)送ADV_IND（廣播），并將CCC-DK-UUID（CCC DK的唯一通用標識符）作為廣播負載，車(chē)輛LL（鏈路層）處于廣播狀態(tài)，過(guò)濾策略設置為接受所有廣播連接請求。設備主機開(kāi)始被動(dòng)掃描，設備LL應處于掃描狀態(tài)，其過(guò)濾策略應是接受所有廣播，一旦設備LL接收到一個(gè)廣播，它將它轉發(fā)給設備主機，設備主機應檢查CCC-DK-UUID是否包含在廣播有效載荷中，如果有效載荷中包含CCC-DK-UUID，則通知用戶(hù)，如果用戶(hù)接受車(chē)主配對請求，則用戶(hù)應提供配對密碼，在14步后，設備LL將進(jìn)入啟動(dòng)狀態(tài)，過(guò)濾策略設置為客戶(hù)廣播的地址，當設備LL收到下一個(gè)相同的廣播時(shí)，設備LL將發(fā)送連接請求。

2) L2CAP面向連接的通道：

L2CAP對LL進(jìn)行一次簡(jiǎn)單的封裝，LL只關(guān)系數據本身，L2CAP要區分時(shí)加密通道還是普通通道，同時(shí)對連接間隙進(jìn)行管理。

最后是BLE設備配對流程如下：

1. 主動(dòng)發(fā)起配對：設備發(fā)送BLE配對請求到車(chē)輛。車(chē)輛發(fā)送BLE配對響應到設備；

2. 公鑰交換：設備向車(chē)輛發(fā)送BLE配對公鑰。車(chē)輛向設備發(fā)送BLE配對公鑰。設備和車(chē)輛生成DHKey；

3. 生成LTK（長(cháng)期的連接安全密鑰）：設備和車(chē)輛都要驗證作為OOB配對準備程序的一部分接收到的確認值是否匹配。設備和車(chē)輛生成1個(gè)隨機數（Na和Nb）。設備發(fā)送（Na）給車(chē)輛，車(chē)輛發(fā)送（Nb）給設備；

4. LTK計算：一旦設備和車(chē)輛上的DHKey生成完成，設備和車(chē)輛會(huì )計算它們的LTK；

5. DHKey檢查：設備將檢查值（Ea）發(fā)送給車(chē)輛，車(chē)輛將檢查值（Eb）發(fā)送給設備，設備和車(chē)輛都需要驗證這些值；

6. 密鑰分發(fā)；

7. 啟用設備和車(chē)輛加密：設備和車(chē)輛將彼此添加到它們的私有地址解析列表中。

 5. UWB數字鑰匙

UWB數字鑰匙即第三代數字鑰匙，UWB全稱(chēng)為超寬帶無(wú)線(xiàn)通訊技術(shù)，相比較于藍牙通信技術(shù)，UWB具有更寬的頻帶，且通過(guò)ToA到達時(shí)間測距技術(shù)，使其擁有更好的定位精度。

5.1. UWB物理層

IEEE標準定義了一種非常靈活的UWB物理層，IEEE標準的靈活性是通過(guò)調整如同步前導長(cháng)度、前導碼、數據速率等參數來(lái)實(shí)現的，但該規范不需要實(shí)現指令的所有參數和格式。

Responder用SYNC同步收到的UWB信息，STS用于生成一個(gè)防篡改的時(shí)間戳。

PHY Header包含PSDU信息，PSDU包含有效信息。

PPDU(PHY protocal data unit)物理層協(xié)議數據單元：

SYNC：又稱(chēng)前導碼區域，接收機為了檢測和同步UWB信號，首先必須找到符合協(xié)議的前導碼；前導碼（由0/1組成的一種幀結構，通知目標做好接受準備）；

SFD：報文起始分隔符；

STS：安全時(shí)間戳；

PHY header(PHR)(SP3沒(méi)有)，物理頭（漢明碼SECDED）；

PHY 服務(wù)數據單元(PSDU)(SP3沒(méi)有），物理層服務(wù)數據單元（里所碼）。

Responder用SYNC和SFD同步收到的UWB信息，STS則用于生成1個(gè)防止篡改的時(shí)間戳，PHR包含了關(guān)于PSDU的內容，PSDU包含了有效信息，就是Initiator真正想傳輸的數據；

STS、Payload屬于可選配置；根據配置，不是所有可選部件都必須在一個(gè)框架中表示.

5.2. UWB測距定位

UWB設備測距流程如下：

首先，Initiator（設備）發(fā)送一個(gè)Pre poll幀（SP0）到車(chē)上的每個(gè)Responder（車(chē)端的節點(diǎn)），Initiator再發(fā)送一個(gè)Poll幀（SP3）到車(chē)上的每個(gè)Responder，然后車(chē)上的每個(gè)Responder分別發(fā)送一個(gè)RSP幀到Initiator，Initiator再發(fā)送一個(gè)Final幀到車(chē)上的每個(gè)Responder，最后Initiator發(fā)送一個(gè)Final data幀到車(chē)上的每個(gè)Responder，這時(shí)一個(gè)測距會(huì )話(huà)就完成了，最終車(chē)端通過(guò)不同的節點(diǎn)和設備之間的距離算出與設備之間的距離。

SP0：

STS packets type0，包含UWB的定位配置信息，但沒(méi)有STS信息；

SP3：

STS packets type3，包含STS索引信息，完全用于定位；

Pre poll：

包含了UWB會(huì )話(huà)ID、Poll STS Index（后續Poll消息的STS索引）、Ranging Block（會(huì )話(huà)當前測距塊的索引）、Round Index（當前測距塊的測距四舍五入索引，該索引由前一個(gè)測距塊中的測距交換器設置）、Hop Flag（當前測距塊的操作標志，由前一個(gè)測距塊中的測距交換器設置）。

Final data：

包含了UWB會(huì )話(huà)ID、Ranging Block、Hop Flag、Final STS Index（前面Final消息的STS索引）、Ranging Timestamp Final TX（Initiator Poll和Final消息傳輸時(shí)間的時(shí)間差）、Number Ranging Responders（此消息中要跟隨的時(shí)間戳數）、Responder Index、Ranging Timestamp Responder（啟動(dòng)器收到響應器的Poll和Response之間的時(shí)間差）、Ranging Timestamp Uncertainty Responder（不同置信度下1.5 cm-3.6 m的值范圍）、Ranging Status Responder（來(lái)自響應程序的響應框架的狀態(tài)）。

6. 總結

目前UWB技術(shù)在手機端和車(chē)端的應用仍處于初期階段，但UWB技術(shù)的優(yōu)點(diǎn)能為人車(chē)交互帶來(lái)更豐富的應用場(chǎng)景。比如自動(dòng)泊車(chē)、車(chē)輛共享、汽車(chē)支付、車(chē)內活體檢測等。信馳達科技自2014年即涉入特斯拉數字鑰匙方案產(chǎn)業(yè)鏈，截至目前已支持過(guò)個(gè)世界級品牌，為近兩百萬(wàn)輛新能源汽車(chē)實(shí)現無(wú)線(xiàn)數字鑰匙賦能。

————————————————

版權聲明：本文為博主原創(chuàng )文章，遵循 CC 4.0 BY-SA 版權協(xié)議，轉載請附上原文出處鏈接和本聲明。

原文鏈接：https://blog.csdn.net/song0156/article/details/129380219