5 ms·

So, what is the solution? Implementing a PKI over between the key and the car? This would be quite nice, wouldn't it? -Key asks car to unlock and sends public

• deleted 9y ago
  [deleted]
• weinzierl 9y ago
  This would prevent the attack but would be difficult to implement for existing car models. The car most probably lacks the hardware to send at 315 MHz. Not that the key had the ability to receive either, but that means that you'd not only have to replace the key fobs but do a full recall campaign with new hardware in the car.
  • netsharc 9y ago
    Speaking of the car, it has a receiver scanning that band, it should just detect that there's a jamming signal, and somehow prompt the driver to use the physical key to get in. Do modern cars still have physical keys?
  • netsharc 9y ago
    Speaking of the car, it has a receiver scanning that band, it should just detect that there's a jamming signal, and somehow prompt the driver to use the physical key to get in. Do modern cars still have physical keys?
  • netsharc 9y ago
    Speaking of the car, it has a receiver scanning that band, it should just detect that there's a jamming signal, and somehow prompt the driver to use the physical key to get in. Do modern cars still have physical keys?
• exhilaration 9y ago
  A simpler solution is that the car should not accept a "skipped over" code. This attacks works by jamming code A and storing it for later use. The car owner assumes a signal loss and clicks again, opening their car with code B. If the car knows to reject code B in the future, why can't it also know to reject code A?
  • bjt2n3904 9y ago
    This is effectively how a rolling code works. You have a space of say, 2^16 keys that repeats. The car and keyfob share the same index to the keyspace, and increment one for every transaction. If someone tried to "replay" an older key, the car would reject it. However, what if the user accidentally presses the button while not in range of the car? To account for this, the system will "partially accept" keys "ahead of schedule" for about half the keyspace. The car advances its pointer (let's say N+5), and waits for N+6 to unlock. Since most older keyfobs are simply "one way transmitters", PKI is out of the question. Newer keyfobs are able to receive as well, and could preform a handshake. However, car manufacturers are notoriously bad at security.
  • echion 9y ago
    The car isn't being opened by B; it's being opened by A, and B is jammed and stored for later use. See other comment about the attacker always being "one [code] ahead" of the legitimate key fob user.
    • exhilaration 9y ago
      Thank you for the clarification!
  • falsedan 9y ago
    That's not how the attack works though: the fob sends A, but the car doesn't see it because of the jamming. The fob then sends B, and the car still doesn't see it. Then the attacker stops jamming the car's receiver, and replays A, so the doors open. B is stored by the attacker to replay later.
  • retSava 9y ago
• IshKebab 9y ago
  You don't need PKI for this - the car and the key have pre-shared keys. All you need is to include a counter in the signal that is incremented for each button press. The car remembers the last counter value it receives and ignores any before that. Obviously the counter needs to be encrypted in some way but it's not exactly difficult. I'm kind of amazed this still happens in 2016. Or maybe it doesn't. The cars could be old.
  • Unhackable 9y ago
    This usually that attack method with the added benefit of making a mesh network out of it using LoRa signals.
  • ethbro 9y ago
    Assume you're getting downvoted instead of commented on because, as above poster pointed out, the weak point is the counter in any one-way scheme. Specifically when the car doesn't see a fob press but the fob is pressed (e.g. out of range / blocked). Thus, you have a broken keyfob if you ever press it outside the car's range (or require a "re-pairing" handshake to resynchronize the counters). Infeasible due to terrible usability. Or you widen the window of accepted counters to avoid the above issus. Which is what this attack is preying on.
    • IshKebab 9y ago
      Err, no. You wouldn't require then counter to go up by exactly one each time. You just wouldn't allow it to go backwards.
• w8rbt 9y ago
  A physical key ;) like we used to have.
  • dzdt 9y ago
    This is vulnerable to high-resolution photograph and reproduction from that. Really it is a very analagous vulnerability to the one discussed in the article : an attacker in close proximity can get a good enough look at the key's secret to reproduce it.
• weinzierl 9y ago
  I wonder if there is any (even theoretical) authentication method that works with a one way communication channel and is not vulnerable to the attack described? Or maybe a proof that it isn't possible?
  • dfox 9y ago
    One thing that you can do with one way channel is to not use counter, but timestamp or preferably both at once. In this context it would require the keyfob to have reasonably accurate RTC which will certainly have some effect on battery life (which might be acceptable tradeoff given the fact that the CR2032 battery in VW's keyfobs seems to outlive the mechanical integrity of the receiver antenna on the car side). It's certainly not complete solution to the problem but allows you to arbitrarily shrink the time window the attacker has to mount this attack.
    • mseebach 9y ago
      That's how one-time password tokens like RSA SecurID and YubiKey works, and hardware/battery/cost wise, they seem to be well within scope for a car key.
      • ethbro 9y ago
        How do you ensure the clocks are sync'd? Or is there a one-channel method that doesn't require synchronized times? E.g. window-based Or is it that cheap to have ~5-10 yr accurate clocks implemented in hardware now? (Not that the margin on keyfobs seems exactly slim...)
        • mseebach 9y ago
          A combination of good, accurate clocks (remember that a $10 digital Casio drifts less than a second per day) and some functionality on the server side to detect and correct for drift. When the key window is 30 seconds, the key won't drift more than 10 keys per year, which should be easy to correct for without compromising security (and if in doubt, it's easy to "ask" for a second code - just fail the attempt, the user will try again).
• awqrre 9y ago
  I'd rather have to push a button on the key-fob then on the car...