Bluetooth Flaw Allows Remote Unlocking of Digital Locks

Locks that use Bluetooth Low Energy to authenticate keys are vulnerable to remote unlocking. The research focused on Teslas, but the exploit is generalizable.

In a video shared with Reuters, NCC Group researcher Sultan Qasim Khan was able to open and then drive a Tesla using a small relay device attached to a laptop which bridged a large gap between the Tesla and the Tesla owner’s phone.

“This proves that any product relying on a trusted BLE connection is vulnerable to attacks even from the other side of the world,” the UK-based firm said in a statement, referring to the Bluetooth Low Energy (BLE) protocol—technology used in millions of cars and smart locks which automatically open when in close proximity to an authorised device.

Although Khan demonstrated the hack on a 2021 Tesla Model Y, NCC Group said any smart locks using BLE technology, including residential smart locks, could be unlocked in the same way.

Another news article.

EDITED TO ADD (6/14): A longer version of the demo video.

Posted on May 20, 2022 at 6:02 AM24 Comments


T May 20, 2022 8:00 AM

The Bluetooth Proximity Profile specification ( clearly states:

“6.2 Distance Measurement Security

Note that for the Bluetooth Core Specification [1] v4.0 (and possibly later versions) even if the link between the Proximity Monitor and Proximity Reporter has security enabled, the two devices can be spoofed into assuming that the other device is close. So the Proximity Profile should not be used as the only protection of valuable assets.

One simple attack would utilize the fact that a MIC is not added to empty packets. For the Bluetooth Core Specification [1] v4.0 it’s recommend that use cases that require a moderate security level ensure that there is some authenticated data traffic on the link between the Proximity Monitor and the Proximity Reporter. If no other profile is causing data to be exchanged, the Proximity Monitor might read the Alert Letvel characteristic of the Link Loss Service occasionally. The average frequency of the data traffic must be chosen as a trade-off between the security requirement of the use case and the added battery drain in the tiny device

More advanced attacks might use some form of relay to extend the range of between the two devices. There is currently no known way to protect against such attacks using Bluetooth technology.”

This profile was intended to be a convenience feature (e.g. automatically locking a personal computer when the user walks away), not a security mechanism for high-value assets…

There are a variety of wireless protocols that are attempting to address the security aspects, such as Bluetooth HADM (High Accuracy Distance Measurement) or IEEE 802.11az (Enhancements for Positioning)… although they generally rely on implementation of mechanisms not defined by the standards to actually detect and stop active attackers.

The trouble is that the end-product manufacturers are not experts in these standards and do not understand (or care) what needs to be done to use them securely.

Gordon Dove May 20, 2022 8:19 AM

These claims seem a little overblown.

The description isn’t incredibly explicit, but this sounds like a simple MITM attack.

When they say any BLE lock “could be unlocked in the same way”, this seems a bold claim, especially when they claim that this weakness is intrinsic to the design of BLE and cannot be ameliorated in software ( in linked articles).

Surely a remote mitm attack like this can be defeated by a simple latency check. Even if the relay device has a very fast path, BLE is always peer to peer, so a genuine unlock has two hops ( there and back), and the bogus unlock has four. BLE is not quick, so BLE transit will dwarf any processing time.

So what they’ve really shown is that a simplistic unlock scheme is vulnerable to MITM, which probably didn’t need hardware to prove.

T May 20, 2022 8:44 AM

Gordon, a relay attack does not need to be store-and-forward. It is relatively simple to forward a radio signal in near real-time, with the relatively little latency beyond the extra RF propagation time. Standard Bluetooth devices have a timing accuracy of around 1 microsecond, so it is possible to insert at least 150m extra range (300m round trip) without it being noticeable. Typically at least 10 microsecond timing error is accepted to allow for clock inaccuracies.

James Harr May 20, 2022 9:26 AM

It really makes me wonder how much further could this approach be generalized to anything that uses RF contact as a proxy for physical proximity? Does a target have some sort of IOT setup that unlocks their house when they’re detected on their home WiFi? Could you do something similar with an SDR setup to make it appear as if they were close? Maybe it’s too impractical for Wifi, but what about other types of things? Zigbee may be a low enough data-rate that you could do so with less sophisticated gear.

You may not be able to understand what’s going on in the conversation, but that’s not the goal. It’s just to fool at least one side into the notion of physical proximity.

David Leppik May 20, 2022 10:09 AM

I thought Tesla fixed this relay attack years ago by adding tighter latency checks and by allowing users to add a PIN. Of course, the fact that they added a PIN option implies that the latency check wasn’t good enough.

Bluetooth 5.1 is able to do centimeter-precision positioning by trangulating between multiple antennas. Security is one of the use cases. In fact, they use a car fob as in one of their promotional graphics.

However, there are a lot of caveats. The specification describes signals to allow positioning, but not specific direction-finding algorithms. Handling noise and echos is not specified. Location is only precise if antennas are distant enough. Plus, of course, adding and positioning antennas in a car cannot be done via software update.

David Leppik May 20, 2022 10:19 AM


Bluetooth 4.0’s proximity assumes beacons with known power output, so that distance can be measured by signal strength. This is trivially spoofed with a repeater for a MITM attack.

In my own experiments, I’ve found that 4.0’s proximity is noisy even under very good conditions. You can tell 1 meter from 5 meters, but you can’t generally tell 1 meter from 3 meters. If you add noise or obstacles (e.g. pillars or walls containing metal) then it gets even worse.

For some use cases, this is just fine. Just not use cases which involve security.

Clive Robinson May 20, 2022 10:23 AM

@ Gordon Dove, ALL,

The description isn’t incredibly explicit, but this sounds like a simple MITM attack.

It is, but that is not why it works.

As I indicated over on the current Friday Squid, the problem is due to “stacks”.

Or more correctly the time it takes to go down a stack and back up another stack, gets added on the the packet time and speed of light transmission time, to make the “seen time”

Of these three times the spead of light transmission time is by far the shortest, and the only one related to distance or range.

So all the attackers did was short out part of the stack, and get 8-10 times the range.

You can add another trick or two to shorten the packet time as well thus get extra range.

It’s a trick I called “tail compression” back when I worked out how to do it back in the 1980’s (I suspect others have done likewise).

It works because whilst the claim is the “data is synchronous” which is true-ish, down at the base physical level actually the “communications is asynchronous” as “the clock is derived from the signal”[1]. Thus you can compress bits in the time domain by as much as 25% in most cases.

All you have to know is what they are before they are transmitted… No this does not mean you have to “time travel” you just have to abuse “error correction” There are two basic types, “Check-Codes” and “Forward Error Correction”(FEC).

FEC works by sending the entire data block or communications packet say three times. So as your relay receiver is very close to the transmitter it will most probably get the firs block/packet perfectly. Thus shortening the other two blocks/packets is not difficult.

Alternatively as the tail bits are “unchanging” you only need to grab a good block from an earlier transmission.

So for protocol designers, the further forward in the block/packet you make the “unknown/changing data” towars the transmission head, then the easier the attack is and the further the range it will work at…

That is when you have transmitted past that point of change, the attacket already knows what the rest of the bits are going to be. So can send each “bit” in steadily shorter versions of them. Thus finish the packet say 5-10% faster, thus get an appropriate range extension[2].

I’ve not seen this written up in any “academic papers” and the stuff I did back in the 80’s the report I wrote got “restricted” circulation at best… But I suspect I’m not the only one to have “worked it out”.

[1] There are three reasons the clock is derived from the signal,

1.1, Sending a clock signal would require a second communications channel.
1.2, Whilst textbook pictures and formular imply communications channels are fixed in length, in practice they are not.
1.3, Neither the transmitter or receiver can remain in synchronisation in time, frequency or phase, the laws of physics do not alow it.

The second is due to the fact that what is received is a “Vector Sum” of the transmitted signal bouncing of an unknown number of objects maby of which move.

The third has the minor issue that in most cases the transmitter probably moves, and at ~2.5GHz even at walking speed the Doppler effect is quite noticable. So you can not just lock to the carrier frequency.

[2] Getting your head around “tail compression” can be difficult if you do not draw it out graphically, at which point you generally get an agha momrnt and say something like “That’s obvious”…

Ted May 20, 2022 10:30 AM

@David Leppik

I thought Tesla fixed this relay attack years ago by adding tighter latency checks and by allowing users to add a PIN.

I don’t know if this is a new attack based at a different layer – the link layer rather than the GATT-layer.

Ars: The link layer is the very lowest level of the Bluetooth stack… Previous BLE relay attacks worked at the GATT—short for Generic Attribute Profile—layer, which is much higher up the stack.

Clive Robinson May 20, 2022 11:08 AM

@ David Leppik,

However, there are a lot of caveats.

That “presentation” is inapropriate for use in cars and actually most applications.

Consider the “map” has three RX units at or near the periphery…

That does not apply in most cases, the tags will be outside the periphery by a very long way…

Consider a car roof, people do not want three antennas a half meter appart to be sticking up…

Also assume that the antennas form a “unity circle” how you derive position inside the unity circle, is different to outside the unity circle, but also outside the next circle out…

Worse for any two antennas there will be a series of “circles” that give the same position and there is always a line from the other antenna that falls midway between the two antennas where things get “complicated” to put it politely.

@ ALL,

The system acts like a poorman’s “DECA-Navigator” in reverse. I could list up all of the problems that are “known” that relate to “Angle of Arival”(AOA) system but… It’s easer if you look them up as they are online in a number of places and published standards.

Then there are “Time of Arival”(TOA) systems, that Bluetooth does not currently support (but could do). The closest they get is the lamentably implamented “Time of Flight”(TOF) system.

TOA is like GPS in reverse and can be quite accurate beyond a certain range but only inside the unity circle.

TOF using analog technology was used during WWII as “Gee” it can be accurate but not with low cost digital systems.

Combining multiple systems does not realy help as the accuracy only goes up by the RMS of each systems accuracy.

So if the systems have the same accuracy, you would get about a 40% increase for two say AOA and TOA.

lurker May 20, 2022 1:33 PM


So does Tesla not use UWB or NFC chips to prevent these types of attacks?

What? And have to pay Apple patent licence fees?

More to the point, extra chips mean extra battery. The Tesla attack is against a keyfob, Apple have a handheld bigiron machine.

Ted May 20, 2022 2:41 PM


Or maybe the Car Connectivity Consortium wouldn’t have T as a member?

Lol! Mabye😄

Saint Michael May 20, 2022 3:05 PM

It’s a shame that we – especially vaunted Tesla – don’t have the technology available to develop a dedicated physical unlock token. Something made of durable material – maybe metal or similar. Something that could be easily transported, ideally with no broadcast signal, and operated only in immediate (i.e. contact) proximity.

Ah, well. Maybe someday we’ll achieve such wonders.

Clive Robinson May 20, 2022 4:09 PM

@ Saint Michael,

a dedicated physical unlock token. Something made of durable material – maybe metal or similar. Something that could be easily transported, ideally with no broadcast signal, and operated only in immediate (i.e. contact) proximity.

The problem, is it would still require a control system that is digitally based. Which would still need a physical interface to be an effective turn on.

But would the stress of such a system leave the operator all keyed up?

SpaceLifeForm May 20, 2022 4:24 PM

@ Saint Michael

LOL. Appreciated.

Now, to make it even more secure, no pic[k]s. That part is not going to be simple.

Security. Convenience. Pick one.

MarkH May 20, 2022 4:57 PM

@St Michael, Clive:

I can only visualize using such a system digitally, though there are surely people who could manage with their toes.

Gordon May 20, 2022 5:03 PM

Excellent background details especially from Clive R.

A lot of respondents are treating this like it is a range extension thing, but from the Reuters article, NCC claimed “This proves that any product relying on a trusted BLE connection is vulnerable to attacks even from the other side of the world”

So we’re not talking a hardware BLE retransmission, they are claiming Car -> BLE -> Internet around the world -> BLE -> authentication device -> BLE -> internet around the world -> BLE -> car, and that this cannot be mitigated.

If the Tesla implementation is trusting the ranging information from BLE, I can see how this can be spoofed, and if they ignore the actual rtt or accept that they have to allow time for retransmits.

However, since the implementers know that this is peer to peer and the other device is very close, I can’t see why they have to allow time for retransmits. Just send ten challenges and if none of them come in close to the normal RTT, something fishy is going on.

I’m not taking issue with the claim they can unlock a Tesla, I’m unconvinced that this is a class break that cannot be mitigated against, especially since the lock can know the typically rtt for specific authentication device, and does not need to accept any significant deviations in minimum RTT.

SpaceLifeForm May 20, 2022 6:44 PM

@ Gordon

However, since the implementers know that this is peer to peer and the other device is very close, I can’t see why they have to allow time for retransmits.

Implementation. Non-encrypted channel.

Challenge packets.

How is that Random working for you today?

Tatütata May 21, 2022 1:48 AM

There is a fascinating Ewetoob channel by a dude in Maryland calling himself The Lockpickinglawyer. The videos are usually short, with a median of 2 and a half minutes. In these he manages to show how most locks are susceptible to single pin picking (the master discipline), but often to simpler techniques such as raking. Specialized picking tools are also regularly featured, some of them custom built.

Destructive techniques are also shown. The profusion of incredibly poorly designed products that can be trivially defeated is depressing. (MasterLock is often the butt of the joke). He occasionally tries his hand at electronic products.

After watching a couple of hundred productions, one could definitely see a pattern emerging.

I am therefore inclined suspect that one needn’t to hack the Bluetooth interface to open the virility substitutes peddled by that self-satisfied prick who shall remain unnamed.

Robert May 23, 2022 9:39 PM

@Tatütata, after watching the LockPickingLawyer’s channel, BosnianBill’s channel, and a few others I don’t think any car manufacturer has a decent lock.

Clive Robinson May 25, 2022 1:26 PM

@ Tatütata, ALL,

Sorry this reply is late, earlier versions got acceptd but did not appear… So we try again.

I am therefore inclined [to] suspect that one needn’t hack the Bluetooth interface to open the virility substitutes…

There are I suspect several reasons for this, of which three foundation isses contribute,

1, The “going equiped” legislation.
2, The “Physical trace transfer principle”.
3, The latency of law enforcment ability in emerging technology.

In many jurisdictions there is legislation that is based almost entirely on speculation for you to be found guilty, or punished in some way…

That is “in the opinion of an officer of the law” you are about to commit some crime. One of these is “going equiped” legislation that is you are stoped by a warranted officer or equivalent, and something you have in your posession makes the officer think you are about to commit[1] or are planning to commit some crime…

A friend who keeps an eye on such things told me that more recently the Police actually took a taxi driver to court for having tools next to his spare tire in the boot… Various witnesses were called in the drivers defence and the case got thrown out… But it makes you ask “what next?” They’ve pulled people for having pens and keys, so maybe Mobile phones[2].

But the thing about radio systems is you have “control without contact” which some might figure is kind of useful as no physical contact would mean no “trace evidence” which is often the only thing that gets a conviction these days…

The French Dr Edmund Locard, also known as the “Sherlock Holms of Lyon” was somewhat familiar with and the investigation of violent crime on an almost daily basis. He realised that in such crimes there was a mutual transfer of evidence from one person to another with each blow, stab, etc. He gave voice to this notion and with time it became more general and known as “Locard’s Exchange Principle” expressed as,

“Every contact leaves a physical trace”.

As I’ve indicated in the past much “trace evidence” is at best circumstantial, you shed over 50g of DNA everyday wherever you go. And others move things around that have your DNA or finger prints on (even the Police have been caught “fitting up/. But importantly there are limits on what can be reliably measured, and the less there is of somethibg the more likely there are to be errors. But most don’t know this in fact they get the opposit idea because of the “CSI Effect”. Where for drama TV programs put a very much over exaggerated idea of forensic capability in most peoples minds so some prosecuters love it. Thus in a semi-knowledgeable person the desire not to have to deal with “trace evidence” changes it to,

“No physical contact, leaves no trace”

Which gives rise to assumptions of “no trace” with the likes of “virtual contact” via consumer grade “smart devices” and other similar devices.

But is that actually true?

Well no, it’s not. Law enforcment have kind of realised over the past decade and a half, that mobile phones and smart devices are not just tracking devices, they are also like “tool-bags”. That is you can put virtual / software tools in them that can be used to say you are “going equiped” to commit a crime…

Though Law Enforcment and other Government Agencies can not just “open and look” inside a phone there are now personnel for various agencies equipped with technology that can “image” a mobile phone or smart device, more easily than looking in a traditional bag, and see what is stored in various parts of the phone or Smart Devices memory…

What not a lot of people apreciate is that “deleting” files usually neither delets them –just the refrence– nor does it remove the “meta-evidence”. Further even if you do delete the file’s contents by zeroing, or filling with random data the meta-evidence often still remains.

Meta-evidence, is evidence about evidence, one simple example is if you remove an object from a table or shelf it leaves a shape or hole in the dust by which the fact it was taken is visible. It’s base shape and due to the uniform nature of the way dust settles with time, the ability to make an approximation of “what and when” can be made (using a variation of the “Electro-Static Detection Analysis”(ESDA) testing). Likewise static electricity in a carpet by using charged micro objects akin to dust, revealing recent foot prints. But of more interest missing books from a bookshelf, also give rise to meta-evidence. So it does not take much of a leap of the imagination to realise the same basic idea applies to “File System Forensics” thus avoiding “File Systems” in semi-mutable memory such as magnetic media or charge storage media like Flash / ROM in a “Solid State Drive”(SSD) Smart Device or mobile phone would be advisable.

So what is your crook behaving unlawfully going to do?

Some would think “fully mutable memory” like RAM, is safe, because if you remove the power, after a short while data in it does indeed become unrecoverable.

Unfortunately for those using unlawful virtual tools, that is not a sufficient precaution. Because most consumer and commercial Smart Devices and Mobile Devices use “Digital Networks” for communications that “log” all sorts of information. Much of it via “third party” entities that for commercial reasons log a very significant amount of data in their third party business records which become meta-evidence at the submission of not a warrant with independent oversight, but a letter, or in some cases an uncheckable Email…

There are ways around such issues, but slowly but surely with improving technology law enforcment are catching up. But technology has no knowledge of what it is being used for is “good or bad” it just gets on with it. Thus in any conflict there will be those ahead of a curve and those behind a curve, which is which depends on who has the better knowledge at the time.

[1] I’ve suffered from this “going equipped” nonsence simply by having a quite legal pen knife in my small toolkit I had in a toolcase, in a backpack… Luckily in my case at the time the UK was still in the EU and the Met Police found themselves afoul of a then basic leagaly protected right (freedom of movment to carry out a trade or similar economic activity). Yup I had come from doing some work for someone picked up my son and was taking him out for something to eat. According to the unwarranted (Robin-Reliant / Plastic-Pig / PCSO) I should not have picked my son up, but gone home to drop my tool-kit off… Yes the Met Police has it’s fair share of “should never be employed” in it’s ranks and the politically inspired PCSO idea let a lot of rotten eggs in and the stench still lingers from the top of the dung heap on down.

[2] At the moment UK Law Enforcment has not tried to prosecute some one for just carrying a mobile phone… but no doubt it will happen at some point. Because those with longer memories will remember the UK Met Police anti-terror brigade, ran a propaganda campaign implying anyone with two mobile phones was suspicious and you should report them… Ironically at a time when even the Met Polices “street beat” and upwards officers were starting to carrying two phones due to the crap Trunked Radio System inflicted by Central Government with huge amounts of money being wasted on it[3].

[3] The UK National system was based on Motorola TETRA system that was quite unsuitable for many reasons, just afew of are mentioned in,


Then there were all the awaful software SNAFU’s that Marketing/Development so often insist are made. One such was a feature where every time the handset unit received a valid call the large LCD display would get brightly “back lighted” just the sort of thing you “need like a hole in the head” if you are trying to be covert for some reason. Over in East London some started calling the police on the beat “fire-flys”…

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.