本研究是针对特斯拉 Model X 无钥匙系统的实用安全评估。所分析的无钥匙系统采用了由通用标准认证的安全元件实现的安全对称密钥和公钥密码原语。本文记录了该系统的内部工作原理，包括遥控钥匙、车身控制模块和配对协议。此外，还介绍了相关逆向工程技术和几个安全问题。其中，遥控钥匙固件更新机制和遥控钥匙配对协议中发现的问题导致绕过了所有已实施的加密安全措施。此研究还开发了一种完全远程的概念验证攻击（PoC），允许在几分钟内进入车辆内部并配对修改后的遥控钥匙，从而启动汽车。该攻击不是中继攻击，因为其允许攻击者随时随地启动汽车。

用户可以将遥控钥匙和车身控制模块 (BCM) 视为解锁和启动 Tesla Model X 的主要组件。实际上，还涉及其他车辆组件（例如驱动逆变器）。用户还可以使用配套的智能手机应用程序解锁和启动汽车。汽车只会执行先前与汽车配对的遥控钥匙请求的操作。要将遥控钥匙与汽车配对，维修技术人员可以使用 Tesla Toolbox 软件。遥控钥匙可用于通过按下按钮来锁定和解锁汽车，这被称为远程无钥匙进入 (RKE，Remote Keyless Entry)。此外，被动无钥匙进入和启动 (PKES，Keyless Entry and Start) 功能可确保在遥控钥匙接近时，汽车将自动解锁并启动。

下图显示了 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作为额外的攻击向量。

特斯拉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）接口。

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命令。

安全元件，例如用于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接口执行某些操作，例如请求有效的解锁令牌。

德州仪器提供了两个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 库。

在大多数情况下，可以通过向传输仲裁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例程证实了这一假设。

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) 连接，连接笔记本电脑和将与汽车配对的新遥控钥匙。配对过程涉及两个不同的部分或协议：首先提供新的遥控钥匙，然后将其与汽车配对。在实践中，这两个协议通常由服务技术人员依次执行。在接下来的部分中，将详细描述配置和配对协议。然后，将描述如何对安全元件本身执行的操作以及在协议中发现的问题进行逆向工程。

在配对过程的第一部分（称为 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 软件将自动启动配对协议。

在遥控钥匙配对过程的其余部分中，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 凭据。

如前所述，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 签名方案，验证了这一假设。使用这种猜测和确定的方法，能够恢复安全元件执行的所有操作。

协议本身存在明显的漏洞。在正常情况下，必须先提供新的遥控钥匙，然后才能将其与汽车配对。因此，在实践中，配置和配对步骤通常由同一服务技术人员连续执行。然而，全面了解这些协议的工作原理后，很明显可以跳过供应协议。在配置期间生成并存储在遥控钥匙安全元件中的证书在配对期间永远不会发送到汽车。因此，汽车将无法验证证书以及配对的遥控钥匙的真实性。前文演示了如何替换遥控钥匙中的安全元件，从而允许跳过配置协议。这使攻击者能够将恶意遥控钥匙与汽车配对，而无需有效的服务技术人员帐户。

通过执行以下步骤，可以将本文中概述的安全问题组合成攻击：

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（默认禁用），不能防止攻击者创建允许永久物理访问汽车的遥控钥匙，但可以防止攻击者驾驶离开车辆。

为了实施完整的 PoC 攻击，攻击者需要能够远程唤醒目标遥控钥匙。为此，攻击者修改了 BCM 中的 VIN 号，因为 BCM 发送的唤醒命令是根据 VIN 号生成的。攻击者并没有使用定制硬件来执行这些任务，而是恶意利用了遥控钥匙和 BCM 中的其他组件，利用它们在安全元件中的隐式信任。遥控钥匙中的 CC2541 通过通用异步收发器 (UART) 外设与安全元件进行交互。同样，BCM 中的 SPC56 使用其中一个 UART 外设与安全元件通信。在这两种设备中，攻击者可以从板上移除安全元件，并使用 USB 到 UART 桥接器模拟其行为。具体来说，攻击者使用了 Silicon Labs CP2102N USB 到 UART 桥接器，因为它支持非标准波特率（需要 21500 的波特率）。此外，CP2102N 还带有额外的 GPIO 引脚，可以用于检测传入的 RST 信号以响应复位 (ATR)。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！