Sandy Sandfort <sandfort@crl.com> wrote:
Am I missing something here? Why would you need a clock?
I recently used a smart card system for secure remote access to a network. It looked like both the card and the remote system had clocks that were in synch and both ran the same PRNG to produce a new number every minute. Part of the login procedure was to enter the number currently being displayed on the card. A garage door opener built on this principle would not need the ability for the base to transmit any codes, for the remote to receive any, nor to encrypt or decrypt anything. Just a continuously running, clocked PRNG, the ability for the base to receive signals sent by the remote and compare the numbers, and some provision for synching up the clock and state of the PRNG with that of the remote, probably using a physical connection. The remote would transmit a code to the opener. The code would be available to someone listening in, but it would only be valid for the current clock period. The length of the clock period would be a trade off: Too long, and someone could listen in and enter the garage after you have left but before the current code has expired. Too short, and you will have to synch up the remote and the receiver too often to be convenient. (I.e., if the clocks drift by four seconds per year, you can go quite a while with one number per minute, but less than a month at one number per second, before the system becomes unuseable without resynching.) There also has to be some provision for a retry if you happen to signal close to the transition time, within the period where they are out of synch. -- sidney <sidney@apple.com>