Remote keyless entry systems with rolling code: are transmitters really clonable?

I'm interested in developing a new proprietary remote keyless entry system with rolling code. I know, there are many on the market.

Many times I read about some transmitter/keyfob that claims to be "universal", in other words it is able to clone another transmitter, even if it uses a rolling code algorithm.

formatting link

How is it possible? It seems to me impossible to clone a true rolling-code keyfob, without knowing the used algorithm and the secret key.

Even if I know the algorithm used by the original keyfob and I use the same algorithm on a new keyfob, they can't be used with the same receiver. Indeed, the rolling-code receiver accepts only new codes (in a limited window) and the two keyfobs can't be synchronized.

Reply to
pozz
Loading thread data ...

Am 11.12.2015 um 13:18 schrieb pozz:

If you really want to develop a new system, how is it that all you seem interested in is how to break into existing ones?

It's only as impossible as the rolling code is well-designed. Many apparently aren't. It appears the usual design goal in the garage-door opener business is just to avoid the naive playback attack and to avoid that your neighbour's garage opens, too.

Actually, in that case they might be. All but the most braindead systems will offer a way to (re-)synch a keyfob with the receiver, to cover use cases like battery switching in the fob, or addition / replacement of fobs.

Reply to
Hans-Bernhard Bröker

I'm interested in knowing hot other break existing systems so I can design a better system.

Yes, but many "universal" transmitters claim to clone a rolling code transmitter simply putting the original and new face-to-face, without touching receiver.

I agree with you, I think it's impossible with a well-designed system.

Reply to
pozz

As I understand it, with enough sequential codes you can break it.

The idea is that in normal use, there won't be enough, but if you hold down the button long enough, so that it can get enough codes, it can do it. The cloning process is specific on how long you need to do it.

That is close to how well I know it. I don't know how much computation is needed after you have a code sequence. Maybe longer sequences require less computation.

In addition, the receiver has to accept non-sequential codes, as you might press the button away from the receiver. It has to be able to catch up.

-- glen

Reply to
glen herrmannsfeldt

formatting link
has some details, particularly on the KeeLoq system which also has a separate article. Basically those fobs could have been designed securely, but they weren't.

Reply to
Paul Rubin

Il 12/12/2015 00:25, Paul Rubin ha scritto: > pozz writes: >> How is it possible? It seems to me impossible to clone a true >> rolling-code keyfob, without knowing the used algorithm and the secret >> key. > >

formatting link
has some details, > particularly on the KeeLoq system which also has a separate article. > Basically those fobs could have been designed securely, but they > weren't.

I already read that articles, but I can't find anything about the possibility to *clone* an original keyfob.

First of all, attacks referenced in those articles are only for Keeloq system. If another system is used, how a "universal" transmitter can replicate the behaviour of the original transmitter?

Even for Keeloq, they talk about "Replay attack" and "Side-channel attack" that are oriented to thieves that need only one-time valid code to open and steal the car. "Bute-force" could work, but they can't be used to *clone* an original transmitter.

It seems to me, the cracks of Keeloq system can be used to clone an original keyfob.

Reply to
pozz

What does "well designed" have to do with these systems? I expect the rolling code clone can work because there are only a few major makers and so only a few different rolling codes.

--

Rick
Reply to
rickman

From Keeloq article:

IIUC all what is needed is to use side-channel to build katalog of master keys corresponding to various manufactures and then you can clone at will.

AFAICS the main problems are:

- use home-grown encryption method (such method frequently contain weaknness unknow to creator, but which can be find when details get known to the public)

- large part of code is common to all devices from given manufacturer, so you can extract common part from one device and then easily break other

- too short encrypted message

With 128 bit messages you can use standard cipher, like AES. If you ensure that each encoder/decoder pair has its own key, than attack via common code no longer applies. Of course, jamming and reply attack still applies. To avoid reply attacks you need two way communication, there are well-known challenge-response protocals. Basically, if you ensure that attacker can not predict the challenge, then whole class of attacks becomes impossible.

Now, practically you have problems:

- ensuring that devices get good keys is tricky (think about installer which uses the same key for all devices or assigns codes in arithmetic progression). Note that assigning code at factory has risk that method used to genereate codes leaks and then all devices may be compromised.

- strong encrytion and two-way communication may cause troubles with antiencription laws in some countries

- IIUC individual device is allowed to transmit on 432 band only for tiny percentage of time, so you may run out of bandwidth when you try longer messages

- you need more complicated device (probably processor) instead of simple hardware used for existing systems

--
                              Waldek Hebisch
Reply to
Waldek Hebisch

There's a unique key in each device.

Reply to
Paul Rubin

But the algorithm can be determined. With a few samples you can determine the key.

--

Rick
Reply to
rickman

Looking at the KeeLoq wiki article, this can be done but it's harder than it sounds. It could be that the cloneable units are using a weaker system. If the things were designed by cryptographers, then finding the key by eavesdropping would be essentially impossible. On the other hand, the attacker can always break into the car by smashing the window.

Reply to
Paul Rubin

Rubbish. Timestamp is used for exactly this purpose in the most widely-used and comprehensively scrutinized authentication protocol - the Kerberos AP (Authentication Protocol) which is the basis of Windows domain authentication. It avoids the need for a bi-directional challenge (CHAP), because the time is used to locally generate a challenge.

If your computer's time is more than five minutes off, your Windows domain login will fail.

Reply to
Clifford Heath

Not necessarily; you can use timestamps. Transmitter and receiver both have reasonably-accurate clocks (like, "digital watch" accuracy, not "atomic clock"). The transmitter sends the current time as well as a code which is derived from the current time and the device's unique key. The receiver rejects the code if the code doesn't match the timestamp or ID, or if the timestamp is too far from what it should be, proportional to the elapsed time since the last accepted code.

Some form of re-synchronisation needs to be performed if either end needs to be replaced. Multiple transmitters would need the receiver to track each one separately.

With a strong cipher (or hash), and a key too large for a brute-force search, even a few million plaintext/ciphertext pairs shouldn't be enough to derive the key.

This is the real issue.

Strong ciphers (or hashes, or pseduo-random number generators) need significantly more silicon than a weak pseudo-random number generator (e.g. LFSR). Accurate timekeeping needs a crystal rather than an RC oscillator, and backup power to avoid needing to re-synchronise if you change the transmitter battery or the vehicle has the battery disconnected during servicing.

Whereas wireless fobs seem to aim for the complexity of a 74-series chip.

And that's the ones used for protecting cars. When it comes to things like wireless doorbells, you're lucky if it only gets triggered by random EMI once an hour.

Reply to
Nobody

I don't think anyone is doing that. I expect it is too costly in some regard, power, computation, dollars....

So build a better doorbell and the world will beat a path to your door?

--

Rick
Reply to
rickman

No.

No.

Every attacker can make timestamps at least as easily as the keyfob, probably better, because he's not bound by having to work for a long time on a very limited energy source. So time doesn't add any safety to the system.

Replay attacks are blocked by adding _sequence_ to the mix, not time. I.e. the receiver and sender both keep a record of what their previous key was. That key is burnt, and only the next (few) keys are accepted.

The real weak points, however, are transmissions not seen by the receiver, and re-synchronization after power loss.

The lock, being (somewhat) stationary, with more power available, may be save its state to non-volatile memory on apparently imminent power loss, so that can be kept reasonably painless. Power loss of the keyfob is harder. There has to be some way to re-synchronize the fob after exchanging its battery over the air, or by putting the lock into a special "learning" mode.

Car keys use a combination of approaches:

  • Key presses that the receiver didn't see are tolerated to some extent by allowing any of the next N keys in the sequence, at the price of throwing some of the cryptographic power away.

  • If you waltz further off-sequence (think of kids playing with the blinky light on the fob, or some object in your pocket pressing it on every step), or after a battery change in the fob, re-synchronization is achieved by checking that the receiver sees two or more rolling keys in the right order.

  • The final back-up solution is that a repair shop can re-synchronize any key (including an entirely new one) to the lock by physical access from inside the car. In somewhat current systems this is further strengthened by requiring a secured internet link to the manufacturer's database servers, which only licensed dealerships get to use. That way the true master key never leaves the manufacturer's site(s).
Reply to
Hans-Bernhard Bröker

The idea is the timestamp is authenticated by a secret key in the fob. So if the attacker captures an authenticated timestamp, it's only useful for 30 seconds or whatever, and the authenticated timestamp was presumably only sent when the car owner was standing in front of the car. Alternatively if the attacker gets access to the physical fob in the owner's absence, they have only 30 seconds to use the code, so they must be close enough to the car by using the real ones.

How about just clicking the fob after pressing a button inside the car, or turning the physical key in the lock. That updates the lock to the fob's idea of the time.

This is good if you have to initialize a new fob, but sounds like overkill if you still have the original fob with the internal secret key, and only need to resynchronize it after a battery change.

Reply to
Paul Rubin

When was the last time you saw a 74-series chip? You can get an MCU today for what a 7400 used to cost.

Reply to
Paul Rubin

Am 14.12.2015 um 19:31 schrieb Paul Rubin:

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.

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.

And if you do it properly, the captured data is _completely_useless_ to him, because the moment it's been received by the lock, it immediately becomes invalid for future use. Not 30 seconds later, but right then and there.

That's one possibility to re-synchronize.

But really, get that "timestamp" idea out of your head. It makes no sense; it offers exactly zero protection value.

That's what the "press it multiple times" intermediate scheme is for, which you opted to skip over.

Reply to
Hans-Bernhard Bröker

I don't understand that. It's just like TOTP which is used widely:

formatting link

In the microamp range, like a digital watch. The limiting factor is the battery shelf life as much as the device's power drain.

In both cases they need the secret key that's inside the fob, and if the crypto is any good and they can't destructively examine the fob, they have no way to get that. They can't generate any new codes without it.

If the lock opening invalidates the code, then you can't use the fob again for the next 30 seconds. That might be annoying. OTOH lowering the interval to 5 seconds could take care of that.

You keep saying that but you haven't explained why you think it's true.

Reply to
Paul Rubin

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.

-a

Reply to
Anders.Montonen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.