How were these Tesla's stolen?

[roblab]

Well, I don't know. That's my disclaimer.

OK. They unlock the car. The fob has to be near the car/ in the car to drive it, right? So the computer has to keep doing the RFID thing to pretend it's a fob?

Secondly, I understand that thieves steal Hondas because there's a market for Honda parts. Where's the market for Tesla parts? They'd have to sell the whole car, WITH a fob. Hmmmmm.

I guess I'm just glad I live in California in a place where we don't have any thefts -- at least according to the police department. I have never in my life worried about someone stealing anything from me, much less my car. I wish it was the same everywhere.

 

[S'toon]

Well, I don't know. That's my disclaimer.

OK. They unlock the car. The fob has to be near the car/ in the car to drive it, right? So the computer has to keep doing the RFID thing to pretend it's a fob?

Secondly, I understand that thieves steal Hondas because there's a market for Honda parts. Where's the market for Tesla parts? They'd have to sell the whole car, WITH a fob. Hmmmmm.

I guess I'm just glad I live in California in a place where we don't have any thefts -- at least according to the police department. I have never in my life worried about someone stealing anything from me, much less my car. I wish it was the same everywhere.

Here’s what happens to professionally stolen Tesla vehicles: dismantled Model S found in truck

 

[deonb]

like having a really precise clock in the fob that you can trust and some measures so that the foreign signal does not impersonate it.
And there's more of course.

Not even - keep in mind a nanosecond is a light-foot (approximately). So if you have a 1 ghz processor on the fob and you add the internal processing time taken for decoding in clock cycles to the response (and sign it of course) - the sender will be able to tell how far the fob is to within a foot.

So e.g. if the sender measures the reply time as 100ns and the fob said it took 80ns to process then the signal distance is 20ft roundtrip, or 10ft between the car and the fob.

 

[Troy]

Some people had their cars disappear from their MyTesla accounts. I wonder if the thieves are emailing Tesla photoshopped documents to make it look like the car was sold and then have it moved to a different MyTesla account. See the topic here.

 

[verygreen]

Not even - keep in mind a nanosecond is a light-foot (approximately). So if you have a 1 ghz processor on the fob and you add the internal processing time taken for decoding in clock cycles to the response (and sign it of course) - the sender will be able to tell how far the fob is to within a foot.

So e.g. if the sender measures the reply time as 100ns and the fob said it took 80ns to process then the signal distance is 20ft roundtrip, or 10ft between the car and the fob.

Well, assuming said 1ghz cpu in a fob can still operate off coin-sized battery for a decent time, you still need to ensure that the clocks used o store those ticks don't drift.
It does not matter that you encode "now is X ns from some common epoch", you need to ensure that the clocks stay reasonably in sync between the car and the fob, or there's a way to bring them in sync. I suspect you could not just resync at communication time because you don't know the distance (back to square one in a way).

 

[KarenRei]

The difference here is the laser measure emits the light and then catches it back.
Now FOB is a whole different device, car does not just bounce the signal off fob so you need to play all sorts of games to catch the latency, like having a really precise clock in the fob that you can trust and some measures so that the foreign signal does not impersonate it.
And there's more of course.

Indeed - that's the fundamental problem, trying to find a way to use a device not designed for precise timing to do something that requires precise timing.

I don't know how much control Tesla has over the receiver's firmware, and I imagine they can't reprogram fobs at all over the air, that they'd have to be replaced. The best that I can think of that they might be able to do with current fobs and reprogrammable firmware on the vehicle end would be to try to initiate a repeated challenge-response system - transmitting to the fob and triggering a response, which triggers a new transmission, and so forth, many thousands of times. This would amplify any transmission delays to easily measured amounts. The problem is that you'd be imparting even more processing delay in handling and responding to signals, and the unpredictability in processing times could swap the accumulated transmission delays.

In short, I don't know what they're actually capable of, if anything, via an over-the-air update.

 

[KarenRei]

Well, assuming said 1ghz cpu in a fob can still operate off coin-sized battery for a decent time, you still need to ensure that the clocks used o store those ticks don't drift.

More to the point, processor clock speed is not the same thing as reportable system clock speed. System clocks run independently to processor clock speeds. For PCs, older OSs don't support HPET and so only have a 33kHz clock. Modern OSs support HPET, and depending on the hardware, and have a clock speed of either 10 or 100MHz. As for some random piece of embedded hardware, who knows what its clock speed is? Don't count on it being high precision unless it was specifically designed for that purpose.

That's the maximum reportable precision - assuming that the clocks haven't drifted, which as you note, they absolutely do. Also, some system clocks (again, on systems not specifically designed for tasks requiring high precision) have precision errors in reporting their time, independent of their clock speed.

 

[verygreen]

Hm, I did not consider it but I guess if parameters of the receiving system are known, we can measure roundtrip latency including the processing time of the other side, as long as there's no unpredictable retransmission happening in case of errors or some such.

 

[deonb]

Well, assuming said 1ghz cpu in a fob can still operate off coin-sized battery for a decent time, you still need to ensure that the clocks used o store those ticks don't drift.
It does not matter that you encode "now is X ns from some common epoch", you need to ensure that the clocks stay reasonably in sync between the car and the fob, or there's a way to bring them in sync. I suspect you could not just resync at communication time because you don't know the distance (back to square one in a way).

There is no need for a common epoch, or for the clocks between the car and the FOB to be in sync in any way shape or form.

All that is needed is that the fob clocks its own internal roundtrip time to the nearest nanosecond and add the result to the response. Heck, for that matter it doesn't even need to compute the response time, if it can guaranteed the response time. So if you e.g. have a buffer that stores the result until exactly e.g. 100ns has elapsed and only send the result after, the car would still have a way to calculate the distance.

Essentially the fob just needs a crystal to tick an accumulator between request and response. Even something running at 200mhz is probably good enough (5ft accuracy) - there are 5uA FPGA's available that can run at 200mhz - or you manufacture an ASIC for this and draw even less power.

 

[KarenRei]

Essentially the fob just needs a crystal to tick an accumulator between request and response. Even something running at 200mhz is probably good enough (5ft accuracy) - there are 5uA FPGA's available that can run at 200mhz - or you manufacture an ASIC for this and draw even less power.

First off, you ignore the variation in time concerning how long it takes the car to reply. Secondly, fobs aren't going to have that sort of temporal resolution. You of course could make a fob like that, a device not already built for high precision timing isn't going to be able to report such fine-grained, precision time deltas.

Nobody is questioning whether fobs could be made that would be immune to this attack. The question is to whether it's possible to retrofit today's system with a software update. That's dubious.

 

[deonb]

First off, you ignore the variation in time concerning how long it takes the car to reply. Secondly, fobs aren't going to have that sort of temporal resolution. You of course could make a fob like that, a device not already built for high precision timing isn't going to be able to report such fine-grained, precision time deltas.

Nobody is questioning whether fobs could be made that would be immune to this attack. The doubt is to whether it's possible to retrofit today's system with a software update.

Ahh. You want a software only fix.

Fair enough, that isn't likely to happen unless the existing FOBs by very big coincidence replies in a very short or very constant period of time today, which, consider the internal math they have to do isn't likely.

Don't think it's a big deal replacing FOBs though. I replace them every few years anyway when they run away.

 

[ggr]

Who said anything about "simply"? The length of time it takes radio waves to travel one meter between a car and a fob is one one hundred millionth of a second. Putting in timing constraints might not even be possible with the hardware onboard to do directly, although I could envision some creative solutions. It depends on how much ability they have to reprogram the both the receiver and the fob itself. Most probably they have to entirely switch transmission methods.

Relay attacks are fairly new... maybe as early as 2014? Originally just for opening car doors... stealing the cars came later.

Relay attacks in general are not at all new. They were first (as far as I know) used in late WWII to relay IFF (Identification Friend or Foe) radar signals.

 

[roblab]

Here’s what happens to professionally stolen Tesla vehicles: dismantled Model S found in truck

Interesting! Also glad to note that the "always on" GPS deters them, and that they are still mostly in Europe.

 

[stopcrazypp]

Granted, he may have had an accomplice.

But more concerning is the fact that the other transmitter must be within a few feet of the key fob. If this were at a house, then the thieves would have to know precisely where the owner stored his key in the house and it would assume that they could approach to the appropriate vicinity. In my house, my fob is on the kitchen counter which is 15 feet away from the exterior.

If this were in an apartment, the thieves would have to gain access to the apartment complex and know precisely which unit the owner lived in. Neither scenario seems terribly likely.

Even for regular break ins (which may be far lower value than this) a thief may monitor the target a couple of days. They don't actually have to determine where you put your fob, only have to test which location might get a good signal to it.

The videos I see of how it's used tends to be more opportunistic (they wait at crowded location where cars are parked and just take the car shortly after owner leaves it). This string of attacks appear to be targeted so I imagine it's more like the situation I described in the first paragraph.

 

[Blissedout]

How hard would it be for a computer to mimic the signal a key fob sends out when you double click the button on the fob? How long would it take to run through all possible signals? Is what happens when clicking the button twice different than when you merely stand close enough to the car so the two communicate?

 

[schonelucht]

Granted, he may have had an accomplice.

One of these incidents was caught on a security cam. Footage was broadcast by Dutch police, requesting help from the public in solving the cases. See here : Auto stelen nieuwe stijl The Dutch voice over explains the process : one guy is close to the door of the house, the other close to the door of the car.

But more concerning is the fact that the other transmitter must be within a few feet of the key fob. If this were at a house, then the thieves would have to know precisely where the owner stored his key in the house and it would assume that they could approach to the appropriate vicinity. In my house, my fob is on the kitchen counter which is 15 feet away from the exterior.

Many people keep their keys in their coats and the coat rack is often conveniently close to the front door in Dutch houses.

 

[boaterva]

The interesting detail is that my BMW (2009!) won't move if the fob isn't in the car. I never understood why Tesla doesn't do the same. I know it uses different hardware/signals, but you would think it could tell with multiple antennas that the actual transmitter was inside or not. That would eliminate this issue and perhaps with a PIN, the 'using only the app' scenario.

Or am I missing something basic here? My EE degree is a few years out of date.

 

[arnis]

Well, the "fob" (aka the device that transmits correct rolling and fixed code) is in the car when thief gets into the car with the repeater.
Unfortunately, it is not original fob that is in the car but the repeater.

It is actually possible for vehicle to notice the lag repeater devices make.
But I would add second layer of security to model S/X:
require a Bluetooth connection to start driving. If no Bluetooth paired, request a simple
pin code. As soon as phone connects, cancel the request.

 

[mal_tsla]

Apple does time of flight calculations to prevent Apple Watch unlocking a Mac using this same technique. Seems to work!

 

[KarenRei]

So, Tesla apparently added a workaround to present this:

Tesla adds 'Passive Entry' to combat vehicle theft by keyless-entry exploit

It's not ideal, but you can disable passive entry and make it require a keyfob button press for the handles to present. Probably about the best that they can do with the current hardware.

 

[boaterva]

So, Tesla apparently added a workaround to present this:

Tesla adds 'Passive Entry' to combat vehicle theft by keyless-entry exploit

It's not ideal, but you can disable passive entry and make it require a keyfob button press for the handles to present. Probably about the best that they can do with the current hardware.

Right, until they can prove you are really standing nearby (time of flight of the signal), it's a good answer. I'll be using it as I like positive control. Until they make the external cameras do facial recognition like Apple is supposed to do next month (not sure I'll trust that either!), then everything will be fixed!