-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Tesla fob, should we be concerned ?
- Thread starter saz25
- Start date
Derek Kessler
Active Member
A properly encrypted communication cannot be compromised even if all traffic between the two parties is intercepted.
The whole premise of having to protect your car key fob in this manner, is that the communication between the key fob and the car is vulnerable to a simple replay attack.
Is this premise really true?
This was the reason why Telsa added the Passive Entry Enabled/Disabled option in 17.32 (i think).
I agree that the risk is pretty low, but since a solution is also very inexpensive - a simple faraday pouch/container - I purchased one and just keep my fobs (Tesla and wife's MB) in the pouch when we get home.
https://www.amazon.com/gp/product/B072LT73RP
Or put your keys in the microwave (just don't turn it on!, or sue me)
A relay attack should be detectable by having the car continuously monitor and over time characterize the latency in the communication with each device that the driver uses.
When the latency for a specific, characterized device exceeds a given threshold, the car can take one or more (pre-configured) actions, e.g.
1) Not unlock the car (duh),
2) Send a message to the driver's device, warning the driver that a relay attack seems to be in progress,
3) If the device is flexible enough, provide the driver with an option to state whether the driver is in fact trying to
unlock the car or not,
4) Take note of the out-of-bounds latency for improving the robustness of the countermeasure,
5) If the car determines that an attack is in progress, it can go on with:
6) some specific flashing of the cars (emergency) lights/horn,
7) start recording input from the car's cameras and other relevant sensors,
8) silently drop the out-of-bounds communication, or maybe stall the bad guys with some form of non-sensical communication.
The robustness of this countermeasure depends on the bad guy's ability to create a relay device with a latency so small that it cannot be reliably detected - so a weak point is when the driver has only just started to use a new device with the car. This weak point could in turn be negated with the car having a pre-defined list of devices and their known latency.
Good cryptography software works equally well if the bad guy has the source code. So I have a feeling that Tesla's software for communicating with the driver's devices could become better if it was open source, so people could suggest concrete improvements to Tesla.
Corsair
Member
My patient tried that. Didn't stop The Devil from laughing at him (unfortunately from the general populace too...)
Interesting ideas.
Seems likely to have problems if there is any multipath around. (eg. when another car parks next to you, or passes by on the street.)
To avoid denial of a valid unlock request in a multipath case where two (or more) signals arrive with different round-trip latencies, the smallest latency should be used.
A different idea, for when a smart phone is used for the passive unlock:
Send only the unlock signal when the built-in sensors show acceleration of the phone, i.e. when the owner is moving.
This would protect against the case where the car is parked outside the house, with the owner sleeping inside with the phone turned on but stationary.
Even if one imagines a perfectly smooth wheel-chair ride towards the car, the unlock signal would be still sent when the wheel chair stops at the car.
This solution would also conserve battery while the phone is stationary.
.jg.
Member
It isn't a replay attack - smart key typically use rolling codes. The thieves use radio repeaters which relay the regular traffic between the fob and car in both directions, such that the car is fooled into thinking the fob is nearby or inside. Like this.
This method only works if passive entry is enabled - the repeaters used by the thieves cannot simulate the depression of a button on a fob, they merely relay the traffic between fob and car.
Yes, a relay attack.
So my ideas for how Tesla can allow passive entry to safely remain enabled are:
1) Let the car measure the round-trip latency of its communication with the unlocking device (fob or whatever) - if this is higher than what it normally is for that device, the signal is assumed to be relayed, and a range of actions can be taken.
2) Let the (smartphone) unlocking device only send the unlock-signal when it is in motion, since the car should only unlock when the owner (and the owner's device) is moving - this would take care of the scenario you link to.
.jg.
Member
Yes - a distance bounding protocol could be used to verify that the the fob is actually near the car and is not being relayed. I would have thought that new code could be introduced into the keyless entry system to achieve this - I guess by the keyless system OEM, Pektron.
If a smartphone can be used, additional checks could be made, to check that the Tesla is in range of the smartphone's Bluetooth and WiFi interfaces and/or that the location data of the Tesla matches that of the smartphone.
Similar threads
