I have an idea of building the PIC based "electronic key", which could
allow easier computer login or door access etc.
It should be the small device containing the small keypad (eg. 16 keys),
one LED and three wire asynchronous interface.
The device should work in following way:
1) Normally it is in the "idle" state.
2) To be used, it should be "armed" - the user has to enter the password with
the keypad. After entering the correct password, the device remains armed
for eg. 10 minutes (may be there should be possibility to enter the
desired time). When armed, the LED should blink (eg. 0.2 sec flash each
3 secs).
3) If the incorrect password is entered, the device gets locked for 10 secs
(it should block the possibilities of password hacking).
4) There is an "emergency" button which allows the immediately disarming
of the device (eg. if someone tries to steal it.)
5) The armed device may be used as an "electronic key", working in following
way:
A) When connected to the computer or to the door lock, the device sends a
single character, eg. "!". The computer (or door lock etc.)
answers with the "challenge" - a random string of bytes.
Then the device encrypts the challenge using the RSA (or ElGamal to avoid
patent problems) private key, and sends it to the computer.
B) The computer checks if its database contains the appropriate public key,
decrypts the answer and checks it correctness, allowing the access if
everything is OK.
The advantages of such device are:
1) The input device (keypad) is integrated with the device, no danger, that
someone hijacks the entered password.
2) Even if someone steals the device, it can be used for anauthorised access
only for limited amount of time. (Or is completely useless if stolen in
"disarmed" state).
3) Even if someone steals the computer's key database, the device remains
safe. Only the public key must be stored in the access granting system.
The secret key is kept ONLY in the PIC located in the device.
I think that it can be done even with single PIC 16F84 (however I don't
know it allows for using 512 or 1024 bit long RSA key). The secret key
may be stored as a table in the code, but I don't know if it is possible
to implement the RSA algorithm for so long keys having only 68x8 bits of
RAM.
Anyway I'm looking for any RSA or ElGamal implementations for PIC.
Any suggestions are also appreciated. I'd like to develop such device
as an "Open Hardware" project - all diagrams and code freely available.
Thanks in advance for any help, pointers or suggestions.
--
Greetings
Wojciech M. Zabolotny http://www.ise.pw.edu.pl/~wzab <--> spam_OUTwzabTakeThisOuTise.pw.edu.pl
>It should be the small device containing the small keypad (eg. 16 keys),
The other trick to get up to is when the user comes to the keypad, they have to
activate it, e.g. by a swipe card, or maybe the first keypress. Up to this point
the keypad has no legends for the keys. The operator initiation then causes the
micro to display the key legends in random order, so anybody watching cannot
determine what the number sequence is, because the next time it is activated the
legends will be different. It would require a little extra code in the micro to
match random legends to the key actually pressed to get the correct number
entered, but it would stop "pattern matching" (top left, centre ,mid right,
bottom left) by an observer, as the operator has to enter the code corresponding
to the random legends.
On Mon, Mar 13, 2000 at 01:06:20PM -0000, Alan Pearce wrote:
> >It should be the small device containing the small keypad (eg. 16 keys),
>
> The other trick to get up to is when the user comes to the keypad, they have to
> activate it, e.g. by a swipe card, or maybe the first keypress. Up to this point
> the keypad has no legends for the keys. The operator initiation then causes the
> micro to display the key legends in random order, so anybody watching cannot
> determine what the number sequence is, because the next time it is activated the
> legends will be different. It would require a little extra code in the micro to
> match random legends to the key actually pressed to get the correct number
> entered, but it would stop "pattern matching" (top left, centre ,mid right,
> bottom left) by an observer, as the operator has to enter the code corresponding
> to the random legends.
Great idea, however in this case I'll need an additional display.
The cheapest solution would be probably the old LED based calculator
display located above the keypad, organized in a single raw of keys.
--
Wojciech M. Zabolotny http://www.ise.pw.edu.pl/~wzab <--> .....wzabKILLspam@spam@ise.pw.edu.pl
It was called "The Scrambler" and was a dismal failure because people
remember where the numbers are (from conventional keypads) and don't look
at the numbers on the keys, leading to lots of difficulty with it.
Mid-late 70's
Sorry.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
I saw it used on a building entry keypad system. it seemed to work well there
because the keypad used clear keycaps with a seven segment display digit under
each keycap. the display was normally unlit until the "operator initiation
point". I was not aware that it had been patented.
At 02:43 PM 3/13/00 +0000, Alan Pearce wrote:
>I saw it used on a building entry keypad system. it seemed to work well there
>because the keypad used clear keycaps with a seven segment display digit
under
>each keycap. the display was normally unlit until the "operator initiation
>point". I was not aware that it had been patented.
Oh yes.
Another neuron just kicked in, IIRC they had a fibre-optic faceplate over
the keys as well, making the view-angle for the keys very narrow. I know
the unit was expensive, I wonder what their cost per switch was? =:-0
Today, that would probably be a lot less expensive to do with an LCD and
touchscreen.
(Might also get around the patent, if it wasn't worded carefully)
I'm sure there are still some in use, and it made a big splash when
announced, but there was so much trouble with users, that it was largely
abandoned. Only places with really strong security departments could force
it on the users.
You have two keypad layouts burned into your brain. Telephone (probably
90%+) and calculator. If you watch someone who dosen't use a calculator a
lot, they have to stop and look for the numbers. It's a lot worse with the
scrambler, because there's deliberately no order to it.
It's a good idea as far as security, but it's not user-friendly, and it
makes the user take more time to enter the numbers, which partially negates
it's security advantage.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
> I saw it used on a building entry keypad system. it seemed to work well there
> because the keypad used clear keycaps with a seven segment display digit under
> each keycap. the display was normally unlit until the "operator initiation
> point". I was not aware that it had been patented.
>
I saw the coolest thing in one of the industry trade rags a couple of
years ago. Someone (don't remember who) makes square pushbutton switches
with addressable LED or LCD matrix keycaps. You can display whatever
short message or legend on the keycap you want, under program control.
They're probably obscenely expensive, but it would be perfect for this. I
think they were developed for aircraft & industrial control applications.
Dale
---
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov
>I saw the coolest thing in one of the industry trade rags a couple of
>years ago. Someone (don't remember who) makes square pushbutton switches
>with addressable LED or LCD matrix keycaps. You can display whatever
>short message or legend on the keycap you want, under program control.
>They're probably obscenely expensive, but it would be perfect for this. I
>think they were developed for aircraft & industrial control applications.
Omron IIRC. About $40 when I quoted them (years ago)
We thought about using them for transaction terminals.
At least until we saw the price. The terminals sold at that time for $90.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
It shouldn't be too hard to make your own display if all you want is digits.
Taken to the extreme make your own display using SMD LEDs. I have seen clear
keycaps available for switches. the display angle problem could be sorted with a
shroud around the keyboard.
On Mon, Mar 13, 2000 at 03:38:43PM -0000, Alan Pearce wrote:
> It shouldn't be too hard to make your own display if all you want is digits.
> Taken to the extreme make your own display using SMD LEDs. I have seen clear
> keycaps available for switches. the display angle problem could be sorted with a
> shroud around the keyboard.
Thanks for all the technical hints. However the main point is that the
key (let's give it a code name "PICKEY" - sounds good) should be as small
as possible (width and height of credit card, only a little thicker).
The main problem however is the choice of proper microcontroller.
The simplest RSA implementation requires holding of "challenge" and
result of it's exponentiantion in RAM. If "challenge" is L-bits long,
and the RSA's N coefficient is M-bits long, than I need L-bits for
"challenge" and L+M bits for temporary multiplication result.
For 512-bit key (it is a minimum for practical use) the M is 1024.
If L is 512 I need the 1536 bits = 192 bytes of RAM.
It can't be done with 16F84 :-(. For 1024-bit key results are even worse
and probably even the 16F87x is not sufficient.
However maybe there is a tricky RSA implementation better suited for
microcontroller implementation. Does anybody knows about it?
There is an additional problem: To defend the PICKEY against the timing attack
(a "feature" specific to RSA algorithm) the encrytpion time should be
probably hidden (eg. by outputing the results after the constant time
<longer than the longest possible calculation time>, independently on
the real calculation time).
> [Access-control keypads with dynamic reordering of the keys has]
> been done. Patented too.
>
> It was called "The Scrambler" and was a dismal failure because
> people remember where the numbers are (from conventional keypads)
> and don't look at the numbers on the keys, leading to lots of
> difficulty with it.
David;
I've used one; I didn't find it difficult at all. Hirsch
Electronics, who hold the patent, sell LOTS of them; where'd you hear
that they were "a dismal failure"?
For those of you who haven't seen the ScramblePad, info is at:
>I've used one; I didn't find it difficult at all. Hirsch
>Electronics, who hold the patent, sell LOTS of them; where'd you hear
>that they were "a dismal failure"?
It came out when I was in the alarm industry, got a lot of press, and some
of the local alarm companies tried them, but we all had to pull them out
and replace with conventional keypads because of user complaints.
I remember reading similar experiences in the trade mags, and then hearing
no more about them, nor seeing any in use. They may well have found a
market, likely in government or banking, where the security is dictated
from the top down, rather than in the home/business alarm market.
Techinically oriented people didn't have so many problems, but the average
users found them difficult.
I still think it's a good idea, it's just that the ergonomics (by
definition) dosen't work well.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
A suggestion is MD5 (one way hash) instead of RSA, better suited to
microcontrollers I believe. Means the server has to walk the passcode
table, or part of the passcode is actually an ID transmitted plaintext.
More important problem: a digit is only about 3.2 bits, no one can
remember an 18 digit passcode, maybe 10 digits = 32 bits (but realisticly
more like 4 digits!). Assuming I can eavesdrop the conversation then this
is very easy to crack.
Counter-top ATM readers must have the exact same problem, how do they deal
with it? I know they have an 'encryption chip' provided by the banks but
don't know how it fits into the protocol.
> The main problem however is the choice of proper microcontroller.
> The simplest RSA implementation requires holding of "challenge" and
> result of it's exponentiantion in RAM. If "challenge" is L-bits long,
> and the RSA's N coefficient is M-bits long, than I need L-bits for
> "challenge" and L+M bits for temporary multiplication result.
> For 512-bit key (it is a minimum for practical use) the M is 1024.
> If L is 512 I need the 1536 bits = 192 bytes of RAM.
> It can't be done with 16F84 :-(. For 1024-bit key results are even worse
> and probably even the 16F87x is not sufficient.
> However maybe there is a tricky RSA implementation better suited for
> microcontroller implementation. Does anybody knows about it?
>Counter-top ATM readers must have the exact same problem, how do they deal
>with it? I know they have an 'encryption chip' provided by the banks but
>don't know how it fits into the protocol.
It's complicated.
I don't know of any "encryption chip", ours were loaded by PC programs with
keys supplied by the banks, for DES. The idea is that you transmit the
encrypted PIN, and the recipient compares that with his copy of the
encrypted pin, so nobody has to keep the cleartext pin anywhere. I wasn't
that heavy into that side of it though, I just built the interface boxes
that they used to put the keys in, and tested the systems.
We had a potted module that contained processor, ram, and rom, with the
battery off-board, but we designed and built the modules.
Visa used a three man system for it's master keys. Three execs are required
to generate, each knows a third, and there are some alternates, in case
someone chokes on his caviar :)
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
>
> I'm sure there are still some in use, and it made a big splash when
> announced, but there was so much trouble with users, that it was largely
> abandoned. Only places with really strong security departments could force
> it on the users.
>
> It's a good idea as far as security, but it's not user-friendly, and it
> makes the user take more time to enter the numbers, which partially negates
> it's security advantage.
>
The Hirsch scrambling keypad was not a failure
technically, I was technical manager of a security
company that installed a number of them. I considered
them the best manufactured equipment I had ever seen.
The viewing angle was tight due to bonded perspex
slats... kind of like tiny venetian blinds so of course no
one could see what numbers you were entering.
The problem with them was price.. they were... bloody
expensive!
The other problem was the idiot factor and the public... "I
cant remember my number?".
I cant see how taking a bit longer to enter a code negates
security.. someone stealing your card and getting in with
it negates security!!!!!!!
I still think that conceptually this is one of the best
security access concepts around.
_____________________________
Lance Allen
Technical Officer
Uni of Auckland
Psych Dept
New Zealand
> Counter-top ATM readers must have the exact same problem, how do
> they deal with it? I know they have an 'encryption chip' provided
> by the banks but don't know how it fits into the protocol.
ATMs and point-of-sale credit-card readers use DES; the protocol
is available from VISA.
For lots of information on current work on encryption, see http://csrc.nist.gov/encryption/aes/
This page represents the US Govt's current effort to create an open-standard
replacement for the DES algorithm.
Of the candidates, I think Rijndael is the best suited for PIC
implementation.
>The Hirsch scrambling keypad was not a failure
>technically, I was technical manager of a security
>company that installed a number of them. I considered
>them the best manufactured equipment I had ever seen.
They were made well, we just had endless problems with people punching
their numbers without looking at the pads.
>The problem with them was price.. they were... bloody
>expensive!
That wasn't a huge factor with us, we got jobs when we were 3X over the
next lower bidder. :) We also had all but one gun shop in the state, and
NO succesful attempts.
>The other problem was the idiot factor and the public... "I
>cant remember my number?".
That's what killed them for us, they just seemed unable to remember to
"look before poking"
>I cant see how taking a bit longer to enter a code negates
>security.. someone stealing your card and getting in with
>it negates security!!!!!!!
It gives more opportunities for someone to observe the numbers you're
pushing.
The limited display angle helps a lot, but it's not perfect, especially at
night, once the keys get a little crud on them.
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
> > Counter-top ATM readers must have the exact same problem, how do
> > they deal with it? I know they have an 'encryption chip' provided
> > by the banks but don't know how it fits into the protocol.
>
> ATMs and point-of-sale credit-card readers use DES; the protocol
> is available from VISA.
>
> -Andy
>
Right, OK, so the answer must be: they deal with it by having pre-loaded
encryption keys, not challenge/response.
Are preloaded keys feasible from an end-user perspective for something
like a PICKEY? (Note my clever avoidance of the M-word... :)
Otherwise it'll need some kind of diffie-hellman thing, and I'd *love* to
see the source.
ise.pw.edu.pl
