The ibuttons aren't wireless (afaik), 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. The challenge/response scheme you outlined is clever, and I'll certainly remember it in the future. 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. 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. There's always *two* big dogs... ----- Original Message ----- From: "Olin Lathrop" To: Sent: Thursday, August 12, 2004 8:54 PM Subject: Re: [EE:] Ibutton Samples > Robert B. wrote: > > I'm planning on developing a > > modifiable key that is synced between the uP and the ibutton. > > What happens when the remote device and the ibutton get out of sync? What > if a communications error occurred so that a message got thru but one side > didn't think so, or the reverse where one side thought a message got thru > but it didn't? What if the remote device or the ibutton device lose power > and forget the current key sequence? > > At the very least it seems you need a sync mode where the two devices can be > re-synced, maybe with special physical access required to the ibutton > device. > > > The idea is that this way if someone were to steal the current ibutton > > access code, they would have to use it before the owner did as the > > key would be modified to a new key each time the owner uses it. > > There is no need to ever send the secret code over the airwaves as clear > text. There are many schemes around this. For example, the button device > makes up a random string and sends it to the remote device as a challenge. > The remote device performs a one-way permutation of this challenge string > using the secret and sends it back. If authentication is valid, then both > communicate securely using a key based on the secret and the challenge code. > > An eavesdropper would only learn the correct response to that particular > challenge, which is useless since challenge codes are many bits long and > randomly selected, thereby making it extremely unlikely that the same code > will ever be used twice. Even knowing the challenge and the valid response > still won't allow someone else to communicate because they don't know the > full encryption key which depends on the secret. > > This may sound complicated, but it's actually rather easy to implement on a > PIC. > > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body