本文将向您介绍关于IOActive最近对特斯拉最新车型Model Y发起的NFC中继攻击的概念验证和技术细节。为了成功实施攻击，IOActive反向设计了特斯拉在NFC卡和车辆之间使用的NFC协议，然后我们创建了自定义固件修改，允许Proxmark RDV4.0设备使用Proxmark的BlueShark模块通过蓝牙/Wi-Fi中继NFC通信。Proxmark（如下图所示）是一个强大的通用RFID工具，相当于一副卡片的大小，用于窥探、监听及模拟从低频（125kHz）到高频（13.56MHz）标签的所有内容。然而，我们不能简单地使用该工具来执行命令。需要了解Proxmark的内部结构，以及执行C语言固件修改的能力。
在我们开始讨论具体问题之前，让我们来谈谈NFC中继攻击。在车辆安全行业中，NFC中继攻击（以及射频中继攻击）是一个严重的问题，目前广泛的被利用于偷车。这种类型的攻击包括在车辆和虚拟钥匙（NFC卡或智能手机）之间传递加密材料。
以下是特斯拉NFC功能的简化说明：
为了更好地了解车辆和NFC卡之间的情况，我们必须对协议进行逆向工程。对于此次攻击，IOActive使用Proxmark RDV4.0设备嗅探这些通信。下图是结果，说明了在使用NFC卡打开车辆时发生的NFC通信。蓝色所示的数据包是低层NFC通信，红色所示的是应用层（APDU）：
低层通信（蓝色）与此过程无关，因为它们是所用卡类型的标准协议。而应用层数据是我们需要集中注意力的地方，因为此处可发现特斯拉专有协议。
在上图的框1中，读取器向特斯拉卡发送APDU用以选择应用类型。这是智能卡选择所谓AID（应用标识符）的常见过程。在本例中，车辆请求智能手机中使用的虚拟汽车钥匙的标识符。由于我们正在使用物理特斯拉NFC卡进行嗅探，该卡将以6d00（无效）响应。如果我们用智能手机作为钥匙进行嗅探，它会响应9000（有效）。
在框2中，车辆请求特斯拉NFC卡使用的虚拟汽车钥匙所使用的标识符。由于我们正在使用物理特斯拉卡进行嗅探，因此该卡将响应9000。此时，该卡将选择该应用程序并等待读取器的挑战。当车辆收到来自该卡的9000响应时，它认为自己正在与特斯拉NFC卡通话。车辆向卡发送加密质询（框3），并等待对该质询的有效响应。
此时，特斯拉NFC卡（基本上是智能卡）将计算从车辆收到的挑战的密码响应。由于这种加密计算需要大量的时间（虽然可能几毫秒，但这仍然是“过多的时间”），因此卡会向等待响应的车辆请求更多的时间，实际上是在说，“嘿，不要放弃我，给我一些时间，让我计算加密响应。”
这条“需要更多时间”的消息构成了在上图的框4中卡和车辆之间来回的内容。这个消息通常被称为等待时间扩展(WTX)。
最后，卡片将发送根据先前接收的挑战计算出的密码响应。如果这个响应是有效的，汽车将打开车门，允许用户驾驶汽车(取决于车辆的配置-我们将在后面讨论这个)。
这为我们提供了进行攻击所需的所有知识。然而，我们仍然需要更多问题的答案：
-
通过蓝牙和Wi-Fi进行中继攻击，需要大量的时间在车辆和卡之间进行中继通信，会不会需要的时间太长？
-
我们是否遗漏了协议中防止中继攻击的内容？
-
攻击者必须离受害者的卡有多近？
要回答这些问题，唯一方法就是尝试攻击。
这种中继攻击需要两名攻击者；在本例中，其中一名攻击者将在车辆的NFC读取器处使用Proxmark设备，另一名攻击者可以使用任何NFC功能的设备（例如平板电脑、计算机，或者就本例而言，智能手机）靠近受害者的特斯拉NFC卡或带有特斯拉虚拟钥匙的智能手机。Proxmark和第二个攻击者的智能手机可以使用Proxmark RDV4.0的BlueShark模块通过蓝牙进行通信，甚至可以通过Wi-Fi进行通信，将Proxmark连接到一台小型计算机，如Raspberry Pi或具有蓝牙功能的微型计算机上，而Raspberrry Pi则通过Wi-Fi连接到第二个攻击者的智能手机上。
Proxmark固件中的自定义代码必须使设备能够处理车辆和Proxmark之间的低层NFC协议，并促进以下工作流程：
1.在收到车辆发出的select AID信号后，Proxmark将以正确的值进行响应。
2.然后，Proxmark接收挑战并将其转发给第二个攻击者的手机，该手机靠近受害者的特斯拉NFC卡。
3.第二个攻击者的智能手机将通过NFC与受害者的卡进行通信，选择AID，并发送从Proxmark收到的挑战。
4.特斯拉NFC卡将以加密响应进行响应，然后从第二个攻击者的智能手机转发到Proxmark。
5.Proxmark将接收加密响应并将其发送到车辆的读取器。
我们可以开始编写Proxmark的代码了。需要对Proxmark进行编程，使其充当为模拟器，因为它将模拟特斯拉NFC卡，并在尝试解锁车辆的同时处理所有上述任务。此外，Proxmark的蓝牙接口是外部通信所必需的。
Proxmark GitHub存储库解释了如何为Proxmark RDV4.0编写独立模块：
https://github.com/RfidResearchGroup/Proxmark3/wiki/Standalone-mode.
Proxmark的硬件提供了一个ARM处理器，我们的代码在其中运行，该代码需要通过UART接口与蓝牙芯片进行交互。还需要通过Proxmark的FPGA进行通信，该FPGA处理NFC通信的所有射频调制/解调。
Proxmark项目提供了某些用于与蓝牙芯片和FPGA通信的API，我们将在编程阶段使用这些API。像hf_reblay这样的第三方独立模块有助于更快地了解这种通信的工作原理。
该代码首先做的事情之一是设置Proxmark来模拟14443卡，并执行初始化和FPGA设置：
接下来，代码使用GetIso14443aCommandFromReader（）接收从车辆读取器发送的内容。在读取来自无线电的数据后，它立即使用usarT_rxdata_available()检查用于蓝牙芯片的UART端口中是否有可用的数据。如果有数据，那么它向读取器发送最后一个WTX，并读取来自蓝牙接口的数据。通过蓝牙接收的数据将始终是受害者卡的加密响应。
然后，代码处理通过NFC接收的数据，首先检查第一个字节，并处理在通信的早期阶段接收的低级别NFC消息的类型。
如果只是接收应用层消息（APDU），代码也会处理这些消息：
一旦我们收到了来自车辆读取器的挑战，我们需要使用蓝牙接口将数据发送到第二个攻击者的智能手机上。我们将复制接收到的缓冲区内容，通过UART将其发送到蓝牙芯片，并在第二个攻击者的智能手机应用程序中处理这些数据。
此外，一旦我们通过蓝牙接收到加密响应，我们需要通过NFC将其发送到车辆的读取器。
在我们通过NFC发送任何数据之前，我们必须添加CRC字节，使用prepare_tag_modulation（）准备调制，然后使用EmSendPrecompiledCmd（）通过NFC传输数据。
Proxmark代码差不多已经准备就绪了，但我们需要创建额外的代码在第二个攻击者的智能手机上运行，该智能手机将接近受害者的特斯拉NFC卡。该应用程序将需要NFC、蓝牙和Wi-Fi功能来执行中继攻击。
当第二个攻击者的智能手机上运行的Android应用程序通过Wi-Fi或蓝牙接收到来自Proxmark的挑战时，它将通过NFC将该挑战转发到受害者的卡上，然后读取加密响应并将其发送回Proxmark。
以下图片展示了通过USB电缆连接到计算机的Proxmark进行的中继攻击，以便实时查看所有日志。特斯拉NFC卡还放置在一个NFC读取器中，该读取器连接到另一台笔记本电脑，笔记本电脑通过蓝牙与Proxmark连接，以进行中继攻击。
在图片中，我们将使用Proxmark和智能手机应用程序在更真实的场景中演示了攻击。第一个攻击者等待受害者离开汽车，然后用Proxmark接近车辆的读取器。与此同时，第二名攻击者将靠近受害者，并使用智能手机读取受害者口袋中的特斯拉NFC卡。
本演示回答了我们之前提出的问题：
- 时间限制似乎非常宽松，可以在几米外通过蓝牙以及更远距离的Wi-Fi进行攻击。我们相信通过互联网也可以实现。
- 当车辆中未启用“PIN to drive”功能时，打开和驾驶车辆只需要一个挑战/响应。
- 其中一名攻击者必须非常靠近受害者的卡片。这个距离可能会因多种因素而改变，但使用智能手机时，距离可能要精确到4厘米或更小的距离。使用更专业的高功率设备可能会使距离更大，甚至超过60cm：
特斯拉有几种方法可以解决或缓解这一问题，尽管它们可能需要更换硬件，但可以列举以下示例：
- 正如我们之前提到的，时间限制是关键。如果系统在等待加密响应时能够更加精确地确定时间，那么通过蓝牙/Wi-Fi利用这些问题将变得更加困难。然而，如果系统对时间限制太多，合法用户在尝试解锁或启动汽车时可能会遇到问题（例如，如果他们的智能手机负载不足或处于节电模式）。
- 清点WTX数据包，并拒绝超过必要数量的数据包。这与上述解决方案类似，但系统将计算WTX数据包的数量，而不是计算时间。
