Possible to steal a tesla with a MITM attack?

[father_of_6]

The idea popped into my head today of using some sort of Bluetooth relay devices to unlock a Tesla. Thief A stands near your car, thief B stands near you (in the mall, grocery store, etc), each with a device that relays the Bluetooth exchange between your phone and vehicle.

After a bit of Googling, it seems this can't be done easily with standard off the shelf devices, or at least not that I could find. Certainly it must be physically possible though, it's just relaying short-range wireless signals back and forth across a longer distance.

PIN to drive would be the other challenge. A brute-force device that mounts onto the MCU and rapidly types all PINs would be one way. It would probably take a few hours to go through all possible PINs though. Really, if you have a good view of the car while the driver is typing the PIN, it seems like it'd be easy to get. Probably this would just take a good targeted attack (follow the driver on their travels, binoculars, write down the pin).

I'm going to steal *all* of your Model 3s... then I'll park them all at my house and send a mass TXT... "surprise, I've got your car!". Really it'll just be a fun way to invite you all to a Model 3 owners backyard barbecue party. Except you'll all need a ride... haven't figured that part out yet.

 

[linux-works]

private keys on both endpoints keep middle guys (MITM) out.

replay attacks are always the first things to be protected against, when making secure protocols. you have to do a lot more than be a PHY repeater to break BT or BLE.

its (security) been worked out, not to worry. you do have to be a good pen tester to get thru. bluetooth (of all types) is one of the least secure wireless protocols, truth be said, but its still pretty good for all but government use (LOL).

 

[linux-works]

A brute-force device that mounts onto the MCU and rapidly types all PINs would be one way.

unless tesla is completely incompetant, they'd time out any repeated sequence that looks like a crack attempt. either lock the car (like phones do) or just take longer and longer before the prompt comes back and you can try again.

 

[linux-works]

Really, if you have a good view of the car while the driver is typing the PIN, it seems like it'd be easy to get.

I have not tried using the PIN feature; but one thing that is useful is rotating numbers on the pad, so that pressing a pattern wont be enough for a remote viewer to steal, unless they really could see the numbers underneath. moving number grids is annoying to users and slows them down and causes errors, but it has a security benefit. I wonder if tesla does that or thought about that for their pin to drive feature. now I'm curious and might check tomorrow

 

[father_of_6]

Indeed, the pad appears in a different location each time... but the keys are always in the standard phone-style display. Without bouncing around, it'd be pretty trivial to determine a PIN just by greasy fingerprints.

How are Model 3 owners going to see the invite to my backyard barbecue now that this post was relocated? Oh well... it was BYO chicken anyways.

 

[father_of_6]

private keys on both endpoints keep middle guys (MITM) out.

replay attacks are always the first things to be protected against, when making secure protocols. you have to do a lot more than be a PHY repeater to break BT or BLE.

This is hard to understand... I'd actually like to disagree, but I definitely don't have the technical prowess to back it up. I do have a basic understanding of encryption of traffic using pre-shared keys... but that still allows ISPs to facilitate the exchange of information between those endpoints. It doesn't allow the ISPs to *alter* the communications traveling between the endpoints, but it allows them to pass those communications back and forth in their unaltered state.

That's all I'd aim to do with these bluetooth extenders... just repeat the signal over a longer range. How can the devices physical secure against that? The only difference from their native exchange is a *tiny* bit more latency... is it possible that bluetooth devices take milliseconds of latency into consideration while handshaking?

 

[DOCAL]

That's all I'd aim to do with these bluetooth extenders... just repeat the signal over a longer range. How can the devices physical secure against that? The only difference from their native exchange is a *tiny* bit more latency... is it possible that bluetooth devices take milliseconds of latency into consideration while handshaking?

This has been done in Europe with the older key fobs, I believe "PIN to drive" was a response to it happening.

As you mentioned, the RF signal is just relayed, and measuring "time in flight" is a mitigation. I would expect it to be harder with bluetooth due to the frequency hopping that it does, but I'm sure that can be worked around too.