解讀trifinite.group對特斯拉的安全研究

一. 概述

trifinite.group 是由Martin Herfurt和Collin Mulliner于2004 年 8 月成立的計算機專家小組，他們將空閑時間用于無線通信和相關領域的研究。在對特斯拉的研究方向上，他們專注于被動進入系統。

本文是對他們研究成果梳理后的匯總，從2019年的iBeacon隱私泄露開始，依次介紹Key Drop攻擊、授權提取并重放、授權定時器攻擊、P2D繞過以及加密計數器混淆。其中還將穿插介紹他們開源的工具——能夠模擬 Tesla 汽車 BLE 接口的Temparary以及充當 VCSEC 客戶端連接汽車的Tempara。

二. 特斯拉解鎖的方式

1、NFC 鑰匙卡（NFC Card）

車主隨車就可獲得已加入白名單的NFC鑰匙卡。解鎖或鎖定車輛時，需將卡片鑰匙貼近駕駛座側B柱中部；啟動車輛或進行授權時，需將卡片鑰匙放置于杯托后側的中控臺感應區。卡片鑰匙無法實現“被動進入（passive entry）”。

2、手機鑰匙（PhoneKey）

手機鑰匙是特斯拉官方iOS/Android APP中的一項功能，該功能基于Bluetooth LE (BLE)/NFC，允許“被動進入（passive entry）”。把手機設置為車鑰匙之后，手機可以通過藍牙與車輛進行通信，當手機靠近車輛時，車輛會檢測到手機的藍牙信號，并在按下門把手時自動解鎖車門。

3、鑰匙扣（KeyFob）

這是個實體小設備，基于Bluetooth LE (BLE)，從V.P60開始允許“被動進入”。開鎖時無需手動操作鑰匙扣，將鑰匙扣放在口袋中，拉動門把手即可開鎖。在進行授權的時候，通過輕觸中控臺感應區即可。

特斯拉一直在汽車行業實施新技術。其中一項創新就是藍牙接口，用于鎖定和解鎖車輛，并可用于唯一識別汽車。特斯拉將此前僅在model 3和model Y上使用藍牙被動進入系統，后引入到特斯拉2021年model S/X改款等產品線中，表明了這項技術在未來幾年對特斯拉的戰略重要性。

三. iBeacon隱私泄露

Martin Herfurt 于 2019年發現他的Tesla Model 3會通過BLE不斷對外明文廣播一組特殊的ID號。Tesla將這組ID號作為實現手機APP開鎖的重要參數。

這組特殊的ID號碼其實和 iBeacon 有關，iBeacon是蘋果公司于2013年9月發布的一種基于低功耗藍牙的通信協議。其工作方式是，配備有iBeacon協議的低功耗藍牙設備向周圍廣播發送自己特有的ID，接收到該ID的應用軟件會根據該ID采取一些行動。蘋果公司還定義了iBeacon廣播的數據格式，其中包含了UUID, Major, Minor, TX Power這幾個重要參數。

UUID是一串16字節的字符串,這組字符串主要是用來區分各個不同的廠家，比如特斯拉的UUID 為 74278bda-b644-4520-8f0c-720eaf059935；Major和Minor都是2字節的字符串, 它們都是隨機值，可能發生碰撞，但實際上不太可能；TX Power則是通過信號強弱來識別與車主的距離。

廠家可以根據實際需求重新定義具體用途，Tesla Model3 的廣播數據實例如下圖所示：

首先車輛藍牙名稱為S7120a62f34cd8018C，名稱的結構遵循：S<8字節十六進制>C(D,P,R)。即以“S”開頭，以“C/D/P/R”結尾，猜測結尾各項分別為：C(center，中間)、D(driver side, 駕駛室一側)、P(passenger side，副駕駛一側)、R(rear,后方)。中間的8字節十六進制是隨機的，并且每輛車都不一樣。

安裝有Tesla App 的智能手機（Andoid/iOS）在連接車輛時，手機會根據車輛藍牙名稱來識別車輛（未采用藍牙設備地址來識別是因為iOS設備為了隱私混淆了該信息）。

但是這里存在一個問題，就是用戶并沒有權限改變或者關閉該ID, 那么通過掃描捕捉這組ID號, 有心人就可能實現對車主的跟蹤, 甚至對車主的個人隱私造成困擾。Martin為此還特意寫了一個APP (teslaradar，特斯拉雷達)，安裝有此應用程序的手機能夠檢測到在其附近的特斯拉車輛，teslaradar收集到的數據共享后還形成了全球特斯拉監測平臺（https://www.teslaradar.com/）。

特斯拉在2019年對此風險的回應表示藍牙追蹤是他們內部已經考慮到的問題，他們對此的評估是即便隨機化該ID，還會有其他方法可以跟蹤汽車，該風險可接受。

四. Key Drop攻擊

Tesla Key Drop 攻擊通過使用開源的Temparary工具模擬車輛來進行。一旦車主手機上的應用程序開始與模擬汽車的仿真 BLE 接口通信，Temparary將向手機請求授權。當Temparary從手機接收到 VCSEC AuthorizationResponse 后，Temparary會響應用于簽署 AutorizationResponse 的密鑰是未知的。在應用程序嘗試驗證這種異常的情況后，手機應用程序中的車鑰匙將被停用，手機與車輛會斷開連接。

由于手機中的鑰匙不會被此攻擊刪除，并且鑰匙對真車仍然有效，因此當車主下次要使用車輛時，需要啟動鑰匙恢復過程。該過程需要用卡片鑰匙輕觸B 柱或中控臺上的 NFC 傳感器。

上文中提到的 VCSEC (Vehicle Control Secondary)，用于定義設備和車輛之間的交互，通過它能做很多事情，例如：解鎖和鎖定汽車、打開和關閉充電口、打開和關閉大多數車型后備箱、遠程啟動等。

此攻擊在 App 版本 4.11.0（2022 年 7 月 15 日）上成功測試。下面展示Temparary實施Key Drop的過程。

temparary.py 是一個基于 pybleno 的 python 腳本，能夠模擬 Tesla 汽車的 BLE 接口。從APP 上看的話，Temparary模擬了隨機汽車。不過目前該工具只是實驗性的，只實現了基本的交互。https://github.com/trifinite/temparary

使用方法：

• 使用 bluez-tool bdaddr將藍牙接口設置為實驗車輛的地址。Android 應用程序能夠判斷車輛的 MAC 地址，只有在地址正確的情況下才會產生連接。
• 確保停止并禁用系統的藍牙進程，因為它會干擾temparary的 BLE 通知。
• 復制exapmle_vehicle.json文件并將里面的值調整為被模擬的實驗車輛正在使用的值。exapmle_vehicle.json 中的示例內容如下：

eir指Bluetooth EIR（Extended Inquiry Response，擴展搜索響應），其結構如下：

綠色：長度、藍色：iBeacon UUID、橘色：iBeacon major、紫色：iBeacon minor。

ScanResponse示例：

綠色：長度、藍色：汽車VIN。

視頻 https://github.com/trifinite/temparary/blob/main/images/KeyDrop.mp4中展示了Key Drop 實施的主要過程:

1. 運行./temparary.py 腳本并等待智能手機應用程序連接到temparary會話。

藍色的是從手機 APP 發出的消息，綠色的是Temparary 發出的消息。

手機APP 首先發來了 KeyId， KeyID 代表白名單中的密鑰，KeyID = SHA1(public key)的前四字節。

2. 輸入“e”并回車來切換evil bit。

3. 輸入“a”并回車請求授權。

Temparary響應SIGNEDMESSAGE_INFORMATION_FAULT_NOT_ON_WHITELIST

Temparary返回白名單中的密鑰。

4. Temparary與手機斷開連接；

5. 輸入“q”回車退出應用程序。

五. Tesla授權提取/重放

特斯拉授權重放攻擊中也使用到了Temparary工具，它用來收集手機應用發送的VCSEC AuthorizationResponses。

AuthorizationRequests主要用于被動進入功能，被動進入系統依賴于挑戰-響應模式，大致過程是這樣的：車輛發送一個challenge token，手機應用程序必須對此token用AuthorizationResponse來應答，AuthorizationResponse嵌入在一個VCSEC SignedMessage對象中，該對象的簽名類型是SIGNATURE_TYPE_AES_GCM_TOKEN。

攻擊者從目標汽車中獲取到challenge token，然后前往車主附近，假裝是汽車發送challenge token以收集手機發送的有效AutorizationResponses。一旦攻擊者收集到足夠數量的有效AuthorizationRequests，就可以在車輛請求授權時進行響應。手機響應車輛的過程可以通過像tempara這樣的工具來實現，tempara.py 是一個基于 Bleak 的 Python 腳本，能夠充當 VCSEC 客戶端對車輛的VCSEC接口進行未經身份驗證的調用。

而且研究人員在測試中發現，token在幾天內都沒有變化，也就是說用于挑戰VCSEC AuthorizationResponse的token不會經常更改。

PIN2Drive功能提供了針對這種攻擊的保護。

六. 特斯拉授權定時器攻擊

2021年8月特斯拉發布了一項更新。從前，車主使用卡片鑰匙打開車門坐在駕駛座上后，系統會提示將卡片鑰匙放在中控臺上才能啟動車輛，更新后車主在使用卡片鑰匙解鎖車輛后，無需將其放在中控臺上就能直接啟動。

但是這項功能有一個奇怪之處，即它不僅讓汽車在使用 NFC 卡解鎖后130 秒內自動啟動，而且還使汽車處于能接受全新鑰匙的狀態——不僅不會對添加鑰匙使用者的身份進行任何確認，車載顯示屏上也不會顯示任何告警。

在正常情況下，添加新的卡片鑰匙或遙控鑰匙時，都需要在中控臺上掃描已認證（即已經有車輛訪問權限）的卡片或實體鑰匙。但是在車主用 NFC 鑰匙卡解鎖車輛后的 130s 內，無需將NFC 鑰匙卡放在中控臺上也能將新鑰匙添加到車鎖白名單中。

特斯拉引入這一計時器的原本目的是使使用者可以通過 NFC卡更方便的操控汽車，但問題在于這130秒內，使用者不僅獲得了啟動車輛的權限，而且還獲得了注冊新鑰匙的權限。

當然，特斯拉官方的APP確保了只有車主才能添加鑰匙，它要求必須登錄車輛的Tesla賬戶，否則APP 不允許注冊新鑰匙，但問題是汽車仍然會與附近的 BLE設備交換數據。

為了保存鑰匙，研究人員需要一個VCSEC客戶端或一個可以處理鑰匙協議的應用程序，為此他開發了一款名為 Teslakee 的 App,用來驗證可以在這130秒內注冊新鑰匙。Teslakee的非武器化版本有助于防止中繼攻擊，可通過https://www.teslakee.com/訪問。

利用 Teslakee 秘密注冊鑰匙對黑客的唯一要求是：在車主使用 NFC鑰匙卡打開車門后130秒內與車輛的距離必須保持在 BLE 信號傳輸范圍內，如果車主使用手機App 打開車門，則可以通過干擾信號迫使車主使用 NFC卡，并趁機注冊自己的鑰匙。具體實現步驟如下：

1. 車主用鑰匙卡打開車門，與此同時，中控屏亮起，車主坐入駕駛室并關門。

2. 攻擊者在車輛附近，手機上裝著 TeslaKee，TeslaKee 看起來識別到了車輛的 MAC 地址，并且也能和車載中控屏一樣顯示車輛的狀態。

下圖中TeslaKee 界面中的車身周圍亮起，應該表示TeslaKee和汽車成功通信了。

3.  添加鑰匙時，可以看到TeslaKee界面中確實有認證提示：請刷NFC 卡片以允許當前操作。

4.  車內用戶并未將 NFC 卡片放置于中控臺上。不久后，TeslaKee界面提示操作已成功。

5. 保存了被列入白名單鑰匙的TeslaKee APP通過BLE響應 VCSEC 的授權請求。

如果汽車沒有開啟 PIN2Drive 功能，那么車輛馬上可以被開走。

所以，將 NFC 卡片交予他人使用時需要注意安全風險。況且，有不少車主習慣將 NFC 卡片總是放置于中控臺上，這也是一個容易帶來風險的習慣。

值得注意的是，一旦攻擊者在汽車中注冊了有效鑰匙，攻擊者還可以通過發送 VCSEC 命令“REMOTE_DRIVE”繞過 PIN2Drive。https://www.youtube.com/watch?v=vWM98f3-vvc&feature=youtu.be&ab_channel=trifinite.

七. PinToDrive（P2D）繞過

trifinite.group 對于P2D繞過只提供了一個演示視頻，并未有更多說明，不過另一位獨立研究員Lex Nastin在其博客中提供了P2D繞過的更多內容（https://www.lexnastin.com/?action=view&url=is-pin-to-drive-really-securing-your-vehicle）。

P2D功能允許車主設置一個安全的四位數驗證碼，必須正確輸入后才能啟動汽車。但結合VCSEC的部分功能和授權定時器攻擊后，P2D也存在被繞過的風險。

之前提到特斯拉的VCSEC(Vehicle Control Secondary)能做很多事情，其中一個特別突出的作用，就是遠程啟動。但存在的問題是遠程啟動時并不要求提供P2D碼或任何其他東西。那么在成功執行授權定時器攻擊，擁有一個被列入白名單的鑰匙后，再向汽車發送一條帶有RKE_ACTION_REMOTE_DRIVE RKE動作請求的信息就能夠繞過PIN碼輸入，直接啟動汽車。

Lex Nastin出于教育目的創建了一個安卓應用程序，名為P2DB（Pin To Drive Bypass）。在自己開啟了P2D功能的車輛上實驗，首先選擇車輛，按下 "Hack"，用鑰匙卡輕觸感應區，然后直接啟動。https://github.com/ArchGryphon9362/p2db

特斯拉2022 年 7 月 22 日對此問題的回復是已在 2022.16.1.2 及更高版本中修復。

八. 特斯拉加密計數器混淆攻擊

特斯拉加密計數器混淆攻擊（Tesla Crypto Counter Confusion Attack）的工作原理是用Temparary工具模擬車輛，一旦手機上的應用程序開始與被模擬汽車的仿真BLE接口通信，Temparary工具就將向手機請求授權。

在從手機接收到VCSEC AuthorizationResponse后，Temparary工具做出響應，表示AuthorizationResponse中加密計數器的值為SMALLER_THAN_EXPECTED。然后，手機應用程序將向車輛詢問實際的會話信息，會話信息中包括實際的加密計數器值和challenge token。

上述步驟可以用于在手機應用程序中設置一個新的計數器值，該值將用于下一次與真實車輛的通信。將該值設置為最大可能的UINT32值4294967295 (iOS)/2147483647 (Android的INT32)，這將打破加密計數器邏輯。而且由于加密計數器不能再繼續增加，該密鑰也將不能再被使用。

這種情況下通常需要車主重新安裝官方手機應用程序，并生成一個新的密鑰，而且該密鑰必須加入車鎖白名單中。但是來自同一臺智能手機的新密鑰加入白名單將導致車輛中存在兩個名稱相同的不同密鑰。這種情況似乎觸發了一種安全機制，即要求用戶在B柱上輕觸NFC 鑰匙卡。而且這種情況將一直持續到具有相同名稱的第二個密鑰被刪除。

由于在此期間需要不斷使用NFC 鑰匙卡輕觸B柱，這也為攻擊者實施密鑰注冊提供了機會。