1994-07-26 - Re: CYPHERPUNKS TO THE RESCUE

Header Data

From: jim@bilbo.suite.com (Jim Miller)
To: cypherpunks@toad.com
Message Hash: 89899ddb44dcfdb55ddbef8802d28235c78164ced82c225107e40b341af56be3
Message ID: <9407262304.AA05483@bilbo.suite.com>
Reply To: N/A
UTC Datetime: 1994-07-26 23:08:19 UTC
Raw Date: Tue, 26 Jul 94 16:08:19 PDT

Raw message

From: jim@bilbo.suite.com (Jim Miller)
Date: Tue, 26 Jul 94 16:08:19 PDT
To: cypherpunks@toad.com
Subject: Re: CYPHERPUNKS TO THE RESCUE
Message-ID: <9407262304.AA05483@bilbo.suite.com>
MIME-Version: 1.0
Content-Type: text/plain



Matt Blaze describes a couple of possible attacks against the simple  
one-way authenticating garage door opener.  The attacks are basically the  
ones that are often suggested against one-way login authentication  
protocols.  However, I think the garage door opener scenario is just  
different enough that the attacks he describes can be ignored or  
eliminated without overly complicating the devices.

(The following idea is a combination of ideas stolen from earlier posts.  
plus a couple of new ones.  Anyone following this thread should recognize  
the earlier ideas and hopefully mentally credit the original posters.)


The transmission is one-way, from hand unit to base.  There is no  
encryption involved, no hash functions, no counter values to transmit, no  
loosely synchronized clocks.  The hand unit consists a transmitter, a  
memory chip, a simple cpu chip, and some kind of jack or plug used to  
initialize the unit.

Initialize the hand unit and base with identical sets of large random  
numbers using a wall mounted panel.  The random numbers will be arranged  
in groups of, say, ten.  I'll call each group a "family".  Since memory is  
cheap, load hundreds of families of random numbers.

Both the hand unit and the base will maintain an internal counter of the  
"current family number".  As numbers from a family are used, the "current  
family number" is incremented.  If the two "current family numbers" get  
off, then the hand unit and base will have to be re-initialized.

To open the door, push the button on the hand unit (duh) to send the first  
random number from the "current family".  The base unit opens the door if  
the received number is in the "current family" of random numbers.  If the  
door opens, the "current family number" counter in the base unit is  
incremented and the remaining numbers in the previous "current family"  
become invalid for opening.  The "current family number" in the hand unit  
automatically increments after about a minute from the time of the button  
push.

If the first button push/transmission didn't get received, a second button  
push (within a minute) will send another number from the same family,  
activating the door.  If the first transmission is successful, but the  
driver continues to push the button, the subsequent transmissions are  
useless to an interceptor/man-in-middle because the numbers transmitted  
are from a family that has just become invalid for opening.

To close the door (within a minute of opening): pushing the button sends  
another random number from the original family (i.e. the same family used  
to open the door, now invalid for opening).  Since the door is in the open  
position, the base unit interprets the transmission as a request to close  
the door.  NOTE: the base unit ignores all button pushes while the door is  
in the process of opening.

WRINKLE: If you wait more than a minute before trying to close the door,  
the hand unit increments to the next family number.  Therefore, when the  
door is in the open position, the base unit will actually check the  
received random number against both the previous "current family" and the  
current "current family".

The major flaw I see in this scheme is that the "current family number" in  
the hand unit may become off frequently due to accidental button pushes.

...

Now that I've gotten to the end of the description, I'm not so sure this  
scheme is practical.  I get the feeling that the delayed auto-increment of  
the hand unit will create situations that violate the principle of "Least  
Surprise".  In other words, the hand unit may not always do what you  
expect it to do.

Oh well, I'll post my description anyways in case it induces some better  
ideas in others.


Jim_Miller@suite.com






Thread