Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Model 3 - Is pin to drive not available yet?

This site may earn commission on affiliate links.
Last night my M3 got 36.2 version update and under what's new it just says bug fixes. I watched some video demo on how to setup "Pin to drive" feature and I wonder is this feature should be available on M3 also?
 
Is the relay attack the same as signal boosting?

Yes, the idea is that a relay is used to boost/relay the signal of the original fob sitting in a nearby location to the car so that the car thinks the fob is in immediate vicinity.

I believe newer technology fobs use a challenge response method as well as encryption to validate that the fob is who it says it is and is not a relay/booster.
 
Yes, the idea is that a relay is used to boost/relay the signal of the original fob sitting in a nearby location to the car so that the car thinks the fob is in immediate vicinity.

I believe newer technology fobs use a challenge response method as well as encryption to validate that the fob is who it says it is and is not a relay/booster.
Maybe I am being dense, but if I am just amplifying the existing signal, how does challenge response or encryption help?
 
Maybe I am being dense, but if I am just amplifying the existing signal, how does challenge response or encryption help?

Imagine you are connecting to Amazon.com using an encrypted HTTPS session. Your PC makes an initial request of Amazon and Amazon generates a signed certificate with a secret key that only your PC and Amazon know about. This exchange is done over an encrypted connection.

Now, you insert a network capture device and capture all of this traffic in an effort to "spoof" your PC and make it look to Amazon like it's your PC talking to Amazon. This will not work because your capture device doesn't have the secret key (was exchanged encrypted) and so Amazon is not "fooled" into thinking that device is your PC and can make purchases.

I believe that the newer keys work the same way. The communications are encrypted and there is a key exchange that happens so that the fob and car know each other with a secret pre-shared key and there's no way for a "man in the middle" to fool the car into thinking it is the fob.

It is likely that this key exchange is done when you pair a fob to the car and from that point on all of the communications are encrypted and the certificate key is then on the fob. No relay can recreate this encrypted certificate so it will never fool the car into thinking it is the fob.

The car doesn't just say "I see the fob". The car interrogates the fob for the secret key when it thinks the fob is in proximity. The relay device doesn't have this key, and can't fool the car into thinking it's present. Just forwarding the encrypted packets isn't enough for this hacking method to work.
 
  • Informative
Reactions: tread
Imagine you are connecting to Amazon.com using an encrypted HTTPS session. Your PC makes an initial request of Amazon and Amazon generates a signed certificate with a secret key that only your PC and Amazon know about. This exchange is done over an encrypted connection.

Now, you insert a network capture device and capture all of this traffic in an effort to "spoof" your PC and make it look to Amazon like it's your PC talking to Amazon. This will not work because your capture device doesn't have the secret key (was exchanged encrypted) and so Amazon is not "fooled" into thinking that device is your PC and can make purchases.

I believe that the newer keys work the same way. The communications are encrypted and there is a key exchange that happens so that the fob and car know each other with a secret pre-shared key and there's no way for a "man in the middle" to fool the car into thinking it is the fob.

It is likely that this key exchange is done when you pair a fob to the car and from that point on all of the communications are encrypted and the certificate key is then on the fob. No relay can recreate this encrypted certificate so it will never fool the car into thinking it is the fob.

The car doesn't just say "I see the fob". The car interrogates the fob for the secret key when it thinks the fob is in proximity. The relay device doesn't have this key, and can't fool the car into thinking it's present. Just forwarding the encrypted packets isn't enough for this hacking method to work.
Ah so the relay isn't just merely boosting the signal (think holding the fob to your chin to get greater range) it is also doing a Man in the Middle Attack. Which the Challenge/Response + Encryption prevents.
 
Ah so the relay isn't just merely boosting the signal (think holding the fob to your chin to get greater range) it is also doing a Man in the Middle Attack. Which the Challenge/Response + Encryption prevents.

I'm not sure, but I assume that it's acting like a man in the middle with the older generation non-encrypted keyfobs. There's probably some great brain dump on Reddit or elsewhere about relay attacks on key fobs.

Attacks like this were first used with garage door openers (thief sits near by and grabs the garage door signal) even ones with rolling codes in order to gain entry to homes after the homeowner left for the day. I assumed it's a similar attack on the older generation fobs.
 
Imagine you are connecting to Amazon.com using an encrypted HTTPS session. Your PC makes an initial request of Amazon and Amazon generates a signed certificate with a secret key that only your PC and Amazon know about. This exchange is done over an encrypted connection.

Now, you insert a network capture device and capture all of this traffic in an effort to "spoof" your PC and make it look to Amazon like it's your PC talking to Amazon. This will not work because your capture device doesn't have the secret key (was exchanged encrypted) and so Amazon is not "fooled" into thinking that device is your PC and can make purchases.

I believe that the newer keys work the same way. The communications are encrypted and there is a key exchange that happens so that the fob and car know each other with a secret pre-shared key and there's no way for a "man in the middle" to fool the car into thinking it is the fob.

It is likely that this key exchange is done when you pair a fob to the car and from that point on all of the communications are encrypted and the certificate key is then on the fob. No relay can recreate this encrypted certificate so it will never fool the car into thinking it is the fob.

The car doesn't just say "I see the fob". The car interrogates the fob for the secret key when it thinks the fob is in proximity. The relay device doesn't have this key, and can't fool the car into thinking it's present. Just forwarding the encrypted packets isn't enough for this hacking method to work.

I am well aware of how asymmetric encryption works however I must admit I still share @diamond.g 's lack of understanding.

My problem here is that there's a difference between _facilitating_ a dialog, and _having_ a dialog. When you connect to Amazon, you just want to make sure you are having response from amazon. The network hardware may relay that dialog as many times as needed without your awareness. The only thing that is guaranteed is that (1) information does come from the participants, and (2) that man in the middle does not see its content.

But man in the middle can amplify it as many times as he/she wants without having access to content, as long as both points are willing to talk at all (and in fact it does, in the form of routers, backbones, satellites etc.)

Since the modern keyless entry keyfob is always in the mode "willing" to be talking to the car, instead of such dialog being proactively initiated by a key press by the owner, it would seem signal amplification is still a problem since the dialog between keyfob and the car can be facilitated at any moment without owner's awareness.

By that logic, bluetooth connection should be just as vulnerable (although perhaps just harder to hack because of hardware availability and the fact that it has to be maintained all the while the vehicle is being driven). Perhaps, challenge-response gives a solution to not being able to drive far away, but it would seem it should still be possible to yield the control within the amplified area (i.e., to get in, although perhaps not to drive too far)
 
Last edited:
  • Like
Reactions: Omniver
I am well aware of how asymmetric encryption works however I must admit I still share @diamond.g 's lack of understanding.

My problem here is that there's a difference between _facilitating_ a dialog, and _having_ a dialog. When you connect to Amazon, you just want to make sure you are having response from amazon. The network hardware may relay that dialog as many times as needed without your awareness. The only thing that is guaranteed is that (1) information does come from the participants, and (2) that man in the middle does not see its content.

But man in the middle can amplify it as many times as he/she wants without having access to content, as long as both points are willing to talk at all (and in fact it does, in the form of routers, backbones, satellites etc.)

Since the modern keyless entry keyfob is always in the mode "willing" to be talking to the car, instead of such dialog being proactively initiated by a key press by the owner, it would seem signal amplification is still a problem since the dialog between keyfob and the car can be facilitated at any moment without owner's awareness.

By that logic, bluetooth connection should be just as vulnerable (although perhaps just harder to hack because of hardware availability and the fact that it has to be maintained all the while the vehicle is being driven). Perhaps, challenge-response gives a solution to not being able to drive far away, but it would seem it should still be possible to yield the control within the amplified area (i.e., to get in, although perhaps not to drive too far)

Your argument seems to be that a hardware amplification attack is invisible to the devices on either end. One way this could possibly be defeated is if there is an echo or ping time used in the communication that makes it apparent to the car if the key fob is in close enough proximity.... the man-in-the-middle would be creating a signal level that looked like it was 10 meters away but the ICMP messages or whatever would indicate a much longer "ping time" indicating that the device is further away.
 
  • Informative
Reactions: Omniver
So, this article from Wired is pretty good, and as I postulated, some of the methods of protecting against these attacks include enforcing a low TTL of the communication times;

Just Two of These $11 Gadgets Can Steal a Car

Qihoo's researchers suggest that carmakers and component companies like NXP could prevent the relay attack by requiring tighter timing constraints in the call-and-response communications between key and car. Relay the signal from too far, and those limits could prevent the fraudulent transmission from being accepted.

The other method to foil the attack falls to the car owner: Keep your keys in a Faraday bag that blocks radio transmissions—or, in a pinch, in a metal box, like a fridge, that performs the same function. Storing your keys in the equivalent of a tin-foil hat may sound paranoid. But if the Chinese researchers' work is any indication, attacks on automotive keyless entry systems may get significantly easier—and more common—before they get fixed.
 
As stated by those above, encryption does nothing to stop a relay attack. In theory, the Model 3’s use of your phone’s encrypted Bluetooth is just as susceptible - just needs some different equipment than what the attackers are using today. Measuring message timing to detect likely extra hops is the only way I can think to defat this - but this is non trivial.

I do cyber security for a living, but I’m not an RF/Bluetooth engineer. Can anyone knowledgeable speak on how reasonable it would be to do message timing analysys on Bluetooth messages when you only have detailed knowledge of the equipment on one side? (ie you’d have no knowledge of the delays created by different phones/operating systems on one end, only the Tesla end.