Re: Rolling Code Generation?

Dude, you are going way off track here. No one ever suggested that an LFSR is secure. The only point is that it is harder to defeat than a fixed pattern with no code. It is always a matter of how much effort do you want to spend to require the hacker to spend more effort?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman
Loading thread data ...

..and for just a tiny bit more effort on the part of the designer to move from an LFSR to a real encryption algorithm, you can raise the difficultly level for the attacker to the point of making it almost impossible to crack. That is why is makes no sense to design a simple LFSR into a rolling code device.

-Robert Scott Ypsilanti, Michigan (Reply through newsgroups, not by direct e-mail, as automatic reply address is fake.)

Reply to
Robert Scott

I see your point, but I don't agree that it is a "tiny" extra effort. I can implement an LFSR in my sleep and there are even free programs available to generate the taps and HDL (which is easy to change into C) for any LFSR you wish. So the transmitter could easily be implemented in hardware without an MCU. I expect I could do the entire design in an afternoon.

But then you may have experience with a "real encryption" algorithm that I don't. So to each his own. :)

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

Not quite. The transmitter has RAM and is expected to lose its memory once in a while (thus the need for resync).

The car has battery-backed RAM (via the car battery, not a special battery) and only takes 4 bytes per transmitter (if memory serves), not umpty-ump Kbytes. If you only cache resync commands, it takes a long time for the resync queue to wrap around in the threat scenario included in the customer requirements document.

I have to switch my attention to other things. The patents spell it all out and are probably more accessible to engineers than most (I insisted they be more in "real" English and less in patentese to the degree the lawyers would go along with it).

Phil Koopman -- snipped-for-privacy@cmu.edu --

formatting link

Reply to
Philip Koopman

If the transmitter loses its RAM, won't it restart at the same point each time? How could it work with any real security in that case?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

At the first glance, one might answer that a human-operated device has a good source for true random data. After a second thought, though, one must realize that the device is supposed to open the door even at the first button-press (even after RAM failure), so actually there's not much random to learn - thus not really lots of security.

On the other hand, I never got the impression that this rolling code stuff is high security art. Most developers, be it big players or small people, seem to cut corners whereever they see fit. Many regard a system resistant to occasional playback attacks already as "high security".

I think this has a long tradition, even with locks in general. Many house frontdoor locks have 5 bits with 3 possible positions each, and total at only about 250 possible keys. Many rolling codes can be defeated easily, because they were designed by the same guys.

Marc

Reply to
jetmarc

When you have a hammer, everything tends to look like a nail.

I bowed out of this one a while back. But a simple rolling counter, with a encryption algorithm can run on a tiny MCU, they generally have a little bit of EE in there also to keep where it's up to.

All you need is a 'sync' phase between transmitter and receiver so they can share encryption keys and current counter value and your done. It's really very simple, and very secure.

As has been said many time here before the receiver gets the encryped data, and starts rolling forard it's counter looking for a match (up to say 1000 counts). If it finds one, it's saved counter is updated to the found value and Aladins treasure is revealed.

Have a look at TEA. I like it because it's tiny, simple, fast, and in C.

Ralph

Reply to
Ralph Mason

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.