CYPHERPUNKS TO THE RESCUE

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                         SANDY SANDFORT
 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C'punks,

On the noon news in San Francisco, there was an item of crypto
interest.  It was about something I think they called the "Code
Grabber."  It is a device which receives and records the coded
RF signals used to remotely unlock car and garage doors.

The hand-held unit is a little larger than a paperback book.  It
has a half dozen switches on it.  After you intercept someone's
code, you can play it back anytime to control that person's car
lock or garage door.  It's kind of like a TV universal remote.

Some politicos have already started talking about banning it, but
I think just the publicity will guarantee a healthy black market
in such devices.  The public will be clamoring for a solution.
Enter the Cypherpunks.

How can this nifty burglary tool be outsmarted?  How about a
replacement system that uses strong crypto?  The Code Grabber
represents a great opportunity for an inventive Cypherpunk to
make some money AND promote crypto awareness.

The questions are:  Could standard auto and garage door openers
easily be retrofitted?  Could a "crypto remote" with its own CPU
be made small enough to fit into a hand-held unit?  Could such a
system be made for a reasonable cost?


 S a n d y

P.S.  I bet there are some other interesting uses to which such a
      device could put.  Any ideas?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Mon, 25 Jul 1994, Sandy Sandfort wrote:

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>                          SANDY SANDFORT
>  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 
> C'punks,
> 
> On the noon news in San Francisco, there was an item of crypto
> interest.  It was about something I think they called the "Code
> Grabber."  It is a device which receives and records the coded
> RF signals used to remotely unlock car and garage doors.
> 
> The hand-held unit is a little larger than a paperback book.  It
> has a half dozen switches on it.  After you intercept someone's
> code, you can play it back anytime to control that person's car
> lock or garage door.  It's kind of like a TV universal remote.
> 
> Some politicos have already started talking about banning it, but
> I think just the publicity will guarantee a healthy black market
> in such devices.  The public will be clamoring for a solution.
> Enter the Cypherpunks.
> 
> How can this nifty burglary tool be outsmarted?  How about a
> replacement system that uses strong crypto?  The Code Grabber
> represents a great opportunity for an inventive Cypherpunk to
> make some money AND promote crypto awareness.
> 
> The questions are:  Could standard auto and garage door openers
> easily be retrofitted?  Could a "crypto remote" with its own CPU
> be made small enough to fit into a hand-held unit?  Could such a
> system be made for a reasonable cost?
> 
> 
>  S a n d y
> 
> P.S.  I bet there are some other interesting uses to which such a
>       device could put.  Any ideas?
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sandy, 
  
 When I saw that commercial for the remote control deal with the minivan 
and that nice big luxury car I thought about someone being able to 
figurethe frequency and be able to open that door and start the engine. 
Makes you think about getting one of those systems for your car. And, I'm 
sure if someone can come up with a way to encrypt those cars, they could 
make some money. The only thing is you have to hope the person who makes 
it doesn't put a back door in the crypto and that car manufacturers won't 
try and do the Clipper Stunt themselves (ie. they put in a back door)...

Aaron


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-=- 	YABBS - telnet phred.pc.cc.cmu.edu 8888                       -=-
-=-    								      -=-
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

8086's are very cheap these days.  They have enough computing power to run
something like IDEA, albeit very slowly.  I'd use a challenge/response method
with something like this, because you have to keep in mind that encrypted
signals can just as easily be captured.

You'd need a clock on the garage controller.  CMOS clock chips
anyone?  It doesn't have to be acurate to the second, but certainly to the
minute, and have date, month and year available to it.   The garage opener
would receive a signal from the remote, issue a challenge code based on a
hash of the time/date + some random numbers.  The remote would encrypt this
hash with the owner's IDEA key and send back the response.

Both units would need some sort of keypad to program the codes into them.  A
backup batery for both sides is also important along with a warning that
the main battery has failed.  You wouldn't want to lose access to your garage.

I suppose some backup entry system would also help... a two key system (using
physical keys with high security mushroom pin locks, etc.)  Remember that should
the remote opener fail, the driver would be damned pissed at crypto and we
want him very happy.

C'punks,

On Tue, 26 Jul 1994, Arsen Ray Arachelian wrote:

> 
> You'd need a clock on the garage controller....The garage opener
> would receive a signal from the remote, issue a challenge code based on a
> hash of the time/date + some random numbers.  The remote would encrypt this
> hash with the owner's IDEA key and send back the response.

Am I missing something here?  Why would you need a clock?  What I had in 
mind was something like:

	1--The owner presses the "open" button on the remote.
	2--The remote sends an "ask me" signal to the door unit.
	3--The door unit transmits a random number in the clear.
	4--The remote encrypts and signs the random number using
	   its unique private key.
	5--The door unit decrypts and compares the numbers, using
	   the remotes public key.
	6--If the numbers match, the door opens.  QED.

Adjusting my flame retardant underwear,


 S a n d y

P.S.  For most car and garage doors, relatively short (32 bit?) keys 
      should be more than sufficient, I would think.

A challenge /response may make sense crypto-wise, but not $$-wise.
The car would then need a receiver too, & the house a transmitter.
More things to buy & break.

A one-way solution is needed to make it fly here.
-- 
A host is a host from coast to coast.................wb8foz@nrk.com
& no one will talk to a host that's close............(301) 56-LINUX
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433

From: wb8foz@nrk.com (David Lesher)
   Date: Tue, 26 Jul 1994 18:51:19 +0000 (GMT)

   A challenge /response may make sense crypto-wise, but not $$-wise.
   The car would then need a receiver too, & the house a transmitter.
   More things to buy & break.

   A one-way solution is needed to make it fly here.

Okay, here's my "bright" "idea"...

A 32-bit counter, a 32-bit somewhat-random "salt", a 32-bit fixed
authenticator and a 32-bit checksum, two DES blocks.  The transmitter
just counts up each time the button is pressed, and the whole thing is
DES'd in CBC mode with the symmetric key or what have you.

The receiver decrypts, verifies the checksum and perhaps the
authenticator and just checks for the count to be greater than the
last time it received a signal.  This handles replays and doesn't
require exact sync between remote and base.

The receiver can have a reset button inside so the owner can push it
and click the remote if somehow the receiver gets skipped way ahead.

Counterexamples, anyone?

From: wb8foz@nrk.com (David Lesher)
   Date: Tue, 26 Jul 1994 18:51:19 +0000 (GMT)

   A challenge /response may make sense crypto-wise, but not $$-wise.
   The car would then need a receiver too, & the house a transmitter.
   More things to buy & break.

   A one-way solution is needed to make it fly here.

Okay, here's my "bright" "idea"...

A 32-bit counter, a 32-bit somewhat-random "salt", a 32-bit fixed
authenticator and a 32-bit checksum, two DES blocks.  The transmitter
just counts up each time the button is pressed, and the whole thing is
DES'd in CBC mode with the symmetric key or what have you.

The receiver decrypts, verifies the checksum and perhaps the
authenticator and just checks for the count to be greater than the
last time it received a signal.  This handles replays and doesn't
require exact sync between remote and base.

The receiver can have a reset-to-zero button inside so the owner can
push it and click the remote to re-sync if somehow the receiver gets
skipped way ahead.  This DOES, however, require different counters and
authenticators for different remotes.

It can also be done with a one-way hash if the salt is omitted and the
receiver can try, say, the next few dozen sequence numbers against the
received string.

Counterexamples, anyone?

Eric Weaver  Sony AVTC  3300 Zanker Road, MS 4B1  SJ CA 95134  408 955-4904
& Chief Engineer, KFJC 89.7  Foothill College  Los Altos Hills, CA 94022