The researcher (and, according to email correspondence from NCCGroup, a fellow Autopian reader, so thanks!) Sultan Qasim Khan (actually, he’s a Principal Security Consultant and Researcher) demonstrated how the hack can work as he unlocks, starts, and drives off a Tesla Model Y using a laptop connected to a relay device, which in turn was in contact with another remote relay device that was in communication with the original Tesla key. Essentially, what is happening is that he is replicating the signals from the car owner’s phone and relaying them, potentially quite far away, to another device near the car. And he’s getting past security strategies that require require certain response times in the communication between the vehicle and the driver’s phone (this response time is referred to as latency). Here’s how NCCGroup describes it: This will all make a lot more sense if you just watch what happens: NCC Group has developed a tool for conducting a new type of BLE relay attack operating at the link layer, for which added latency is within the range of normal GATT response timing variation, and which is capable of relaying encrypted link layer communications. This approach can circumvent the existing relay attack mitigations of latency bounding or link layer encryption, and bypass localization defences commonly used against relay attacks that use signal amplification. As the latency added by this relay attack is within the bounds accepted by the Model 3 (and likely Model Y) passive entry system, it can be used to unlock and drive these vehicles while the authorized mobile device or key fob is out of range.
Okay, so what is this video showing, exactly? Khan does a great job of explaining, but let’s re-cap here. There’s a small device that looks to be based on a Texas Instruments single-board computer with various wireless signal technologies embedded, a sort of board that sells for about $50 online, and that device is placed within Bluetooth range of the Tesla’s iPhone-based “key” which just means the tesla owner’s phone that has been configured to act as a key. This can be a surprisingly large distance, which in the testing reported by NCCGroup was about 21 feet. Next, a similar device, this one attached to a laptop, is in communication with the closer-to-the-phone device via longer-distance communication protocols, like cellular data signals. This end of the attack would then approach the car, and send the Bluetooth low-energy (BLE) signals from the near-phone device–wherever in the world that is–to the device near the car, which can then open and start the car as though the owner’s phone was in the car. Here’s a very simple diagram:
Here’s more information from NCCGroup on the test they performed: It’s worth noting that the above refers to a Model 3 used in the test, and the video shows a Model Y, which makes sense as they both use the same system. Khan described the method of the attack, and gave some nice, alarming scenarios to haunt your dreams: Now, this sort of relay-type attack has been done before, but Kahn and his team are the first to demonstrate it working with the sort of Bluetooth signals used by phones and key fobs. They explain that a bit here: “Using this attack method, I was able to unlock and start the car, then drive away in it. NCC Group has repeatedly and reliably tested and demonstrated this full attack against Tesla Model 3 and Model Y vehicles that it was in rightful possession of as a proof of concept. “In the same fashion, attackers can also unlock people’s houses to gain access for nefarious reasons; or breach businesses. Perhaps worse, they can enter our personal digital domains via our laptops or phones and sift through our work or invade our communications and innermost thoughts and feelings, and access every photo and video taken of our family, and learn about the places we frequent. “Systems that millions of people rely on daily to guard their cars, homes, and private data are using Bluetooth proximity authentication mechanisms that can be easily broken with cheap off-the-shelf hardware. “This research was focused on a class of vulnerability known as a “relay attack”. In a relay attack, messages between the key fob/phone and vehicle (or other device being unlocked) are forwarded to each other by relaying devices. This effectively increases the range over which the vehicle and key fob/phone can communicate. Thus, a phone/key fob and vehicle can be made to believe they are close to one another, when in reality they may be long distances apart – even on opposite sides of the world for digital relays like what I have developed. “Here’s a basic scenario: A victim is at home. Their phone is in the bedroom, and their car in the driveway, locked. The attacker places one relay device in the garden—close enough for Bluetooth signals to travel—and carries the other relay device close to the car. They can then unlock the car, start and drive it away. Once the device is in place near the fob or phone, the attacker can send commands from anywhere in the world. “In another scenario, an attacker can go to a restaurant or office full of people, and leave a relay device hidden under a table, in a closet or in a bush beside the building. Vehicles belonging to people inside would be parked in a nearby lot. Thieves can take their pick.” GATT refers to Generic ATTribute and deals with how two BLE devices communicate with one another. And while I admit I don’t know what a “link layer” is, I do know that this is the method that was key to making this work, and Khan’s team seems to be the first to accomplish such a link layer attack over Bluetooth. None of this is necessarily Tesla-specific, as other carmakers use similar systems. What this is really demonstrating is that while these Bluetooth-based security systems are convenient, Bluetooth was designed to let your computer and other devices have things like wireless headphones, keyboards, mice, game controllers, and that sort of thing. It was never intended to be a protocol for keeping something like a car secure, and we’re seeing the implications of that here. The other big issue with this vulnerability is that it can’t be fixed with a software update, as it’s an inherent limitation of the Bluetooth low-energy protocol. NCCGroup did have this recommendation: I suppose the takeaway here is that specific protocols for secure automotive use should be developed for these sorts of phone-as-key systems, since using the same protocol that your old Wii used to talk to the Wiimotes just isn’t very secure, shockingly. If you have a car that uses this sort of Bluetooth-based setup, you may want to go back to a key fob or at least be on the lookout for strange small circuit boards in your home and yard. For reliable prevention of relay attacks in future vehicles, secure ranging using a time-of-flight based measurement system (such as Ultra Wide Band) must be used. The “link layer” of Bluetooth is what handles things like connection establishment and maintenance, channel hopping, transmit/receive timing, and some other things like that. It’s not something normally visible to end users or mobile app developers – it’s abstracted away by Bluetooth controller chips and Bluetooth stacks. What Bluetooth stacks expose to application developers is GATT. GATT provides a structured mechanism for devices to exchange data, but it provides no visibility or control of how the underlying radio hardware sends the data. It’s possible to establish two BLE connections with standard Bluetooth controller hardware (the kind you’d find in your phone or laptop), and conduct a relay attack by forwarding GATT requests and responses coming out of your operating system’s Bluetooth stack using standard APIs. This has been done in the past (eg. with GATTacker by Slawomir Jasek), though it had limitations in that it introduced easily detectable levels of latency, and didn’t work with encrypted BLE connections (when the encryption key is unknown). I built custom radio firmware to handle all the BLE frequency hopping and bidirectional communications, while providing functionality for the connected computer (host) to send and receive raw link layer data. This way, I was able to avoid the conventional Bluetooth controller firmware and the operating system’s Bluetooth stack, while also gaining control of low level radio timing parameters that are normally invisible to higher level software. This allowed me to minimize added latency, and also let me pass along encrypted link layer messages without needing to decrypt them. By doing this, I could conduct relay attacks against targets that couldn’t be relayed with previous tools. I wouldn’t make blanket statements that Bluetooth is insecure, but rather it is a protocol that was designed for exchanging data, and not proving that two devices are close to one another. Similarly, what mitigations would help avoid this? Some sort of frequency-hopping with parameters negotiated in the encrypted channel? And in extremely extremely related news, you should set up a MITM packet sniff of the various ‘remotely start/unlock/find your car’ apps. I’d do it, but I’d feel way too morally obligated to repeatedly and continuously set off thousands of alarms at 3AM until they fixed it. *On this site should i say thumbs up? Thumbed up? That sounds a bit personal Technologies like UWB provide time-of-flight measurement. Think of it as sending a ping over the air, and timing how long it takes to get a response. While there would be some delay at the other end between receiving the ping and sending a response, that delay can be made consistent. You can subtract that consistent delay from the time it takes to get a response to your ping, and what you’re left with is the time it took for the signal to reach the other device and back, at the speed of light. You need specialized hardware (like what UWB radio chips provide) to get such precise timing measurements. You combine time-of-flight measurement with some cryptography to build a system that is theoretically impossible to perform a range extension attack against. In practice, there are some other attacks possible against implementations of this that allow at least limited range extension (eg. Early Detect/Late Commit attacks) but nevertheless it makes relay attacks much more difficult overall, and long distance relays impossible. It’s a bit better than the late 90’s and early 00’s when most Ford work vans were keyed so similarly anyone with a key could jiggle it a bit to enter and drive any other Ford van. I’m thinking Chevy’s weren’t much better. Otherwise… if you buy a newer car made in the past 5yrs, you D E S E R V E to have the fucking thing stolen. It spies on you: 5g / GPS sourced service, its written into the contract from the OEM that they will be using info gathered from your OBD-II in your general travels with THEIR vehicle… The vehicle does everything for you… including make the E N T I R E A C T of driving itself… so god damn boring… that there is no physical contact to the vehicle or its drive ELEMENTS. On top of.. your desire to stare the screen.. instead of driving… is purely ON PURPOSE. AND… the BEST way to protect a LAPTOP on 4 wheels… is a 4dig pin?! What ya do is this: Ya wire in a fuel cut off switch Ya put in a IGNITION SWITCH, then wire in a ignition cutoff switch Ya wire in a POWER cut off switch. — With Toggle Switches. Then ya get a big ol damn METAL key, use 1 for each door.. plus one for the trunk. AND.. ya yank out that shitball motor and trans its got.. and shove in a 6spd manuel with NO SYNCROS! NOW, watch the FUCK NUTS try and steal a fucking car again… I didn’t read anything about Tesla’s PIN to Drive. Do the other manufacturers with BLE PaaK have something similar? https://www.tesla.com/support/car-safety-security-features#pin-to-drive I know Ford has something similar with their door keypad, but not sure if they have something similar to start the car. No clue about Hyundai Explain to me… why is this allowed to happen? Why Are “we”, “society” as a group (not I mind you), my car is 20+yrs old)… “This system allows users with an authorized mobile device or key fob within a short range of the vehicle to unlock and operate the vehicle, with no user interaction required on the mobile device or key fob”?? What is inherently “wrong” with having a connection of any type to a vehicle? Id also like to know why Bluetooth… is being allowed as a safety device, to stop the threat of a car being pilched? Sure… its cheap. But why bluetooth? As far as passwords and or security… we as a people.. involved with TECH, are notoriously horrible, I mean downright MISERABLE with safeguards, protections, safety… involving TECH. —- Went into my bank once and asked: “Why do you need to ask me 5 different questions with specific answers to log into my account online”. But then ya give me a 4dig passcode (that should just be illegal). Most sites.. heck even the weirdest Govt Sites require the most insane combination of letters, numbers capitals and symbols… just to gain an account (for something as “regular as the DMV”). My… wife / other half bitched about changing passwords on various items. But this is a world where… people stand in a public domain, on their devices using a public signal, to access — any hose of websites…. without a care in the world. As for conventional keyed locks on automobiles – it is NOT a high skilled attack to pick and decode an automobile lock. Witness any number of the Lock Picking Lawyer videos. So the low tech solution is not necessarily better, as I would gather far more people can figure out how to pick a lock than to master and exploit Bluetooth technology. I’ll still keep visiting https://www.schneier.com/ for my weekly squid fix, but this site is great and really a reflection of Autopia. As long as both of these statements remain true, I figure I’m twice as safe from this attack as I would be with just either one by itself. I like my cars.
