Re: CYPHERPUNKS TO THE RESCUE

["Ian Farquhar" <ianf@simple.sydney.sgi.com>]

On Jul 26,  3:23pm, Matt Blaze wrote:
> Both base and remote need to store a shared key and a counter; the remote
> needs a transmitter and the base needs a receiver.  To authenticate
> itself, the remote sends {counter, hash(key,counter)} and then increments
> its counter.  The base calculates the hash for the received counter value,
> verifies that it matches the received hash value, verifies that the counter
> increases the stored counter value, stores the new value,  and opens
> the door.

You'll need to allow support for multiple transmitters, as many doors need
such support.  This is a trivial modification:

	{unit_id, counter, hash(key, counter[unit_id])}

The base station will need to keep the current key counter for each transmitter
it stores, indexed by unit_id.

Of course, one could also argue that the presence of the counter is
unnecessary,
as the receiver and transmitter both should KNOW what it's value/acceptable
range is, and transmitting it in the clear is unnecessary.

I would still argue that some sort of very coarse (~5 minute accuracy would be
sufficient) timestamp would be very useful here, although clock drift is still
a
problem (unless the base station tracked and recorded the drift).

>A practical system system also probably include some mechanism
>for rekeying and for zeroizing the counters.

Preferably NOT over an air-interface of any kind.

> permit an conventional exhaustive search for key.  If the hash space is
> too small (say, 16 bits or so), the adversary can select an unused counter
> value and probe the receiver with random hash values until the door opens.

Bear in mind, folks, that almost all current systems are cleartext-to-air
passwords, usually 8 or 10 bits in length.  I have pulled apart enough units
to know, and it's amazing how many of their passwords are set to 0000000000!

							Ian.