h a l f b a k e r y"Bun is such a sad word, is it not?" -- Watt, "Waiting for Godot"
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
| |
[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). |
|
| |
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? |
|
| |
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. |
|
| |
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. |
|
| |
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. |
|
| |