針對Model X無鑰匙系統的遠程攻擊

本研究是針對特斯拉 Model X 無鑰匙系統的實用安全評估。所分析的無鑰匙系統采用了由通用標準認證的安全元件實現的安全對稱密鑰和公鑰密碼原語。本文記錄了該系統的內部工作原理，包括遙控鑰匙、車身控制模塊和配對協議。此外，還介紹了相關逆向工程技術和幾個安全問題。其中，遙控鑰匙固件更新機制和遙控鑰匙配對協議中發現的問題導致繞過了所有已實施的加密安全措施。此研究還開發了一種完全遠程的概念驗證攻擊（PoC），允許在幾分鐘內進入車輛內部并配對修改后的遙控鑰匙，從而啟動汽車。該攻擊不是中繼攻擊，因為其允許攻擊者隨時隨地啟動汽車。

一、系統剖析

用戶可以將遙控鑰匙和車身控制模塊 (BCM) 視為解鎖和啟動 Tesla Model X 的主要組件。實際上，還涉及其他車輛組件（例如驅動逆變器）。用戶還可以使用配套的智能手機應用程序解鎖和啟動汽車。汽車只會執行先前與汽車配對的遙控鑰匙請求的操作。要將遙控鑰匙與汽車配對，維修技術人員可以使用 Tesla Toolbox 軟件。遙控鑰匙可用于通過按下按鈕來鎖定和解鎖汽車，這被稱為遠程無鑰匙進入 (RKE，Remote Keyless Entry)。此外，被動無鑰匙進入和啟動 (PKES，Keyless Entry and Start) 功能可確保在遙控鑰匙接近時，汽車將自動解鎖并啟動。

A. 遙控鑰匙

下圖顯示了 Model X 遙控鑰匙中包含的PCB。值得注意的是，德州儀器的 CC2541 BLE 片上系統 (SoC)負責與汽車通信的遙控鑰匙。此外，還有一個 Maxim Integrated 低頻 (22 kHz) 轉發器芯片，用于接收車輛發送的數據。最后，還有一個通過 Common Criteria EAL5+ 認證的英飛凌 SLM97 安全元件。該遙控鑰匙包含三個微處理器，每個微處理器都包含一個硬件 AES 協處理器。

特斯拉選擇了不太傳統的低功耗藍牙（BLE，Bluetooth Low Energy）作為汽車通信通道的遙控鑰匙，很可能是為了使用同一頻道的電話即鑰匙功能（phone-as-key）。此外，與125 kHz和134.2 kHz通道相比，22 kHz的LF通信通道似乎沒有被廣泛使用。這種不太常用的通信通道與加速度計相結合，可能有助于防止中繼攻擊。在中繼攻擊中，攻擊者將被動進入場景中的汽車和遙控鑰匙之間的最大距離被延長，即使遙控鑰匙不在物理上，也允許解鎖和啟動汽車。不常見的通信通道與大多數現成的中繼工具不兼容。此外，加速度計可用于在遙控鑰匙不移動時將其置于所謂的深度睡眠模式：這會延長電池壽命并允許遙控鑰匙忽略傳入的通信嘗試。

Model X遙控鑰匙嵌入了許多硬件，并且應該包含創建實際安全遙控鑰匙所需的所有組件。使用通用標準認證的安全元件使研究者相信遙控鑰匙的設計考慮了安全性。通過識別遙控鑰匙中使用的組件，很明顯攻擊不太可能涉及對專有密碼的密碼分析，而是希望設備使用標準化的密碼原語。另一方面，這個遙控鑰匙比經典設計更復雜，并且有BLE作為額外的攻擊向量。

B. 車身控制模塊

特斯拉Model X中的BCM負責解鎖車門、控制車內閃電和觸發警報器。下圖顯示了BCM的PCB，并指出了模塊的不同區域以及與這項工作相關的組件。遙控鑰匙和BCM都使用英飛凌SLM97安全元件。不出所料，BCM包含一個Maxim Integrated 22 kHz收發器，使其能夠使用分布在車輛上的五個LF天線傳輸LF信號。此外，BCM包含三個德州電儀器 CC2541 BLE芯片（每個BLE天線一個），用于接收來自遙控鑰匙的數據。

BCM中的主處理器是飛思卡爾SPC5605，它與BCM中的其他組件以及汽車中的其他模塊進行通信。與BCM中其他組件的通信使用通用輸入和輸出（GPIO）接口以及UART和SPI等芯片間通信協議進行。與其他ECU的通信主要通過連接器X060和X061上的CAN和LIN接口進行。與本文最相關的CAN總線稱為主體CAN；它位于媒體控制單元（MCU）下方的診斷連接器（X179）上。

診斷連接器上的這些CAN總線的可用性允許與車輛中的ECU（例如BCM）進行交互。維修技術人員可以使用它來讀取診斷故障代碼（DTC）并將新的遙控鑰匙與汽車配對。大多數ECU實現了可通過CAN總線訪問的統一診斷服務（UDS）接口。

C. 診斷工具

Tesla Toolbox軟件是維修技術人員用于Model S和Model X車輛維護的診斷工具。Toolbox軟件還實現了遙控鑰匙配對程序，因此允許維修技術人員將新的遙控鑰匙與汽車配對。在正常情況下，該軟件在帶有USB-to-CAN接口的筆記本電腦上運行，該接口連接到車輛中的診斷連接器。如前所述，這允許軟件與車輛內部的ECU進行通信。下圖顯示了Toolbox軟件的屏幕截圖。從這個屏幕截圖中可以推斷出Toolbox軟件可以指示汽車喚醒遙控鑰匙，并且該軟件可以發現正在廣播的遙控鑰匙并喚醒。

要進行遙控鑰匙的配對，需要使用額外的 USB 到 BLE 適配器（USB-to-BLE），以便允許 Toolbox 軟件與遙控鑰匙進行通信。在正常的遙控鑰匙配對場景中，Toolbox 軟件協調配對過程并有效地充當遙控鑰匙和 BCM（車輛主控模塊）之間的安全通信橋梁。許多汽車都實現了兩種遙控鑰匙配對方案：一種是使用已有的配對遙控鑰匙，另一種是沒有可用的配對遙控鑰匙。前一種情況通常允許車主將額外的遙控鑰匙與他們的汽車配對，而無需訪問服務中心。后者通常被稱為所有密鑰丟失的情況，通常需要制造商特定的診斷工具來解決。對于特斯拉 Model X 車型，只有一種配對機制，并且不需要配對的遙控鑰匙。這樣做統一了配對協議，但也阻止了合法車主在不訪問服務中心的情況下將額外的遙控鑰匙與汽車配對。

與大多數汽車診斷工具一樣，特斯拉 Toolbox 軟件無法免費下載，但是有非官方版本在互聯網上流傳。根據當地法規，必須將軟件提供給獨立的維修店。在這些地點，可以在線從特斯拉購買短期訂閱。雖然最初的研究項目并沒有使用工具箱軟件，但后來通過在線的特斯拉逆向工程社區獲得了對負責遙控鑰匙配對的模塊的訪問權限。即使無法以預期的方式使用 Toolbox 軟件，但在逆向工程中詳細介紹的遙控鑰匙配對協議仍然具有很大的價值。

二、遙控鑰匙和BLE接口

Tesla Model X 的遙控鑰匙采用德州儀器的 CC2541 BLE SoC。在正常操作中，遙控鑰匙不會將自己廣播為可連接的BLE外圍設備，但會使用BLE廣播包向汽車傳輸數據（例如，RKE解鎖命令）。只有在遙控鑰匙重新啟動時，它會短暫地將自己廣播為可連接的BLE外圍設備。同樣，BCM可以使用LF數據包強制遙控鑰匙進行廣播。當遙控鑰匙廣播為可連接時，BLE中心可以連接到它并獲取可用服務及其相關特征的列表。

Model X的遙控鑰匙提供三個BLE服務：第一個服務包含用于讀取遙控鑰匙的一般信息（例如軟件版本和電池電量）的特性。第二個服務包含用于無線下載（OAD）的特性，這是德州儀器（TI）用于無線固件更新（OTA）的實現。換句話說，該OAD服務允許以無線方式更新CC2541 BLE SoC上的固件。第三個服務涉及應用協議數據單元（APDU）的使用，這些數據單元通常用于與智能卡進行通信。在這種情況下，該服務允許BLE客戶端與遙控鑰匙內的安全元件進行交互，這是在將新遙控鑰匙與汽車配對時使用的功能。

從攻擊者的角度來看，OAD和APDU服務都非常有趣。如果OAD固件更新機制沒有得到適當保護，攻擊者可能會濫用它將惡意固件映像上傳到CC2541 BLE SoC。APDU服務可能被濫用以向遙控鑰匙中的安全元件發送任意APDU命令。

A. 安全元件接口

安全元件，例如用于Model X遙控鑰匙的英飛凌SLM97CFX1M00PE，類似于智能卡。物理智能卡接口和APDU格式已經標準化為ISO-7816規范的一部分。在這種情況下，物理接口是不同的，因為遙控鑰匙包含在PG-VQFN-8-1封裝中的SLM97安全元件，但是接口信號與普通智能卡中使用的相同（GND、VCC、IO、RST和CLK）。輸入輸出(IO)信號承載了CC2541 BLE SoC和安全元件之間交換的所有信息(APDU)。

前圖顯示了可以在遙控鑰匙PCB上訪問IO信號的位置。通過將邏輯分析儀連接到此IO引腳，可以接收所有交換的APDU命令。該圖還顯示了一個ModelX遙控鑰匙，其導線焊接到大部分測試點，PCB上的過孔未被覆蓋。能夠接收在PCB上的各個組件之間傳輸信息的多個信號有助于了解系統的功能。例如，通過同時探測多個信號，確定了MAX2153E芯片接收到按鈕按下的信號，然后通過串行外設接口(SPI)向CC2541BLE SoC發送信號。之后，CC2541 BLE SoC向安全元件發送一個APDU命令，該命令返回一個16字節的響應。APDU響應稍后由CC2541廣播，是指示車輛執行操作（例如鎖定或解鎖）的令牌。

如前所述，CC2541為安全元件提供了一個接口，允許BLE客戶端通過APDU服務向安全元件發送APDU命令。APDU BLE服務包含四個主要特征：APDU命令、APDU數據、發送APDU和APDU響應。向安全元件發送APDU命令涉及將主APDU命令（通常為五個字節）寫入APDU命令特征。之后，可以將額外的APDU數據寫入APDU數據特征。寫入APDU命令和APDU數據后，可以通過將0x01寫入APDU發送特性來觸發將實際APDU命令發送到安全元件。當APDU響應可以從APDU數據特征中讀回時，APDU響應特征將通過通知發出信號。

通過BLE接口發送APDU命令并觀察響應和IO信號，可以發現CC2541在實現APDU指令字段（INS）時添加了一個阻止列表。換句話說，某些APDU命令，例如在按下按鈕后使用的命令，在通過BLE接口發送時會被CC2541阻止。這個阻止列表的實施旨在防止攻擊者通過BLE接口執行某些操作，例如請求有效的解鎖令牌。

B. OAD服務

德州儀器提供了兩個OAD示例實現。第一個實現在固件映像中添加了基于循環冗余校驗（CRC）的完整性校驗。第二個實現旨在通過在CTR模式下使用AES進行加密來提供固件機密性。此外，固件認證和完整性是基于AES-CBC-MAC提供的。

2018年，研究人員發現Aruba在默認（未受保護）OAD實現的基礎上實施了額外的密碼檢查。但是，這個密碼已經硬編碼在固件中，并在所有設備之間共享。盡管TI提供的示例實現已經存在多年，但是在2019年仍然存在嚴重漏洞。例如，AES-CTR實現存在缺陷，導致密鑰流每64個字節重復一次。在大多數情況下，這將允許攻擊者在不知道任何密鑰的情況下解密固件映像。此外，使用memcmp的非恒定時間實現檢查消息身份驗證標簽。這些示例表明，Model X遙控鑰匙上的OAD服務缺陷可能允許攻擊者覆蓋固件并獲得遠程代碼執行。

Toolbox 軟件可以用于更新遙控鑰匙固件，因此它包含了最新固件二進制文件的備份。此外，汽車中的大多數組件（包括遙控鑰匙）的固件都包含在信息娛樂系統的根文件系統中，因為它負責更新汽車中的所有組件。通過對二進制固件更新（1.5.1版）的粗略分析，很明顯固件映像以明文形式分發給 Model X 遙控鑰匙。固件映像使用與德州儀器提供的示例實現相同的標頭格式，但特斯拉在固件映像的末尾添加了一些額外的字段。固件以包含 16 位 CRC 值的 16 字節標頭開始。標頭后面是固件映像的實際代碼部分，并用 0xFF 字節填充到固定長度。最后，特斯拉添加了固件映像的 SHA1 哈希值，后跟一個 12 字節的magic值，其中包含兩個空格、文本表情符號 \(?_?)/ 和一個額外的空格。

在這個初始固件格式分析中，無法識別任何簽名或消息認證標簽，以保護固件的真實性。通過修改作為 BLE 廣播一部分的設備名稱（Tesla Keyfob），可以驗證這一發現。隨后，更新了 CRC 值和 SHA1 哈希摘要并執行了 OAD 協議。遙控鑰匙現在使用之前設置的設備名稱進行廣播，因此接受了修改后的固件。從這個實驗中可以清楚地看出，遙控鑰匙沒有驗證提供的固件二進制文件的真實性。

這種不安全的固件更新（或 OAD）實現允許攻擊者覆蓋 CC2541 SoC 執行的固件。實際上，這意味著能夠建立 BLE 連接的攻擊者將能夠在遙控鑰匙的 BLE SoC 上執行任意代碼，從而向安全元件發送任意 APDU 命令。然而，在正常操作期間，遙控鑰匙不會廣播可連接的 BLE 外圍設備。

三、BCM及其UDS接口

Model X 車型中的 BCM 連接到診斷連接器所暴露的 CAN 網絡上。維修技術人員可以通過該診斷連接器使用 UDS 協議通過 CAN 網絡與 BCM 進行交互。UDS 協議是一種常用的診斷通信協議，是 ISO-14229 標準的一部分。許多電子控制單元（ECU）實現了一個 UDS 服務器，允許客戶端與之交互。客戶端可以使用這些服務來執行診斷操作。

由于大多數電子控制單元至少部分符合 UDS 標準，因此列舉可用功能相對簡單。然而，識別哪些服務及其子功能允許執行特定于車輛的操作可能是一項乏味的工作。枚舉階段的目標是識別用于指示 BCM 向遙控鑰匙發送喚醒數據包的診斷操作。此外，還可以了解如何通過診斷連接器與 BCM 中的安全元件進行通信。

為了列舉 BCM 的 UDS 接口，設置了一個測試臺（ bench setup），包括 Model X BCM、一個工作臺電源和一個 USB 轉 CAN 接口。這使得研究人員可以使用 Python 和作為 Linux CAN 子系統一部分的開源工具輕松地與 BCM 進行通信。具體來說，使用了 socketCAN 和 CAN-utils 用戶空間工具以及 can-isotp 內核模塊和 python-can-isotp 庫。

A. 枚舉UDS服務器和服務

在大多數情況下，可以通過向傳輸仲裁ID（11位標識符）的每個可能值發送UDS請求并觀察響應來識別CAN網絡上的UDS服務器。具體來說，可以向DiagnosticSessionControl服務發送一個UDS請求，該服務是標準的一部分，因為它經常被實現。如果在相應的接收方仲裁ID（傳輸仲裁ID + 0x10）上收到回復，則可以假設UDS服務器存在于識別的地址或仲裁ID上。由于實驗設置只連接了一個ECU，因此可以確定識別的UDS服務器實際上是由BCM托管的UDS服務器。

確定了UDS服務器地址后，就可以枚舉已實現的服務。這可以通過向每個服務標識符發送一個空的UDS請求并觀察響應來實現。如果沒有收到響應，則沒有服務在偵聽選定的服務標識符。由于ISO-14229標準包含服務列表及其默認服務標識符，因此將服務標識符鏈接到服務目的通常很簡單。

從這個枚舉階段可以清楚地看出，Model X的BCM擁有多個UDS服務，這些服務允許執行各種診斷操作。假設想要執行的操作（向安全元件發送APDU命令，以及喚醒遙控鑰匙）將由RoutineControl服務作為例程來實現，并通過列舉UDS例程證實了這一假設。

B. 枚舉UDS例程

UDS RoutineControl 服務（服務標識符為0x31）允許UDS客戶端啟動/停止例程并請求例程結果。下圖展示了RoutineControl請求的結構。每個請求都包含服務標識符、欲執行的命令或子功能以及一個兩字節的例程標識符。某些例程需要額外的輸入數據，在ISO-14229規范中稱為routineControlOptionRecord。

可以通過為每個例程標識符發送UDS RoutineControl啟動請求消息并觀察UDS響應來枚舉有效或現有例程標識符。對于這些例程標識符中的許多，UDS服務可能會以否定響應代碼（NRC）進行響應。然而，由于這些NRC是UDS標準的一部分，它們可以幫助指導進一步的枚舉。例如，NRC值0x33對應于securityAccessDenied錯誤。此錯誤表明提供的例程標識符是有效的，但要使用此例程，必須首先使用SecurityAccess服務向UDS服務器進行身份驗證。同樣，NRC值為0x13的錯誤對應于不正確的MessageLengthOrInvalidFormat。此類錯誤表明具有提供的例程標識符的例程存在，但未提供正確的routineControlOptionRecord字節數。此信息可用于擴展枚舉過程以確定每個例程的正確輸入字節數。

雖然枚舉可用的例程標識符相對簡單，但識別每個例程的確切作用卻不是容易的任務。如前所述，枚舉的目標是確定負責向安全元件發送 APDU 命令的例程，以及允許向遙控鑰匙發送喚醒命令的例程。由于標準 APDU 命令至少包含五個字節，因此預計例程需要至少五個routineControlOptionRecord 字節。相比之下，喚醒遙控鑰匙的例程可能不需要任何額外的輸入，而不是請求啟動子功能。在初始的例程枚舉階段，已確定了 54 個例程，其中 11 個不需要任何額外的輸入，10 個需要超過 5 個字節的routineControlOptionRecord。

為了識別負責喚醒遙控鑰匙的例程，將 LF 天線連接到 BCM，并在附近放置了配對的遙控鑰匙。然后使用 Python 腳本為每個已識別的例程標識符發送例程啟動請求，同時掃描 BLE 設備。通過這種方式，能夠自動識別負責喚醒遙控鑰匙的 UDS 例程。通過對多個遙控鑰匙進行試驗，發現 LF 喚醒數據包包含一個標識符，因為它只能用于喚醒與 BCM 配對的遙控鑰匙。從 Toolbox 軟件的逆向工程中了解到，車輛識別號 (VIN) 用于派生一個 2 字節的汽車標識符，該標識符也存儲在遙控鑰匙中。該汽車標識符是喚醒消息的一部分，允許具有不同汽車標識符的遙控鑰匙簡單地忽略喚醒請求。同樣，為了識別用于與安全元件通信的例程，將邏輯分析儀連接到安全元件的 IO 線路。然后使用 Python 腳本發送例程啟動請求，其中包含所需的routineControlOptionRecord 字節。當邏輯分析器觸發并包含攻擊者作為routineControlOptionRecord 提供的數據時，攻擊者就知道可以使用哪個例程標識符來發送APDU 命令。如預期的那樣，可以使用例程的請求結果子功能來檢索安全元件的響應。

四、遙控鑰匙與汽車配對

在正常情況下，要將遙控鑰匙與汽車配對，車主需要安排服務預約。維修技術人員會通過 USB 轉 CAN 接口將筆記本電腦運行的 Tesla Toolbox 軟件連接到汽車上。此外，還會建立一個低功耗藍牙 (BLE) 連接，連接筆記本電腦和將與汽車配對的新遙控鑰匙。配對過程涉及兩個不同的部分或協議：首先提供新的遙控鑰匙，然后將其與汽車配對。在實踐中，這兩個協議通常由服務技術人員依次執行。在接下來的部分中，將詳細描述配置和配對協議。然后，將描述如何對安全元件本身執行的操作以及在協議中發現的問題進行逆向工程。

A. 配置協議

在配對過程的第一部分（稱為 provisioning ）中，Toolbox 軟件通過 BLE 連接與遙控鑰匙中的安全元件通信，并通過互聯網連接與 Tesla 操作的硬件安全模塊 (HSM) 進行通信。下圖顯示了供應協議中涉及的各方以及他們之間交換的消息。

該系統中使用的英飛凌 SLM97 安全元件有五個 RSA Slot。這些 Slot 中的每一個都可以存儲 2048 位 RSA 密鑰對以及關聯的證書。在上圖中，第一步包括在前兩個 Slot 中加載兩個特定證書（Tesla Root 和 Tesla APP）；這些證書在所有遙控鑰匙之間共享。在實踐中，新的遙控鑰匙在銷售時預先加載了這些證書，并鎖定了相關的 Slot，以防止它們被覆蓋。

之后，工具箱軟件將請求安全元件的唯一標識符，并向安全元件提供汽車的 VIN 號。此時，安全元件會為其余三個 Slot 中的每一個生成 RSA 密鑰對。對于每個 Slot，Tesla Toolbox 軟件會請求后端 HSM 生成使用屬于 Tesla 根 CA（Slot 0）的私鑰簽名的證書。每個證書都包含汽車的 VIN 號碼、安全元件的唯一標識符、為其生成的 Slot 和公鑰。據推測，此步驟背后的想法是確保在配對協議期間，汽車能夠驗證正在配對的遙控鑰匙的真實性。

最后，在所有證書生成并加載到安全元件后，三個Slot也被鎖定，防止內容被修改。完成此步驟后，Toolbox 軟件將自動啟動配對協議。

B. 配對協議

在遙控鑰匙配對過程的其余部分中，Toolbox 軟件充當車身控制模塊中的安全元件和遙控鑰匙中的安全元件之間的中央協調器和通信中繼。配對協議在下圖中進行了描述，并將對其進行詳細說明。

Toolbox 軟件啟動配對協議并將 BCM 安全元件生成的 16 字節配對質詢轉發到遙控鑰匙安全元件。遙控鑰匙 SE 使用來自Slot 2 的私鑰對質詢、SE ID 和來自Slot 3 的公鑰生成 RSA-PSS-SHA256 簽名。BCM SE 驗證簽名并生成五個 128 位 AES 密鑰。之后，BCM SE 將一個 magic 值附加到 AES 密鑰，并使用 RSA-OAEP 和來自Slot 3 的遙控鑰匙的公鑰對其進行加密。之后，遙控鑰匙可以解密這些 AES 密鑰，并驗證該 magic 值是否仍然存在。配對協議的其余部分由幾個步驟組成，用于確保雙方具有相同的對稱密鑰。為此，BCM SE 將使用 AES-ECB 加密一個 128 位塊，其中存在由 8 個（可能）隨機字節與固定字符串（key_auth）連接的明文。密文被發送回遙控鑰匙 SE，后者解密配對驗證質詢并確認固定字符串（key_auth）存在于明文中。最后，遙控鑰匙 SE 使用 AES-ECB 加密一個 128 位塊，其中明文由 BCM 生成的隨機輸入及其自身的隨機輸入組成；此令牌再次由 BCM 驗證。

如果驗證成功，遙控鑰匙 SE 將進入配對狀態，其中 SE 內的所有加密材料都被鎖定且無法修改。有一個據說可以將 SE 狀態恢復到其初始狀態的 APDU 命令，但此命令需要由后端 HSM 簽名的輸入，因此需要有效的 Toolbox 憑據。

C. 安全元件內部操作

如前所述，Toolbox 軟件主要用作 BCM SE 和遙控鑰匙 SE 之間的通信橋梁。盡管對 Toolbox 軟件進行逆向工程提供了有關配對協議的寶貴信息，但僅了解安全元件執行的操作還不夠。

具體來說，Toolbox 軟件揭示了正在使用的 APDU 命令，而變量名稱和數據的含義則提供了一些提示。因此，要完全理解配對協議，需要對安全元件內執行的操作進行逆向工程。這是通過使用標準智能卡讀卡器、自定義PCB 和 Python 腳本，同時以黑盒方式與 BCM SE 和遙控鑰匙 SE 接口進行交互實現的。

例如，通過分析工具箱軟件，很明顯配對協議將從 BCM SE 生成配對挑戰開始。通過向 BCM SE 發送相同的 APDU 命令并觀察響應，可以輕松復制此步驟。之后，可以將此挑戰發送給未配對的遙控鑰匙 SE。通過剖析遙控鑰匙 SE 的響應，可以清楚地看出它由 BCM 質詢、SE 標識符、來自 Slot 2 和 3 的公鑰以及 256 字節的未識別信息組成。根據獲得的信息，可以假設未識別的數據實際上是 RSA 簽名。使用多種組合的腳本檢查輸入數據和 RSA 簽名方案，驗證了這一假設。使用這種猜測和確定的方法，能夠恢復安全元件執行的所有操作。

D. 小結

協議本身存在明顯的漏洞。在正常情況下，必須先提供新的遙控鑰匙，然后才能將其與汽車配對。因此，在實踐中，配置和配對步驟通常由同一服務技術人員連續執行。然而，全面了解這些協議的工作原理后，很明顯可以跳過供應協議。在配置期間生成并存儲在遙控鑰匙安全元件中的證書在配對期間永遠不會發送到汽車。因此，汽車將無法驗證證書以及配對的遙控鑰匙的真實性。前文演示了如何替換遙控鑰匙中的安全元件，從而允許跳過配置協議。這使攻擊者能夠將惡意遙控鑰匙與汽車配對，而無需有效的服務技術人員帳戶。

五、PoC

通過執行以下步驟，可以將本文中概述的安全問題組合成攻擊：

1.遠程喚醒與目標車輛配對的遙控鑰匙：

? LF 喚醒數據包可以由 BCM 發送；

? 數據包包含一個基于 VIN 的標識符，可以從擋風玻璃上獲得。

2.使用 BLE 連接到目標遙控鑰匙并執行固件更新：

? 惡意更新禁用了在 APDU 服務上實施的阻止列表。

3.使用 APDU 服務從安全元件請求 RKE 解鎖令牌。

4.使用獲得的解鎖令牌解鎖汽車。

5.連接到診斷連接器并將遙控鑰匙與汽車配對。

6.攻擊者現在有新鑰匙可以用來解鎖和啟動汽車，就像原來的鑰匙一樣。

為了證明研究結果的適用性，實現了一個可以執行上述步驟的便攜式概念驗證設備。研究者重用和修改了特斯拉組件，而不是定制硬件。雖然定制設計可能會導致更便宜的材料清單、更小的設備或更長的范圍，但它需要額外的開發時間和逆向工程。盡管如此，下圖中所示的PoC 設備可以裝在一個背包中，并且可以使用價值約 250 美元的組件構建。

更詳細地說，攻擊者首先必須喚醒目標車輛的遙控鑰匙，使其廣播為可連接的 BLE 外圍設備。為此，攻擊者需要發送一個 LF 喚醒數據包，其中包含從 VIN 派生的汽車標識符。然而，VIN 是公共信息，因為它可以從駕駛員一側的擋風玻璃上讀取。通過啟動喚醒 UDS 例程，攻擊者可以使用修改后的 BCM 發送此 LF 喚醒數據包，并且可以利用 BCM 和 Model X 中使用的標準天線在幾米的范圍內喚醒遙控鑰匙。一旦遙控鑰匙被廣播為可連接，攻擊者就可以連接到它并推送惡意固件更新。更新過程本身大約需要 1.5 分鐘，但可以在更長的距離（BLE 范圍）內執行。惡意固件更新完成后，攻擊者可以使用 APDU 服務從安全元件請求有效的 RKE 令牌。接下來，攻擊者使用此 RKE 令牌解鎖汽車并訪問位于中央顯示屏下方的車輛診斷連接器。然后，攻擊者將自己的設備連接到此診斷接口，以協調目標車輛和修改后的遙控鑰匙之間的配對協議。一旦與汽車配對成功，攻擊者就可以使用遙控鑰匙解鎖并啟動汽車。其他安全功能，例如pin-to-drive（默認禁用），不能防止攻擊者創建允許永久物理訪問汽車的遙控鑰匙，但可以防止攻擊者駕駛離開車輛。

A. 模擬安全元件

為了實施完整的 PoC 攻擊，攻擊者需要能夠遠程喚醒目標遙控鑰匙。為此，攻擊者修改了 BCM 中的 VIN 號，因為 BCM 發送的喚醒命令是根據 VIN 號生成的。攻擊者并沒有使用定制硬件來執行這些任務，而是惡意利用了遙控鑰匙和 BCM 中的其他組件，利用它們在安全元件中的隱式信任。遙控鑰匙中的 CC2541 通過通用異步收發器 (UART) 外設與安全元件進行交互。同樣，BCM 中的 SPC56 使用其中一個 UART 外設與安全元件通信。在這兩種設備中，攻擊者可以從板上移除安全元件，并使用 USB 到 UART 橋接器模擬其行為。具體來說，攻擊者使用了 Silicon Labs CP2102N USB 到 UART 橋接器，因為它支持非標準波特率（需要 21500 的波特率）。此外，CP2102N 還帶有額外的 GPIO 引腳，可以用于檢測傳入的 RST 信號以響應復位 (ATR)。

針對 BCM 和遙控鑰匙，在 Raspberry Pi 上的 Python 腳本中實現了所需的安全元件功能，并連接了 USB 到 UART 外圍設備。為了實施攻擊的第一步，修改了 BCM 以便喚醒與用戶可配置 VIN 號碼配對的遙控鑰匙。為了實現攻擊的第五步，修改了遙控鑰匙使其能夠在沒有配置的情況下與汽車配對。由于目標是模擬遙控鑰匙中的安全元件，因此同一遙控鑰匙可以無限期地使用并與多輛車配對。

B. 暴力固件修改

遙控鑰匙中的 CC2541 BLE 芯片提供了一個公開的 APDU 服務，允許將 APDU 命令發送到包含在遙控鑰匙中的安全元件。然而，APDU 服務實現了一個阻止列表，即不能通過 BLE APDU 服務使用的 APDU 指令列表。為了繞過這個限制，使用了 CC2541 芯片上實現的空中下載服務，覆蓋了庫存固件。這樣就可以將自定義固件映像推送到遙控鑰匙以獲得對安全元件的不受限制的訪問。 

實現這個目標有兩個選擇。一種是從頭開始編寫自定義固件映像，只實現執行攻擊所需的功能。這需要熟悉開發工具和目標平臺。另一種選擇是使用庫存固件并稍微修改它以刪除 APDU 阻止列表。由于無法訪問庫存固件的源代碼，所以需要修改已編譯的二進制代碼。本文選擇了第二種方法，因為這不需要學習開發環境。此外，這種方法會導致惡意固件映像保留庫存固件中存在的所有功能。

通過對固件映像進行逆向工程，并確定阻止列表的確切實施位置，可以定位二進制文件中的偏移量以進行修補。雖然大多數靜態逆向工程工具支持底層 8051 指令集，但它們不支持 CC2541 中實現的自定義指令。因此，研究者選擇了自動化方法來實現固件修改。

基于暴力破解的固件修改方法在 8 位 8051 指令集中非常適用。最常見的實現方法是一組條件 if 語句。這些 if 語句被編譯成一組指令，其中可能包含需要比較的文字和條件跳轉。

在這種情況下，所采用的方法是將固件中發生的“如果累加器非零 (JNZ) 指令 (0x70) 跳轉”修改為“如果累加器為零 (JZ) 指令 (0x60) 則跳轉”。使用 CC 調試器將修改后的固件刷新到遙控鑰匙，通過 BLE 連接到 keyfob 并發送 APDU 命令。如果收到響應，則表明成功繞過阻止列表，否則繼續下一次出現 JNZ 指令。此過程可以輕松實現自動化，并在數小時內找到解決方案。

一旦確定了允許發送目標 APDU 命令的偏移量，就可以反匯編實現塊列表周圍的指令。以上顯示了實現阻止列表的 8051 匯編指令以及禁用阻止列表的同一部分代碼。生成惡意固件映像后，更新了 CRC 和 SHA1 哈希以獲得有效的固件二進制文件，該文件可以在攻擊的第二步中與 OAD 一起使用。在第三步中，該惡意固件允許使用未過濾的 APDU 服務從安全元件中讀取有效的 RKE 令牌。該令牌可以作為 BLE 廣播包傳輸到汽車上，以解鎖汽車。

六、結論

此項工作對電動汽車的被動無鑰匙進入和啟動系統進行了全面的安全分析，該系統依賴于在通用標準認證的安全元件中實現的安全公鑰和對稱密鑰原語。本文提供了所有相關組件的詳細描述，并證明了這些下一代遙控鑰匙增加的復雜性（主要是由于使用了實現藍牙技術的復雜微控制器）可能會引入新的攻擊向量。通過利用這些攻擊向量，可以利用標準認證安全元素不足的問題來獲得安全產品。事實上，此攻擊并沒有利用安全元素本身的任何弱點，而是利用了其使用方式。雖然本項工作中的分析是針對特斯拉Model X 進行的，但所提出的技術和方法對于評估其他汽車產品或其他基于硬件的安全系統也同樣適用。