Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Assume a hemispherical cow.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


         

Please log in.
Before you can vote, you need to register. Please log in or create an account.

No encryption Key Fob

 Using Solid State Memory.
 
(+1, -1) 		  [vote for,
against]

Considering the recent proof that the electronic entry for the prius has been compromised, It is time to consider a different method of security, that could also go well beyond this application.

Solid-state memory has gotten to be very compact and reliable. Flash drives with many gigabytes of memory are now commonplace. The now small size/ portablility of memory can now allow us to use methods other than encription only to ensure security.

Many of us has seen the movie crimson tide, and others where in order to arm and fire a nuclear missle, they need to authenticate. A code is created and 2 copies are made, one for those in command and those with launching capabilities. They read the code to eachother and if they match, they have been "authenticated."

I envision the same system but on a larger, and slightly more sophisticated scale. How many authenticating codes can you store on 2 gigs of memory? If your codes were very long, maybe 100,000?, a billion? (I know there's 8 bits to a byte but other than that I'm not sure). How many times do you need to use your key fob per day? 20 times? 40 times? If it takes about 2 years or so to cycle through the codes and start over again, I would say that this is a worthy security method.

Ok, here's how I specifically see it happening: The car's ignition system and the keyfob have the same memory with the same codes stored in them, and are individual to that care and key fob. The keyfob is pressed and it sends out a signal with a code that matches the code that is in the data space with the memory in the car. (I hope i make sense, i dont' know all the terms). In this first event, the car authenticates back with the same code if it is. If it is, it then askes the key fob for a code from a predetermined space in the memory, maybe a code halfway through the memory spaces. This way, nobody can just press your keyfob, record the signal and get into your car.

Once you have gotten into your car, the signal on your keyfob advances to the next code, as well as with your car. You can get the same code twice, but it would take a at least i would say 6 months to cycle through the memory. Who knows, it could be years until you get through the entire memory and have to cycle through again.

What do you all think? It is the same authentication as nuclear arms x 2, but on a micro scale. Of course, you could always add encription to beef it up, but this is my idea.

It is like having 2 identical lists of random numbers. The 2 parties (key fob and car) know where they are on the list. The keyfob calls out the number of the current position. If it is the corresponding number, the car will call back and ask for a different code.

The datablock position is kept in some kind of ram that will lose it's position if the the thing loses power from the battery. Someone may be able to take the key fob apart but once they disconnect the battery they won't know where from the list to call numbers from. They may have all the codes from the memory but the car authentication system will not allow for the submission of more than one code per second, and could even sound the alarm if it seems like the code is being cycled through really quickly.

I hope some of you got through my horribly electronics comprehension. It was hard enough for me.

—twitch, Aug 26 2007

[link]






       [twitch], your idea is on the right track, because most remote systems use a similar principle. As far as I can recall, the fob generates a new code each time, using a psuedo random generator. The car has the same code generator, and steps to the next code when the car is opened. The car can also accept the next 255 codes in the sequence. Why? Because sometimes the fob is pressed out of range, and things could get out of syncronisation. When a correct code is received, the car re-syncronises again. This is why you can prevent your friend getting in his ferrari (by pressing the fob more than 255 times out of range).
—Ling, Aug 27 2007
   

       What would be the advantage of this? And with a long code, isn't there more of a chance of parts of the signal not transmktting? In other words current key fobs are fast because their codes are very short, simple. While this might work it would at add transmission times, wouldn't it?
—evilpenguin, Aug 27 2007
   

       I've implemented a system much like this. There are two copies of each key stored in the lock and in the fob. When the user presents a fob, the sequence of events is as follows:   

       -1- Check to see if either space in the fob matches either space in the lock.   

       -2- Generate a new random key   

       -3- Write the this new key into the spaces that weren't observed to match in step 1.   

       -4- Verify that those writes have taken place.   

       -5- Write the new key into the spaces that were observed to match in step 1.   

       -6- Verify that those writes have also taken place.   

       -7- Spring the lock.   

       This approach has some advantages. Using a key will render any previously-made copies of the key worthless. Unlike counter-based code-hopping schemes, this one would not allow an intruder to 'push forward' a stolen key.   

       The primary disadvantage of this method (and it's a big one) is the need to have routine bidirectional communication between the fob and the lock.   

       Communications between the fob and the lock could be encrypted using the current keys. Unless one knew the current key, an intercepted copy of the communication would likely be worthless unless one could decipher it before the next access attempt took place.
—supercat, Aug 27 2007
   

       As others have said, you have just reinvented the One Time Pad (OTP). As far as I know, true OTPs are not used in key fobs.   

       (SecurID only uses 128 bits of secret, not 100's of Megabytes as proposed.)   

       A large amount of secret information could be used to augment security, however. This would make known plain-text attacks much harder to mount on these devices. A challenge could consist of a pseudo-random seed used as a series of indexes into the random pad. The key fob could then respond with a 128 bit hash of the series of 128 bit blocks sent as the challenge.
—StCredZero, Aug 27 2007
   
      
[annotate]
   


 

back: main index
business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle