解读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改款等产品线中，表明了这项技术在未来几年对特斯拉的战略重要性。

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，还会有其他方法可以跟踪汽车，该风险可接受。

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”回车退出应用程序。

特斯拉授权重放攻击中也使用到了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.

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柱，这也为攻击者实施密钥注册提供了机会。

参考链接：

[1]https://www.tesla.com/ownersmanual/model3/en_us/GUID-E004FAB7-1C71-448F-9492-CACF301304D2.html

[2]https://www.beaconzone.co.uk/blog/tesla-model-3-is-an-ibeacon/

[3]https://github.com/trifinite/temparary

[4]https://github.com/Adam-Langley/pybleno

[5]https://teslabtapi.lexnastin.com/docs/start Tesla BluetoothLE API（非官方）

[6]https://zhuanlan.zhihu.com/p/399976838特斯拉解锁车的第四种方法

[7]https://www.anquanke.com/post/id/197750车联网安全系列——特斯拉iBeacon隐私泄露

[8]https://mherfurt.de/tags/trifinite.org/

[9]https://www.youtube.com/watch?v=IHZmMbu5sRo&ab_channel=MCH2022

[10]https://teslabtapi.lexnastin.com/docs/intro

[11]https://www.youtube.com/watch?v=vWM98f3-vvc&feature=youtu.be&ab_channel=trifinite