No. This could relay the challenge to the key, and the response back to the car. The attacker doesn't have to know any secrets to do that attack.

If you put the car's public key on the fob, the fob can validate that it is talking directly to the car over a secure connection and then the car can validate the fob's secret.

Please elaborate as to how the fob or car would detect the MITM:

1. You place device A near car and device B near fob. 2. Device A relays all Rf transmissions in the target frequency range(s) to device B, which rebroadcasts, and vice versa.

Public-key encryption / authentication only ensures that no-one in the middle is reading or editing your connection. It does not prevent someone from relaying your communication. (And a good thing too, else the entire encrypted web wouldn't work.)

Well, there may be one way. But it's not user friendly at all.

When the driver presses lock/unlock on the fob, the car first sends a signed message with a session secret. The fob checks the signature, takes the secret and creates a _single use_ auth token and signs it with the private key stored on the fob. That signed auth token is then sent from the fob to the car to lock/unlock the car.

To check if there was a MITM you would have to pull the door handle to see if your keypress was successful. If it was successful, you don't need to worry if the key was grabbed by a MITM, they can't use it even if they tried. If it was unsuccessful for some reason (e.g. the MITM knew it was single use auth token so they didn't pass the token onto the car in hopes you might not be paying attention and will press the button a second time) then there should be a manual override outside and inside the car that clears the valid auth tokens and allows you to lock/unlock/start the vehicle without sending any RF transmissions. A slot that you insert the key would work.

You're assuming user interaction with the key fob, in which case the solution is trivial.

The entire discussion here is based around not requiring interaction with the key fob.

What if the car sent out the signal and the fob received it, then sent an unlock command?

Note the vice versa:

In that case device B picks up on the unlock command and relays is back to device A which rebroadcasts the unlock command to the car.

Presumably the request could be signed.

Signatures do nothing to prevent blind relaying. Transmitting through an amplifying relay in this attack looks identical to transmitting through free space, aside from the received power level and propagation delay.

I'm suggesting that the car sends out a constant, signed signal to a certain range. The rob receives it and sends an unlock signal back to the car.

The amplifier relays that signed signal to the fob. The fob receives it and its unlock signal is relayed back to the car.

No matter what tricky message protocol you come up with, it won't matter. The car and the fob can't detect the difference between being next to each other, and being next to a set of relays rebroadcasting their signals. Not by reading and transmitting radio signals at least.

Ah, I see. You're right, then.

You can't think about this like internet security. Normal encryption doesn't care how long the network cord is. Opening your car door does. This attack lengthens the cord between client and server without touching the data on the cord so that you are genuinely logged in from an encryption standpoint, but from a world standpoint you are sitting at your office desk unable to see your car.