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
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
Return to July 1994
Return to “jim@bilbo.suite.com (Jim Miller)”
1994-07-26 (Tue, 26 Jul 94 16:08:19 PDT) - Re: CYPHERPUNKS TO THE RESCUE - jim@bilbo.suite.com (Jim Miller)