What about if the first password protected a second password, that was randomly selected? (how do you do that in a PIC?) Or.... (back to my chunk of code on the iButton idea) the first read got you a chunk of code that could be used to give the location and value of the real password, which when read must read right. On Fri, 2004-08-13 at 12:36, Robert B. wrote: > The samples are of the DS1992 variety, so no password-only areas. > Unfortunately the door spewing out the password all the time would probably > make the password-ibutton system only marginally more secure than the > non-password type. With the 3-password scheme it would certainly be > improved, and much much harder for someone to guess (oops! not now that its > on the piclist!) But if the protocol was known it would just be a matter of > waiting for you to go in/out/in/out/ then try the door. > > I wonder if these problems are why ibuttons aren't as widespread as they > might be.. > > ----- Original Message ----- > From: "Howard Winter" > > > Robert, > > > > On Thu, 12 Aug 2004 21:13:42 -0400, Robert B. wrote: > > > > > The ibuttons aren't wireless (afaik) > > > > They aren't - then they'd be zero-wire instead of 1-wire :-) > > > > > and don't do any sort of computations > > > on their own. Really I think they're more like a 1-wire interface to a > > > cheap durable and portable kbit of nonvolatile ram. > > > > There are a number of versions... > > The simplest is the DS1990 which is just a serial number and nothing else. > > The DS1992 is the one with 1kb of NonVolatile RAM, so this may be what you > have. > > 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. > > > > > The challenge/response scheme you outlined is clever, and I'll certainly > > > remember it in the future. > > > > Well in this case the challenge from the door would be the password to > unlock an area of protected RAM, and > > the response would be the contents of the RAM, which the door would verify > and open if correct. There's no > > actual encryption involved, but it sounds pretty secure to me! Not only > would your would-be burglar have had > > to build the device, carry it around and wait for you to leave your keys > unattended, the device would then > > have to try to guess the 8-byte password, and would have no way of knowing > when it was correct. To be sure of > > getting a valid response it would have to try every possibility (2^64 of > them) and record all the results, to > > try them later. *How* long were you going to be away from your keys? :-) > > > > > The issues you brought up about out-of-sync keys are also very valid. > The > > > lock portion of the circuit would have to save the key in non-volatile > > > memory, and ensure that it is synced with the key after every > unlock-event. > > > In the event they do get out of sync, however, the lock would still open > but > > > give some indication of the out-of-sync status (most likely a flashing > LED). > > > Right now I'm leaning towards using the serial number as the unlock > code, > > > and the NVram number as an intrusion alert indicator which gives alert > if > > > the numbers are out of sync, then automatically resyncs. If the Ibutton > > > could do its own processing then your challenge/response method would > work > > > very well, but as it is merely a static storage device I can't come up > with > > > a way to make it work. > > > > Well if you have, or can get, the DS1991, which has 3 48-bit memory areas > with a password each, you could do > > it like this: > > Door detects the correct button-ID > > Door sends Password1 and reads a random part of the Memory1, compares it > with its known value > > If wrong, logs an intrusion attempt. > > If right, changes Password1 on the button and internally, and sets itself > to use Password2 next time. > > Unlocks the door. > > > > That way you have 3 passwords and memory areas used in rotation *when a > valid button is read* so continued > > attempts will always get the same password, but next time *you* use the > door that password is no longer valid. > > The only attack that would work would be to get the button and read the > ID, go to the door and spoof the ID > > and read the password that's given, return to the button and give it the > password and read all of the memory > > protected by it, then go back to the door and spoof the action of the > button. They would need two seperate > > accesses to the button, and two visits to the door, during which time you > haven't been home. And two > > device-functions, one to spoof the door, one to spoof the button. I think > this level of difficulty and the > > fact that they would have to know all this, guessing how you've done it > (or reading the PIClist :-) and having > > the motivation and the luck (you having left your keyring unattended on > two occasions without going home > > inbetween) means that just stealing the button or kicking the door down > would be easier! > > > > > Other issues I've been thinking about are what to do if the power goes > out? > > > Eeek I'd hate to be locked out of my house in event of a power outage! > I > > > figured maybe add external power-up posts so at the very least it could > be > > > powered from outside by a battery to unlock the doors. > > > > Not just "applying voltage unlocks the door" I hope, or all the > electronics is wasted! :-) > > > > The usual way it works is that you have an "electric strike" - this > replaces the fixed part of the lock, > > mounted on the doorframe, so the door's latch will operate as usual. When > the strike releases, it allows the > > latch to pass without it being withdrawn, and also allows it to slam shut > again. This means that the key can > > be retained as an emergency access method if you want. The strike can be > set to "fail secure" - it's normal > > position is locked, applying power releases it, or "fail safe" which is > the reverse and is used for things > > like emergency exits. You want "fail secure". > > > > The lock electronics and the supply to operate the release would usually > have a small 12V Sealed Lead Acid > > battery as a backup (say a couple of AmpHours), which is float-charged all > the time the mains is available > > (burglar alarms do the same). This would cover all reasonable power > failures, say up to a few days assuming > > your electronics isn't a real power-hog. Remember, though, that having > power doesn't mean that your > > electronics will be 100% reliable - you need to allow for the fact that > you may need to get in with no > > electronics working. > > > > > There's always *two* big dogs... > > > > So why do you bother to lock the door at all? :-) > > > > Cheers, > > > > > > Howard Winter > > St.Albans, England > > > > -- > > 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 -- Anthony Toft -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu