This paper will walk you through the proof-of-concept and technical details of exploitation for
IOActive’s recent NFC relay attack on the newest Tesla vehicle, the Model Y.
To successfully carry out the attack, IOActive reverse-engineered the NFC protocol Tesla uses
between the NFC card and the vehicle, and we then created custom firmware modifications that
allowed a Proxmark RDV4.0 device to relay NFC communications over Bluetooth/Wi -Fi using the Proxmark’s BlueShark module.
The Proxmark (pictured below) is a powerful general-purpose RFID tool the size of a deck of
cards, designed to snoop, listen, and emulate everything from low-frequency (125kHz) to highfrequency (13.56MHz) tags. However, this is not a case wherein we could simply use the tool to execute commands. This application required knowledge of the Proxmark’s internals, as well as the ability to perform C-language firmware modifications.
Before we begin with the specifics, let’s talk about NFC relay attacks. It’s well-known in the
vehicle security industry that NFC relay attacks (as well as Radio Frequency relay attacks) are a
serious issue, and that they’re currently being used to steal cars. This type of attack consists of
relaying cryptographic material between the vehicle and the virtual key (NFC card or
smartphone).
The following is an oversimplified illustration of Tesla’s NFC feature:
To better understand what’s going on between the vehicle and the NFC card, we must reverseengineer the protocol. For this attack, IOActive used the Proxmark RDV4.0 device to sniff these communications. The next image is the result, illustrating the NFC communication that takes place while opening the vehicle with the NFC card. The packets outlined in blue are the lowlevel NFC communications, and those outlined in red are the application layer (APDUs):
The low-level communications (blue) are not relevant to this process, since they are standard
protocol stuff for the type of card being used. However, the application layer data is where we
need to focus our attention, as it’s where we find Tesla’s proprietary protocol.
In block 1 of the graphic, the reader is sending the APDU to the Tesla card to select the type of
application. This is the common procedure with smartcards for selecting the so-called AID
(Application Identifier). In this case, the vehicle is asking for the identifier used for the virtual car
key used in smartphones. Since we’re sniffing using the physical Tesla NFC card, the card will
respond with 6d00 (invalid). If we were sniffing using the smartphone as a key, it would answer
with 9000 (valid).
In block 2, the vehicle is asking for the identifier used for the virtual car key used by the Tesla
NFC card. Since we’re sniffing using the physical Tesla card, the card will respond with 9000. At
this point, the card will select that application and wait for the challenge from the reader.When
the vehicle receives the 9000 response from the card, it believes it is speaking to a Tesla NFC
card. The vehicle sends the cryptographic challenge to the card (block 3) and waits for a valid
response to that challenge.
At this point, the Tesla NFC card, which basically is a smartcard, will calculate the cryptographic
response for the challenge received from the vehicle. Since this cryptographic calculation takes
a significant amount of time (while we’re probably talking about a mere few milliseconds, it’s still “too much time”), the card will request more time from the vehicle that is waiting for the answer, in effect saying, “hey, don’t give up on me, just give me some time while I calculate the crypto response.”
This “need more time” message makes up the content going back and forth between the card
and the vehicle in block 4 of the graphic. This message is normally known as a Waiting Time
eXtension (WTX).
Finally, the card will send the cryptographic response calculated from the previously received
challenge. If this response is valid, the car will open the doors and allow the user to drive the car (depending on the vehicle’s configuration – we’ll talk about this later).
This provided us with all of the required knowledge to attempt an attack. However, we still need answers to a few more questions:
- Will it work to conduct the relay attack over
Bluetooth and Wi-Fi, requiring much more time for relayed communications between the vehicle and the card, or will it take too much time? - Are we missing something else in the protocol that
would prevent the relay attack? - How close does the attacker have to be to the
victim’s card?
The only way to answer these questions is to attempt an attack.
This relay attack requires two attackers; in this case, one of the attackers will be using the
Proxmark device at the vehicle’s NFC reader, and the other can use any NFC-capable device
(such as a tablet, computer, or for the purposes of this example, a smartphone) close to either
the victim’s Tesla NFC card or smartphone with the Tesla virtual key. The Proxmark and the
second attacker’s smartphone can communicate via Bluetooth using the BlueShark module for
the Proxmark RDV4.0, or even via Wi-Fi, connecting the Proxmark to a tiny computer like a
Raspberry Pi or similar with Bluetooth while the Raspberry Pi connects to the second attacker’s
smartphone via Wi-Fi.
The custom code in our Proxmark firmware must enable the device to handle the low-level NFC
protocol between the vehicle and the Proxmark, and facilitate the following workflow:
- Upon receiving the Select AID from the vehicle, the Proxmark will respond with the correct value.
- The Proxmark then receives the Challenge and relays it to the second attacker’s phone, which is
close to the victim’s Tesla NFC card. - The second attacker’s smartphone will communicate via NFC with the victim’s card, select the AID,
and send the Challenge received from the Proxmark. - The Tesla NFC card will respond with the crypto response, and this will be relayed to the Proxmark
from the second attacker’s smartphone. - The Proxmark will receive the crypto response and send it to the vehicle’s reader.
Perfect – we can start writing the code for the Proxmark. We’ll need to program the Proxmark
to act as an emulator, as it is going to emulate the Tesla NFC card and handle all the
aforementioned tasks while attempting to unlock the vehicle. In addition, the Proxmark’s
Bluetooth interface was necessary for external communications.
The Proxmark GitHub repository explains how to write a standalone module for the Proxmark
RDV4.0: https://github.com/RfidResearchGroup/Proxmark3/wiki/Standalone-mode
The Proxmark’s hardware provides an ARM processor in which our code runs, and that code
needs to facilitate interaction with the Bluetooth chip over an UART interface. We also need
communication via the Proxmark’s FPGA, which handles all of the radio frequency
modulation/demodulation for NFC communication.
The Proxmark project provides certain APIs for communication with the Bluetooth chip and
FPGA, which we’ll use during the programming phase. Third-party standalone modules like
hf_reblay can help to more quickly understand how this communication works.
One of the very first things that the code does is to set up the Proxmark to emulate a 14443 card, and to perform initialization and FPGA setup:
Next, the code receives what is sent from the vehicle’s reader, usingGetIso14443aCommandFromReader(). Immediately after reading the data coming from theradio, it checks to see if there is available data in the UART port used for the Bluetooth chip withusarT_rxdata_available(). If there is data, then it sends one last WTX to the reader andread the data coming from the Bluetooth interface. The data received over Bluetooth will bealways the crypto response from the victim’s card.
The code then handles the data that it received over NFC, first checking the very first bytes and
handling the type of low-level NFC message received in the earlier stages of the
communication.
If it’s just receiving application layer messages (APDUs), the code will handle those too:
Once we’ve received the challenge from the vehicle’s reader, we need to send that data to the
second attacker’s smartphone using the Bluetooth interface. We’ll copy the content of the buffer received, send it to the Bluetooth chip through the UART, and process that data in the second attacker’s smartphone application.
Also, once we’ve received the crypto response over Bluetooth, we’ll need to send that to the
vehicle’s reader via NFC.
Just before we send anything over NFC, we must add the CRC bytes, prepare the modulation
with prepare_tag_modulation() and then send the data over NFC with
EmSendPrecompiledCmd().
The Proxmark code is more-or-less ready, but we do need to create additional code to run on
the second attacker’s smartphone, which will be close to the victim’s Tesla NFC card. That
application will need NFC, Bluetooth, and Wi-Fi capabilities to perform the relay attack.
When the Android application running on the second attacker’s smartphone receives the
challenge from the Proxmark via Wi-Fi or Bluetooth, it will relay that challenge to the victim’s
card over NFC, then read the crypto response and send it back to the Proxmark.
The following proof-of-concept video shows the relay attack performed with a Proxmark
connected with a USB cable to the computer so that you can see all of the logs on the screen in
real time. The Tesla NFC card is also placed in an NFC reader connected to another laptop,
which connects over Bluetooth with the Proxmark for the relay attack.
In the second video, we demonstrate the attack in a more real-world scenario using the Proxmark and the smartphone application. The first attacker waits for the victim to leave the car, then gets close to the vehicle’s reader with the Proxmark. In the meantime, the second attacker will get closer to the victim and use a smartphone to read the Tesla NFC card in the victim’s pocket. This demonstration answers the questions we previously asked:
• Time limitation seems to be very permissive, and it was possible to perform this attack via Bluetooth from several meters away, as well as via Wi-Fi with much greater distances. We believe it may be possible to make it work via the Internet as well.
• Only one challenge/response is required to open and drive the car when the “PIN to Drive” feature is not enabled in the vehicle.
• One of the attackers does have to be very close to the victim’s card. This distance might change depending on multiple factors, but a distance of 4 cm or less might be fairly precise when using a smartphone. Using a more specialized, high power device might make this distance bigger, even more than 60cm: https://eprint.iacr.org/2006/054.pdf. (however, 4cm can be enough in some scenarios when the victim is distracted, like a crowded night club/disco. If the attacker at the vehicle is ready at the driver’s door, then contact with the victim’s NFC
card needs to only be for one to two seconds to be effective.)
There are several ways Tesla could fix or mitigate this issue, although they may require hardware changes, some examples could be the following:
• As we previously mentioned, time limitation is key. If the system can be more precise with its timing while waiting for a crypto response, it would make it much harder to exploit these issues over Bluetooth/Wi-Fi. However, if the system is too restrictive on timing, legitimate users may have problems when trying to unlock or start the car (e.g. if their smartphone is under load or in battery saving mode).
• Count the WTX packets and reject more than what is necessary. This is similar to the above solution, but instead of counting time, the system would count the number of WTX packets.
Source:
https://dl.packetstormsecurity.net/papers/general/NFC-relay-TESlA_JRoriguez.pdf
Stay connected