Slightly better approach is to combine the simple rolling code and the password protected area. When a successful access occurs, change both the password and the code. The attacker then has to get the password, and get your key inbetween times you use the door. Make it a little harder - if the password is taken, but an invalid (or no key) given back then on the next attempt to get the door two passwords are needed, unsuccessful third attempt three passwords are needed. When two passwords are needed, never query for the second password until the first code is accepted. Then query the second password, and if needed the third password if the second is correct. The attacker has to get all three passwords, but can't get them until he knows the first and second passwords. Thus one has to have access to both the lock and the key at the same time, which invalidates the whole key system anyway. If they can go between the lock and the key 3 times, then it's probably just as easy to use the key itself. But it's still insecure. Just less obvious for even a sophisticated attacker, and give as much as more or security than a regular key. -Adam Alex Harford wrote: >On Fri, 13 Aug 2004 12:56:45 +0100, Howard Winter > wrote: > > >>Robert, >> >>The DS1991 may be the most interesting to you: it has some of its RAM area password protected - if you don't >>give it the right password it doesn't object, it just returns random data (I rather like that idea! :-) so a >>brute-force attack would not work, even if it was feasible. >>There are others but I think the ones above cover the ground pretty well. >> >> > >But what would stop the attacker from using a fake iButton that's >really a PIC that talks in the iButton protocol and steals the >password? I've never seen an iButton so I don't know if it's actually >possible to get some alligator clips or probes in there. > >I agree with Robert, some sort of rolling code would be useful. There >would have to be out of sync detection with a manual override. > >It wouldn't stop the evil-doer the first time, but at least you'd be >able to detect if someone had stolen the key and accessed the door >without your knowledge. In that way you'd be one better than the >standard key. > >You'd have to also make sure that the evil-doer can't crack your >encryption scheme when the controller writes the new data back to the >copied iButton. Ie make it very hard to calculate the next code when >you already know two sequential ones. > >Alex > >-- >http://www.piclist.com hint: To leave the PICList >mailto:piclist-unsubscribe-request@mitvma.mit.edu > > > > > -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu