針對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 軟件，但在逆向工程中詳細介紹的遙控鑰匙配對協定仍然具有很大的價值。

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 外圍器材。

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. 小結

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

透過執行以下步驟，可以將本文中概述的安全問題組合成攻擊：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 進行的，但所提出的技術和方法對於評估其他汽車產品或其他基於硬件的安全系統也同樣適用。

閱讀原文：[轉譯]針對Model X無鑰匙系統的遠端攻擊