On Mon, 14 Dec 2015 23:21:42 +0100, Hans-Bernhard Bröker wrote:>> The idea is the timestamp is authenticated by a secret key in the fob. > > One could do that, but choosing a timestamp for that job, instead of any > other pseudo-random data, offers no benefit at all. The keyfob will just > continuously burn precious power running its clock, instead of only waking > up on key-press. And all that consumption will be for nothing.The power consumption of a clock is negligible. Digital watches can run for over a year on a tiny cell, and they're also driving the LCD. A fob needs to power a transmitter; each button press will use what the clock uses in a month.> Actually, using a timestamp would be a heck of a lot worse than any > remotely sensible pseudo-random number. With a rolling code they would at > least have to observe or guess how often you used the original key since > they recorded your signal to generate the next one to use for their > attack. With a timestamp, all they need is a clock. It doesn't get any > easier.Fixed rolling codes are vulnerable to interception attacks. The attacker receives one code while preventing the from receiving it. Then it does the same for several following codes. Then it transmits the first code, unlocking the car, and keeps the following codes for later use. Executing such an attack isn't trivial (you have to interfere with the car's reception without interfering with your own), but if you can manage it, it doesn't matter how good the crypto is. The point about a clock is that the receiver's clock advances automatically. So long as at least one code is accepted, any codes transmitted around that time will expire almost instantly. It's effectively a challenge-response system without the need to actually transmit a challenge. The fact that the challenge is known well in advance only helps if you can break the crypto.>> So if the attacker captures an authenticated timestamp, it's only useful >> for 30 seconds or whatever,Probably not even one second. A 32-bit timestamp with one-second granularity rolls over every 136 years. And rollover doesn't really matter. If you transmit with a different code ten times per second and it rolls over after 13.6 years, no-one is going to wait that long to break into your car.
Remote keyless entry systems with rolling code: are transmitters really clonable?
Started by ●December 11, 2015
Reply by ●December 16, 20152015-12-16
Reply by ●December 17, 20152015-12-17
On 2015-12-16 Hans-Bernhard Bröker wrote in comp.arch.embedded:> Am 15.12.2015 um 21:25 schrieb Paul Rubin: >> Waldek Hebisch <hebisch@math.uni.wroc.pl> writes: >>> And keys seem to have fancy functions that require processor (and >>> probably also two way communication) >> >> I don't know of any keys/fobs with two way communication. > > Never heard of keyless entry and start systems, where you only need to > have the key with you, but no need to take it out and press any buttons, > then? > > Those do use two-way comms. They don't radio quite as far as your usual > remote lock fob, though.But the bad guys have found a solution for that: amplify the signals so a key in your house will start your car. Then drive off (the car keeps driving without key as long as you don't switch it off) to a safe place and have all the time you need to hack or strip the car. I'm not sure this has actually been done or if it was only suggested as a theoretical attack. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Someone will try to honk your nose today.
Reply by ●December 17, 20152015-12-17
In article <n4p7lb$c3r$1@speranza.aioe.org>, Anders.Montonen@kapsi.spam.stop.fi.invalid says...> > Hans-Bernhard Br�ker <HBBroeker@t-online.de> wrote: > > > Actually, using a timestamp would be a heck of a lot worse than any > > remotely sensible pseudo-random number. With a rolling code they would > > at least have to observe or guess how often you used the original key > > since they recorded your signal to generate the next one to use for > > their attack. With a timestamp, all they need is a clock. It doesn't > > get any easier. > > I don't remember where I heard this attack described, but: > - When the user clicks the fob, an attacker records the transmission > while also blocking reception by the car. > - When the car doesn't react, the user clicks the fob again. The > attacker also records the second signal. > - The attacker now replays the first signal, activating the lock. He > still has the second signal with the next code in the sequence banked, > and can use it to unlock the car. > > -aMan in the middle attack, which you CAN use on boundaries of wifi, see various quotes and articles about ising drones to do this. The emphasis is on "middle" as you have to between so your signal can be stronger than the originator. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/pi/> Raspberry Pi Add-ons <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.badweb.org.uk/> For those web sites you hate
