Post by thread:PIC based "Electronic key"

Hi All, 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 http://www.pepix.net/proyectos/glazz/mary The FREE optimizing Forth compiler for PIC microcontrollers

>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 http://www.debian.org Linux - free OS for free people!

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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> iQA/AwUBOM0rPYFlGDz1l6VWEQLRzwCgghAxY+eoX3/DE6N7SK0/2WzbYi8AoMec BIM9vuZKPDsGdIQF6xZB7GSs =hte2 -----END PGP SIGNATURE-----

On Mon, 13 Mar 2000, 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. > 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >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> iQA/AwUBOM0u+oFlGDz1l6VWEQJcQQCdEIpM57DxAhi4Mp+2VZUvfKMXNuEAoIoX E2PczKN5sjQIbWoZnabaAgS0 =IfrC -----END PGP SIGNATURE-----

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). -- Thanks for all asnwers (both to the list and to my e-mail) Wojciech M. Zabolotny http://www.ise.pw.edu.pl/~wzab <--> wzabKILLspamise.pw.edu.pl http://www.debian.org Use Linux - save your data and time

David VanHorn <.....PICLISTKILLspam.....MITVMA.MIT.EDU> wrote: > [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: http://www.hirschelectronics.com/hardware.htm -Andy === Andrew Warren - EraseMEfastfwdspam_OUTTakeThisOuTix.netcom.com === Fast Forward Engineering - San Diego, California === http://www.geocities.com/SiliconValley/2499

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >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> iQA/AwUBOM1DGYFlGDz1l6VWEQLXXgCfbSv6Gdda+uV7KavhgSgE8Gfh2ocAoPQt l2KJH3T3SFTewxBPsVpSSUj+ =QzSo -----END PGP SIGNATURE-----

Interesting concept... 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. {Quote hidden}> 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?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >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> iQA/AwUBOM1mpoFlGDz1l6VWEQJZVACgp/zk9a8QGKgZWKQjyhflhgJpHJsAn1pP hXqmsBrs0jLGxdMUXWntl+Fg =NiUM -----END PGP SIGNATURE-----

> > 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 http://www.psych.auckland.ac.nz _____________________________

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >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> iQA/AwUBOM1uGoFlGDz1l6VWEQL6/QCgg8jtoc/+qn6AA7+2CpdP4+EN50UAn1E3 cE6n5UBbZ/z2rqnxnd0Hb4cE =vmAS -----END PGP SIGNATURE-----

> > 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. -- Rich

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >Right, OK, so the answer must be: they deal with it by having pre-loaded >encryption keys, not challenge/response. Correct >Are preloaded keys feasible from an end-user perspective for something >like a PICKEY? (Note my clever avoidance of the M-word... :) Do you need to really conform to the whole DES standard? If so, they have a lot to say about the hardware design and packaging. Do you need a lot of keys? You need to be able to store the keys in volatile memory, in addition to whatever else you need in ram. I remember we had to go through a lot of gyrations with various levels of keys. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com> iQA/AwUBOM13doFlGDz1l6VWEQLvHACfZjeDx2nQIRViI2C/ILOlL3fsxHgAn06T A7/TChqAGuoPHqIBy/GUh8Dr =gX52 -----END PGP SIGNATURE-----