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:

><snip>
>
>
>
>>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