You're sort of missing the point here.. The point is that it can be done, and that its not terribly difficult to do. Perhaps none of my coworkers *at this moment* have the knowledge or equipment to read or program an ibutton, but in the 2 weeks since you informed me they exist I've had no problems figuring it out. In the 12 hours since the samples arrived I managed to hack together some code to read and write an ibutton, and as these things go I'm definitely on the uninformed and inexperienced end of the spectrum. SO please tell me again why an obvious, easily implemented, no-extra cost security feature should not be added? For a one-off door lock system that I build myself and don't tell many people about, it would probably be very secure to just read the serial and allow/deny access based on that. But the security wouldn't be inherent to the system, it would come from the lack of knowledge about how the system was constructed. On a side note, I actually did know they existed, I just didn't know I knew they existed yet! :) The keys on segway HT's are some variant on an Ibutton, and I'd used those before, just assuming they were proprietary segway strangeness. Thanks for enlightening me! ----- Original Message ----- From: "Engineering Info" To: Sent: Friday, August 13, 2004 12:14 AM Subject: Re: [EE:] Ibutton Samples > 1) And just how many of your co-workers have the equipment sitting at > their desk at work to read an I-Button let alone the knowledge to > simulate one? Remember, you didn't even know they existed until I told > you about them. > > 2) Add a keypad in parallel with the I-Button. You would need to know > BOTH to get in the house. Even if they did steal and/or copy your > I-button, it wouldn't work without the keypad code. > > 3) Use a Microchip KEELOQ system instead > (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=77) > > Robert B. wrote: > > > > > > > > > > >>But if they have physical access to the iButton, what is stopping them > >>from just using it instead trying to make a copy? > >> > >>If you lose a set of keys in real life, you change your locks. You > >>could do the same thing with the iButton system, make it easy for you > >>to grant/revoke access based on serial numbers. Much quicker than > >>getting a locksmitch to install a new front door lock. :) > >> > >>Alex > >> > >> > > > >As an example, lets say you are at work and go to the restroom, leaving your > >keys on your desk. While you're gone for 5 minutes no coworker could get > >your ibutton, drive to your residence, gain access, and return the keys such > >that you would not notice. But 5 minutes is more than enough to copy the > >serial number for use at a later time. Other examples would be in the > >airport, at the gym, leaving your keys in an unlocked car, or at the pool. > >Perhaps I'm more careless with my keys than most people, but just today > >alone I can think of twice that an unsavory individual might have been able > >to copy an ibutton's serial without my knowledge. > > > >If the entire ibutton is missing obviously it would need to lose its access > >privileges. But if a copy is made there would be no way of knowing, and > >therefore the lock wouldn't be changed, even after multiple break-ins. In > >theory, some sort of rolling code would sound the alarm that someone has > >gained unauthorized access, even if it wouldn't stop the initial access from > >occuring. It would act as a broken window or crowbarred door, and prevent > >multiple entries. Standard warning signs would be conspicuously absent from > >an ibutton authorized system, since no physical damage would be done. Access > >logs (if kept) could offer an after-the-fact explanation if you remember to > >review them, and remember what you were doing all day. > > > >I still think it's a good idea to have a double-check system like the one > >I've described. A simple increment-on-use syncronized counter would be > >acceptable, but far easier to bypass or work around than a more complicated > >unpublished algorithm. In the end it might not make the system any more > >secure against an initial attack, but it would at least alert you if someone > >else had been / is currently there, and that its time to change the lock to > >resecure the system. > > > >-- > >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 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