Searching \ for '[EE:] Ibutton Samples' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=ibutton+samples
Search entire site for: 'Ibutton Samples'.

Exact match. Not showing close matches.
PICList Thread
'[EE:] Ibutton Samples'
2004\08\12@161445 by Robert B.

flavicon
face
The I-button samples arrived today from Maxim/Dallas, order placed on 8/04.
Not bad for non-microchip samples!  Now if I can just figure out how to
program them...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@162104 by Marc Nicholas

flavicon
face
iButtons are just 1-wire devices in a can, so-to-speak. You don't
mention how you want to access them...from a PIC (or similar), or from a
PC?

-marc

{Original Message removed}

2004\08\12@164425 by Robert B.

flavicon
face
The plan is to get a PIC routine up and running for reading the ibutton key,
modifying it according to some algorithm, then writing the modified key back
to the ibutton.  The samples I received are 1-k-bit NVram, and at first I'm
planning on assembling a basic ibutton locking mechanism (with a PIC at the
heart) using all 1kb of the memory for the access key.  Pretty basic I know,
but it should be fun to put together.



----- Original Message -----
From: "Marc Nicholas" <.....marcKILLspamspam@spam@GEEKYTHINGS.COM>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Thursday, August 12, 2004 4:22 PM
Subject: Re: [EE:] Ibutton Samples


> iButtons are just 1-wire devices in a can, so-to-speak. You don't
> mention how you want to access them...from a PIC (or similar), or from a
> PC?
>
> -marc
>
> {Original Message removed}

2004\08\12@164846 by Shawn Wilton

flavicon
face
Key, as in the data you are going to store?  I take it you're *not*
trying to modify the built in serial number of the iButton.


Shawn Wilton
Junior in CpE
MicroBiologist

Phone: (503) 881-2707
Email: .....shawnKILLspamspam.....black9.net

http://black9.net


Robert B. wrote:
{Quote hidden}

>>{Original Message removed}

2004\08\12@165914 by Marc Nicholas

flavicon
face
There's definitely PIC 1-wire code floating around in the ether
somewhere, so that should help.

Remember ESD protection!


-marc

{Original Message removed}

2004\08\12@172648 by Robert B.

flavicon
face
I'm not planning on using the built-in serial number for this application.
It seems too easy to fake to be a reliable access-control mechanism, so
instead I'm planning on developing a modifiable key that is synced between
the uP and the ibutton.

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.  I suppose if someone
*did* steal the code and make it work successfully, the owner would be
locked out of his own system since the PIC would update its internal key but
the owner's ibutton wouldn't receive the new key.

Maybe it would be better to store a timestamp of the last valid use in the
ibutton's writable area, and authenticate credentials based on the built-in
serial number.  Then if the timestamps don't match alert the owner that
someone else has been there, but still allow access.

Any thoughts?  or better ways to do it?


----- Original Message -----
From: "Shawn Wilton" <@spam@shawnKILLspamspamBLACK9.NET>
To: <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Thursday, August 12, 2004 4:47 PM
Subject: Re: [EE:] Ibutton Samples


{Quote hidden}

key,
> > modifying it according to some algorithm, then writing the modified key
back
> > to the ibutton.  The samples I received are 1-k-bit NVram, and at first
I'm
> > planning on assembling a basic ibutton locking mechanism (with a PIC at
the
> > heart) using all 1kb of the memory for the access key.  Pretty basic I
know,
{Quote hidden}

> >>{Original Message removed}

2004\08\12@172908 by Shawn Yates

flavicon
face
I have made a PIC talk to the iButton.  From what I remember it was
pretty straight forward after reading the specs.  I may be able to find
some code if you need a starting point.

Shawn

{Original Message removed}

2004\08\12@174151 by Robert B.

flavicon
face
Sample code is very welcome!  Especially if it's in assembly or C.  I've
been rummaging in the samples package and it seems they opted not to include
the ibutton holders I requested, so I guess its a homebrew clip until I find
a place to order a few from.  Maxim's online ordering has a 13-week lead
time and doesn't seem to be working anyway.  Any ideas for alternate
suppliers?



----- Original Message -----
From: "Shawn Yates" <RemoveMEsyatesspamTakeThisOuTCARETECH.NET>
To: <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Sent: Thursday, August 12, 2004 5:26 PM
Subject: Re: [EE:] Ibutton Samples


> I have made a PIC talk to the iButton.  From what I remember it was
> pretty straight forward after reading the specs.  I may be able to find
> some code if you need a starting point.
>
> Shawn
>
> {Original Message removed}

2004\08\12@174812 by Shawn Wilton

flavicon
face
Actually, samples usually come in chunks from them.  Their system leaves
a lot to be desired.  Took me many months to get my samples, and some
still haven't arrived...(some 9 months later).


Shawn Wilton
Junior in CpE
MicroBiologist

Phone: (503) 881-2707
Email: EraseMEshawnspamblack9.net

http://black9.net


Robert B. wrote:
{Quote hidden}

>>{Original Message removed}

2004\08\12@175228 by Shawn Yates

flavicon
face
None.  I have just learned to order more than I need and order them far
in advance.

I don't know if the list supports attachments, so I just pasted in the
code.
This runs on a 16C54 @ 4Mhz, but can be adapted to anything.

; Dallas Semi iButton information
;***********************************************************************
*******************
;The I-Button uses a 1 wire interface.  The wire is
*
;connected to  an open drain type ouput and has a pull-up resistor.
Either the PIC or         *      ; the external components can pull the line low and that is how they
communicate.      *
;
*
;The I-Button pin must sit normaly as in input, leaving the line high.
When a iButton    *
;is connected to this line it will generate a presence pulse (low) and
that is what will  *
;allow the main routine to call the iButton reading routine.  This
presence pulse will be *
;from 60 to 240 uS long, with 120 being nominal.
*
;
*
;After the presence pulse, a read command can be send, which is 33h (lsb
first).          *
; to write a bit,
*
;       10uS low
*
;       50uS data value (Low or High)
*
;        2uS high recovery time
*
;
*
;The iButton will respond with 64 bits of data to be read.
*
;       8 bits of family code (probably the same for everything we will
use)              *
;      48 bits of unique serial number
*
;       8 bits of CRC
*
;
*
;  To read data:
*
; send a low for 2uS followed by high (delay) for 10uS, then sample the
line for a        *
; data bit then wait at least 35uS before reading or writing the next
bit.              *
;***********************************************************************
*******************

;** Macros used to toggle IButton from input to output.
DSIN        
               bsf     PAGE1          
               bsf     DSTRIS
               bcf     PAGE1
               retlw   0

DSOUT        
               bsf     PAGE1           ;change to TRIS page
               bcf     DSTRIS          ;clear TRIS bit to make output
               bcf     PAGE1           ;back to regular page
               bcf     DSBit                  retlw   0
               

D3xuS        
               movwf   JUNK1           ; Store the value                 clrwdt

Dx1             decfsz JUNK1,f          ; 1 cycles
               goto    Dx1                     ; 2,3 cycles

               retlw   0

;***** I - Button Routines *********************************************

RXIBUTT
       ;Get information from the Dallas iButton

       ;incase the button is held on the reader, generate
       ;a reset pulse first (at least 480uS low, then sample at 85uS)

       call    DSOUT

       movlw   .200
       call    D3xuS

       call    DSIN

       movlw   .28
       call    D3xuS

       btfsc   DSBit           ;make sure there is a presence pulse
       retlw   0

       movlw   .40
       call    D3xuS

       btfss   DSBit           ;if there is still a 0, its a short dont
read it
       retlw   0

       
       
       ;Write the Byte stored in W to the iButton
       ; to write a bit,

       ;       10uS low

       ;       50uS data value (Low or High)

       ;        2uS high recovery time


       movlw   33h
       movwf   JUNK2

       movlw   .8
       movwf   BitCount        ;setup to send 8 bits
       call    DSOUT

TXDSBit        

       ;once the line goes low (T), it must stay low for 1 to 15uS.
       ; Data must be present from T+15 to T+60
       ; There must be a high for at least 1uS after T+60

       bcf             DSBit           ;send low       (T)

       goto    $ + 1
       clrwdt

       rrf             JUNK2,f         ;T + 4, data is about to be
asserted

       btfsc   C                       ;if the data bit is low, leave
the bit as is
       bsf             DSBit           ;if the data is high, set the
bit

       movlw   .18                     ;T + 7
       call    D3xuS           ;Delay makes it T + 61

       bsf             DSBit           ;back to high for recovery time
       goto    $ + 1           ;give 2uS recovery

       decfsz  BitCount,f
       goto    TXDSBit

       call    DSIN

       movlw   .10                     ;delay between write and read
       call    D3xuS

       
       ;** Read 64 bits from the iButton
       ;  To read data:

       ; send a low for 2uS followed by high (delay) for 10uS, then
sample the line for a             ; data bit then wait at least 35uS before reading or writing the
next bit.                        

       movlw   .64             ;receive 64 bits of data
       movwf   BitCount        

       
RXDSBit clrwdt

       ; The master pulls the line low at T
       ; master keeps line low for 1uS
       ; Master should sample the line after T+3 and before T + 15
       ; After T + 120, leave the line high for at least 1uS, then
start again
       

       bcf             DSBit        
       bsf             PAGE1
       bcf             DSTRIS  ;set the bit low        (T)
       goto    $ + 1   ;delay 2uS
       bsf             DSTRIS  ;back to input
       bcf             PAGE1
;(T + 4)

       goto    $ + 1
       clrwdt
;(T + 7)

       bsf             C                       ;clear the carry bit
assuming there is a 0
       btfss   DSBit           ;if the pin is high
       bcf             C                       ;set the carry bit

       nop

       rrf             DsByteIn8,f     ;        
       rrf             DsByteIn7,f     ;        
       rrf             DsByteIn6,f     ;        
       rrf             DsByteIn5,f     ;        
       rrf             DsByteIn4,f     ;        
       rrf             DsByteIn3,f     ;        
       rrf             DsByteIn2,f     ;        
       rrf             DsByteIn1,f     ;               (T + 18)

       movlw   .35                     ;                      
       call    D3xuS           ;              

       decfsz  BitCount,f      ;if there are more bits to get
       goto    RXDSBit         ;keep looping

; The crc is calculated below.
;
       movlw   .7        
       movwf   ByteCount       ;CRC 7 Bytes of Data


       clrf    CRC8            ;clear the CRC result

       movlw   DsByteIn1
       movwf   04h             ;point the FSR to the first register        



IbutCRC
;--
       
       movlw   .8
       movwf   BitCount

       movf    00h,w           ;get the byte to be processed
       movwf   JUNK1           ;and store it

CRC1
               clrwdt
               xorwf   CRC8,w          ;xor the working byte with the
CRC result
       
               movwf   JUNK2           ;Store the result
               rrf             JUNK2,w         ;Rotate the bit out to
see what it is

               movf    CRC8,w          ;get the CRC incase we need to
XOR it

               skpnc                   ;if no carry, do not do the xor
               xorlw   18h
       
               movwf   CRC8            ;store whats in W (will be CRC
or CRC with new XOR)

               rrf             CRC8,f          ;rotate the resultant
CRC                 bcf             C
       
               rrf             JUNK1,f         ;rotate the data byte
and store in W and
               movf    JUNK1,w         ;in the work register (junk1)

               decfsz  BitCount,f      ;
               goto    CRC1

       incf    04h,f           ;move to the next byte
       
       decfsz  ByteCount,f     ;if all 8 not done
       goto    IbutCRC         ;then loop

       movf    DsByteIn8,w
       xorwf   CRC8,w

       IF_NOT_ZERO
       retlw   0

       ;The ibutton was read successfully, pause and reset any open
alerts

       DO_PAUSE
       clrf    Pause_Timer
       bsf             PAUSED
       bsf             GREEN
       
       goto    RESET_ALERT
{Original Message removed}

2004\08\12@180302 by Howard Winter

face
flavicon
picon face
Robert,

On Thu, 12 Aug 2004 17:27:21 -0400, Robert B. wrote:

> I'm not planning on using the built-in serial number for this application.
> It seems too easy to fake to be a reliable access-control mechanism

Are you sure about this?  If you use the read-only ID button, it's a factory-made, 6-byte, guaranteed unique
number (thus 2^48 possibilities, so a brute force attack is unlikely to be feasible, with over 280 million
million to try, or 20 million times the number of combinations of the UK national lottery! :-)

What level of security are you looking for?  Is it likely to be subject to a "hard" attack?  Is physical
posession of the i-button not sufficient, and you want to make sure the right person is holding it as well?

> so instead I'm planning on developing a modifiable key that is synced between the uP and the ibutton.
>
> 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.  I suppose if someone
> *did* steal the code and make it work successfully, the owner would be
> locked out of his own system since the PIC would update its internal key but
> the owner's ibutton wouldn't receive the new key.

You seem to be emphasising stealing the code without stealing the device itself - is this a possibility in the
situation you're looking at?

Cheers,


Howard Winter
St.Albans, England

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@180717 by Shawn Wilton

flavicon
face
Furthermore, you could enhane that by allowing one number combination
per second, or so.  Then it would be *quite* difficult to brute force.


Shawn Wilton
Junior in CpE
MicroBiologist

Phone: (503) 881-2707
Email: EraseMEshawnspamspamspamBeGoneblack9.net

http://black9.net


Howard Winter wrote:
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspamspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@182831 by Robert B.

flavicon
face
----- Original Message -----
From: "Howard Winter" <spamBeGoneHDRWSTOPspamspamEraseMEH2ORG.DEMON.CO.UK>
To: <KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Thursday, August 12, 2004 6:03 PM
Subject: Re: [EE:] Ibutton Samples


> Robert,
>
> On Thu, 12 Aug 2004 17:27:21 -0400, Robert B. wrote:
>
> > I'm not planning on using the built-in serial number for this
application.
> > It seems too easy to fake to be a reliable access-control mechanism
>
> Are you sure about this?  If you use the read-only ID button, it's a
factory-made, 6-byte, guaranteed unique
> number (thus 2^48 possibilities, so a brute force attack is unlikely to be
feasible, with over 280 million
> million to try, or 20 million times the number of combinations of the UK
national lottery!

The only problem I'd have with that setup is that although no duplicate
ibutton may exist, how hard would it be to read out the serial# then emulate
an ibutton with that serial number using a microprocessor.  FEX read the
ibutton # into a pic, then hold the pic to the lock contacts and let it spew
the same serial at some later date.  Granted a brute force attack would be
near impossible, but with the ease of reading these things into a PC it
seems prudent to avoid a static key such as the built-in serial number.

> What level of security are you looking for?  Is it likely to be subject to
a "hard" attack?  Is physical
> posession of the i-button not sufficient, and you want to make sure the
right person is holding it as well?

The ultimate level of security is probably not all that secure.  Perhaps
similar to that of a typical house or safe key.  The difference is that
physical keys are fairly difficult to duplicate even if possession is
acquired for some length of time (just ask the guys at your local hardware
store to make you a copy ;)  ) whereas digital keys are easily duplicated
once obtained.

I don't particularly care who has the valid key, only that it is the valid
key, so physical security is in all probability the limiting factor of the
system's ultimate security.

<snip>

>
> You seem to be emphasising stealing the code without stealing the device
itself - is this a possibility in the
> situation you're looking at?

Yes I think its a very real possibility in any access-control situation.
For example, if my college campus had used ibuttons instead of normal keyed
locks, it would have taken about 20 minutes before someone realized that its
possible to read out the serial #s to a laptop.  Then all you need is a
minute or two alone with someones ibutton and a laptop and you have the
serial #.  I can't imagine that emulating the ibutton protocol with a
microchip would be all that hard either.  So once you have the serial its a
(fairly) simple matter of programming it into a uP and making the
appropriate contacts with the door lock.  As far as the access control
system is concerned, its received a valid serial number, and has no way to
differentiate which serial is from the ibutton and which serial is from the
ibutton emulator.

In the case of an old-fashioned brass key, if you leave your keys somewhere
for a few minutes it might be possible for someone to make a wax impression
of it then carry that home and file a key out of it, but this is a very
difficult process and is prone to failure, even for professional locksmiths.
I'd venture to guess that the number of people capable of copying a brass
key in this manner is far exceeded by those with the expertise needed to
duplicate an ibutton serial number.  Furthermore, no craftmanship is needed
to duplicate the ibutton's serial, and once a system is initailly set up any
Joe off the street could use it.

I'd bet that most people on this list could make such a workaround with a
little bit of effort.

So in the end it boils down to never leaving your ibutton alone for more
than a few minutes, or implementing some sort of modifiable key to prevent
such easy copying.


> Cheers,
>
>
> Howard Winter
> St.Albans, England
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email EraseMElistservspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@183450 by Robert B.

flavicon
face
Or simply run the ibutton link at 9600 baud, which would effectively do the
same thing by limiting the read/write cycle for a 1-kbit "key"  to a few
tenths of a second.

{Original Message removed}

2004\08\12@184113 by Shawn Wilton

flavicon
face
My point was to limit the speed of your reading system so they could try
at most 84000 keys per day.


Shawn Wilton
Junior in CpE
MicroBiologist

Phone: (503) 881-2707
Email: spamBeGoneshawnspamKILLspamblack9.net

http://black9.net


Robert B. wrote:
> Or simply run the ibutton link at 9600 baud, which would effectively do the
> same thing by limiting the read/write cycle for a 1-kbit "key"  to a few
> tenths of a second.
>
> {Original Message removed}

2004\08\12@190603 by Robert B.

flavicon
face
Yeah hopefully someone would notice by the time they got around to a
significant fraction of possible keys! lol  At 84000 keys per day and a
100-bit key, it would take only... oh... a trillion trillion years to get
through them all.  By that time I think the intruder might just break the
window / drill the lock / resort to a real-man's lockpick (dynamite followed
by a sledgehammer) and go in the old fashioned way.


{Original Message removed}

2004\08\12@191640 by Shawn Wilton

flavicon
face
Exactly.  And that's what you want.  I think you should stick with the
internal serial number and base your system on that rather than trying
to create a rolling code system.


Shawn Wilton
Junior in CpE
MicroBiologist

Phone: (503) 881-2707
Email: .....shawnspam_OUTspamblack9.net

http://black9.net


Robert B. wrote:
> Yeah hopefully someone would notice by the time they got around to a
> significant fraction of possible keys! lol  At 84000 keys per day and a
> 100-bit key, it would take only... oh... a trillion trillion years to get
> through them all.  By that time I think the intruder might just break the
> window / drill the lock / resort to a real-man's lockpick (dynamite followed
> by a sledgehammer) and go in the old fashioned way.
>
>
> {Original Message removed}

2004\08\12@192925 by Alex Harford

face picon face
On Thu, 12 Aug 2004 18:29:11 -0400, Robert B. <TakeThisOuTpiclist.....spamTakeThisOuTnerdulator.net> wrote:
>
> The only problem I'd have with that setup is that although no duplicate
> ibutton may exist, how hard would it be to read out the serial# then emulate
> an ibutton with that serial number using a microprocessor.  FEX read the
> ibutton # into a pic, then hold the pic to the lock contacts and let it spew
> the same serial at some later date.  Granted a brute force attack would be
> near impossible, but with the ease of reading these things into a PC it
> seems prudent to avoid a static key such as the built-in serial number.

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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservKILLspamspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@195659 by Robert B.

flavicon
face
<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 .....listservspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@200906 by Andrew Warren

flavicon
face
Robert B. <RemoveMEPICLISTspamspamBeGonemitvma.mit.edu> wrote:

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

   Wouldn't it be easier to just buy a big dog, Robert?

   -Andrew

=== Andrew Warren -- spamBeGoneaiw@spam@spamspam_OUTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@201736 by Robert B.

flavicon
face
Are you all just being argumentative?  Or are you serious.  It wouldn't be
hard to implement at all, so why not add the extra little bit of code.  I
certainly don't see how it could hurt anything, and it would make the system
better.

A Big Dog is in the plan as well, but sometimes I'll have to take him out
for a walk, or to guard the truck or something. ;)


{Original Message removed}

2004\08\12@205548 by Olin Lathrop

face picon face
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 listservEraseMEspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@205754 by Olin Lathrop

face picon face
Robert B. wrote:
> Sample code is very welcome!  Especially if it's in assembly or C.
> I've been rummaging in the samples package and it seems they opted
> not to include the ibutton holders I requested, so I guess its a
> homebrew clip until I find a place to order a few from.  Maxim's
> online ordering has a 13-week lead time and doesn't seem to be
> working anyway.  Any ideas for alternate suppliers?

I don't know specifically what the dimensions of an ibutton are, but
Keystone (http://www.keyelco.com) make a variety for coin cell holders.


*****************************************************************
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 RemoveMElistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@211002 by Olin Lathrop

face picon face
Robert B. wrote:
> 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.

There is no need for this to be true.  Presumably the key would be trained
with the secret while the user had physical access to the lock.  The code
would then live in the key in the PIC RAM or read-protected EEPROM or the
like.  This can be cracked with enough effort, but not casually in 5 minutes
and keeping the device physically unharmed so that you're not alerted.

It seems you are worrying about the .1% security hole and ignoring the 50%
security hole that is the glass window next to the door.  That only takes 5
seconds and a low tech brick to get around.


*****************************************************************
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 @spam@listservRemoveMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@211342 by Robert B.

flavicon
face
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 removed}

2004\08\12@211757 by Robert B.

flavicon
face
Again very valid criticisms.  But I think you're confusing the ibuttons with
something else.  The ibuttons don't have any read-protected eeprom, and
can't do any computations on their own (afaict).  So copying all the data in
the ibutton is easy to do and in my mind represents a security hole larger
than 0.1%.  A determined thief will no doubt break in regardless of the door
locks installed, but at least if they break the window then its fairly
obvious the intrusion occurred.  With a copied ibutton they could break in
repeatedly with no physical indications, which was my primary concern when I
came up with the idea of a synced key -- to let you know if someone else has
been there.


{Original Message removed}

2004\08\12@215327 by Chetan Bhargava

picon face
> iButtons are just 1-wire devices in a can, so-to-speak. You don't
> mention how you want to access them...from a PIC (or similar), or from a
> PC?

Or maybe a Tiny11 :-)

Does anybody know of any AVR 1-wire driver?

Regards,

Chetan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@222707 by Anthony Toft

flavicon
face
Here you go, a "stellar" idea...

Use a pic with bootloader capability, when you notice the iButton in the
holder, download the chunk of program that is stored in the iButton and
run it, the chunk of program could be something that does anything (I
quite like the thought of the code chunk unlocking the door).

Using an encrypted iButton (DS1991 I think they are) you can't get the
data off without the proper password...

Just an idea

On Thu, 2004-08-12 at 20:17, Robert B. wrote:
> Are you all just being argumentative?  Or are you serious.  It wouldn't be
> hard to implement at all, so why not add the extra little bit of code.  I
> certainly don't see how it could hurt anything, and it would make the system
> better.
>
> A Big Dog is in the plan as well, but sometimes I'll have to take him out
> for a walk, or to guard the truck or something. ;)
>
>
> {Original Message removed}

2004\08\12@223534 by William Chops Westfield

face picon face
On Aug 12, 2004, at 3:03 PM, Howard Winter wrote:

>
>> I'm not planning on using the built-in serial number for this
>> application.
>> It seems too easy to fake to be a reliable access-control mechanism
>
> Are you sure about this?  If you use the read-only ID button, it's a
> factory-made, 6-byte, guaranteed unique
> number (thus 2^48 possibilities, so a brute force attack is unlikely
> to be feasible, with over 280 million
> million to try, or 20 million times the number of combinations of the
> UK national lottery! :-)
>
But isn't it trivial for the bad guy to read the iButton, and create a
device that LOOKS (to the one-wire protocol) like an iButton with the
same code?  Just like the rfid hacks we were talking about a few days
ago...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservspam_OUTspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\12@225653 by M. Adam Davis

flavicon
face
If you're serious about rolling code or an uncopiable key, you should
consider buying an empty iButton can, and dropping a PIC10F and a keyloq
rolling code generator in there.  Emulate the iButton protocol, or do
something different to confuse people - or pass out regular iButtons to
guests or neighbors that need access to your house for short durations
and disable them later.

Last time I ordered iButton samples I got empty cans instead of the
parts I ordered. Still have the two of them somewhere around here.  The
back is open, it has two solderable tabs on the inside, and it looks
like the back could be soldered closed for a tight seal if you had the
right size metal blank.

-Adam

Robert B. wrote:

{Quote hidden}

>>{Original Message removed}

2004\08\13@001639 by Engineering Info

picon face
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:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-request@spam@spamEraseMEmitvma.mit.edu

2004\08\13@004215 by Robert B.

flavicon
face
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 removed}

2004\08\13@013519 by Marc Nicholas

flavicon
face
You really don't need an iButton holder. Email me privately if you want
to discuss.


-marc

-----Original Message-----
From: pic microcontroller discussion list
[.....PICLISTRemoveMEspamMITVMA.MIT.EDU] On Behalf Of Robert B.
Sent: Thursday, August 12, 2004 5:41 PM
To: .....PICLISTSTOPspamspam@spam@MITVMA.MIT.EDU
Subject: Re: [EE:] Ibutton Samples

Sample code is very welcome!  Especially if it's in assembly or C.  I've
been rummaging in the samples package and it seems they opted not to
include
the ibutton holders I requested, so I guess its a homebrew clip until I
find
a place to order a few from.  Maxim's online ordering has a 13-week lead
time and doesn't seem to be working anyway.  Any ideas for alternate
suppliers?



----- Original Message -----
From: "Shawn Yates" <syatesEraseMEspam@spam@CARETECH.NET>
To: <RemoveMEPICLISTspamspamBeGoneMITVMA.MIT.EDU>
Sent: Thursday, August 12, 2004 5:26 PM
Subject: Re: [EE:] Ibutton Samples


> I have made a PIC talk to the iButton.  From what I remember it was
> pretty straight forward after reading the specs.  I may be able to
find
{Quote hidden}

ibutton
> key, modifying it according to some algorithm, then writing the
modified
> key back to the ibutton.  The samples I received are 1-k-bit NVram,
and
{Quote hidden}

from
{Quote hidden}

on
{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2004\08\13@013726 by Charles Craft

picon face
A lot of good ones here:
http://www.asepco.com/Oddities_&_Jokes_main_pg.htm

including this oldie but goodie:

"Arguing with an engineer is a lot like wrestling in the mud with a pig.
After a few hours, you realize that he likes it."

{Original Message removed}

2004\08\13@042647 by Nigel Orr

flavicon
face
Olin Lathrop wrote:
> 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.

I've not used them, but IIRC that is exactly what the cryptographic
ibuttons do.  As others have said, it would be relatively easy to 'clone'
an ibutton, but extremely difficult to clone the crypto ones.

Nigel
--
Nigel Orr, Design Engineer                 nigelspamBeGonespam.....axoninstruments.co.uk
Axon Instruments Ltd., Wardes Road,Inverurie,Aberdeenshire,UK,AB51 3TT
              Tel:+44 1467 622332 Fax:+44 1467 625235
                  http://www.axoninstruments.co.uk

This e-mail and any files transmitted with it ("E-mail") is intended
solely for the addressee(s) and may contain confidential and/or legally
privileged information.  If you are not the addressee(s), any
disclosure, reproduction, copying, distribution or other use of the
E-mail is prohibited.  If you have received this E-mail in error,
please delete it and notify the sender immediately via our switchboard
or return e-mail.

Neither the company nor any individual sending this E-mail accepts any
liability in respect of the content (including errors and omissions)
and timeliness of the E-mail which arise as a result of transmission.
If verification is required, please request a hard copy version

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspam.....mitvma.mit.edu

2004\08\13@074446 by Olin Lathrop

face picon face
Robert B. wrote:
> 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.

Yes, of course they are.  But you weren't thinking of the ibutton being the
only component of the lock, were you?  For that matter, why do you need an
ibutton anyway?  Couldn't you just as easily program some code into the
non-volatile memory of the lock and key yourself?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestspamKILLspammitvma.mit.edu

2004\08\13@074900 by Olin Lathrop

face picon face
Robert B. wrote:
> Again very valid criticisms.  But I think you're confusing the
> ibuttons with something else.  The ibuttons don't have any
> read-protected eeprom, and can't do any computations on their own
> (afaict).  So copying all the data in the ibutton is easy to do and
> in my mind represents a security hole larger than 0.1%.

So don't do it that way!

I guess I'm finally understanding that you mean for the ibutton to be the
sole component of the key.  Yes, I agree, that's a bad design.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu

2004\08\13@075728 by Howard Winter

face
flavicon
picon face
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?  :-)

{Quote hidden}

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
KILLspampiclist-unsubscribe-requestspamspamBeGonemitvma.mit.edu

2004\08\13@075936 by Nigel Orr

flavicon
face
Olin Lathrop wrote:
> Robert B. wrote:
>> 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.
>
> Yes, of course they are.

Actually, they aren't.  Some of them have processors inside, running java.
It might be worth looking at the range available.

As well as ID (and other applications- I use them for home temperature
monitoring), they are used for monetary applications which require a much
higher degree of security than 'is this the correct serial number', or
'does this RAM contain the correct data', both of which can be easily
cloned.

Nigel

--
This e-mail and any files transmitted with it ("E-mail") is intended
solely for the addressee(s) and may contain confidential and/or legally
privileged information.  If you are not the addressee(s), any
disclosure, reproduction, copying, distribution or other use of the
E-mail is prohibited.  If you have received this E-mail in error,
please delete it and notify the sender immediately via our switchboard
or return e-mail.

Neither the company nor any individual sending this E-mail accepts any
liability in respect of the content (including errors and omissions)
and timeliness of the E-mail which arise as a result of transmission.
If verification is required, please request a hard copy version

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspammitvma.mit.edu

2004\08\13@114340 by Alex Harford

face picon face
On Fri, 13 Aug 2004 12:56:45 +0100, Howard Winter
<RemoveMEhdrwspamBeGonespamRemoveMEh2org.demon.co.uk> 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
KILLspampiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu

2004\08\13@114547 by Herbert Graf

flavicon
face
On Fri, 2004-08-13 at 07:56, Howard Winter wrote:

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

Unfortunately it's not, it's barely more secure then the simple serial
number. The reason is to get the "password" all one would have to do is
connect a device to the reader and sniff the password (since it's spit
out on every transaction). Then just get access to the iBUTTON and boom,
you're in business. A step harder then just a serial number, but still
nowhere near anything I'd consider secure.



-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestSTOPspamspam@spam@mitvma.mit.edu

2004\08\13@115133 by Shawn Yates

flavicon
face
You could store a date/time stamp of the last successful access in the
password protected part of the iButton.  Update it in the iButton and in
the controller every time the button is used.  Then if the code is
duplicated, it has to be used before the user uses the correct button
again because then the date/time stamp will change.  Even if an knows
the stored data is date and time, the would have to know the exact date
and time the real user accessed the system last.  If you measuer down to
the mS, that would be pretty hard for someone to duplicate the date/time
stamp.



{Original Message removed}

2004\08\13@122754 by Robert B.

flavicon
face
----- Original Message -----
From: "Olin Lathrop" <olin_piclistspamBeGonespamspamBeGoneEMBEDINC.COM>
To: <spamBeGonePICLISTspamMITVMA.MIT.EDU>
Sent: Friday, August 13, 2004 7:44 AM
Subject: Re: [EE:] Ibutton Samples


> Robert B. wrote:
> > 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.
>
> Yes, of course they are.  But you weren't thinking of the ibutton being
the
> only component of the lock, were you?

No, but the Ibutton was to be the only component of the key.

> For that matter, why do you need an
> ibutton anyway?

I'm beginning to wonder that myself... :)  The idea is that they're durable,
waterproof, easy to use devices.

> Couldn't you just as easily program some code into the
> non-volatile memory of the lock and key yourself?

I suppose I could, but then what would I do with all these Ibutton samples
I've got?

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestSTOPspamspammitvma.mit.edu

2004\08\13@123721 by Robert B.

flavicon
face
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 removed}

2004\08\13@131915 by M. Adam Davis

flavicon
face
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:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestspamspamspam_OUTmitvma.mit.edu

2004\08\13@132124 by M. Adam Davis

flavicon
face
Ah, a typical engineering problem:

You need to find the problem that your solution fits.

Don't worry, every engineer faces this.

-Adam

Robert B. wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestSTOPspamspamRemoveMEmitvma.mit.edu

2004\08\13@135650 by Anthony Toft

flavicon
face
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:
{Quote hidden}

> {Original Message removed}

2004\08\13@140521 by Denny Esterline

picon face
I'm a little late to this party so maybe I missed something. But I don't
understand the problem. You want to use an iButton as a key in an
electronic door lock and your concerned about security?

This must be a problem that's been solved, Maxim's web site lists more than
twenty commercial products that do this for residential applications alone.
http://db.maxim-ic.com/ibutton/solutions/search.cfm?Action=DD&id=176

Then there's the one-wire appnote library:
http://www.maxim-ic.com/appnotes10.cfm/ac_pk/1
With several dealing with passwords, authentication and security.

Not to insult anyone, but I have to take exception to the comment about
iButtons not being widespread.

Take a look over at http://www.iButton.com Lots of interesting applications, not
the least of which is 1.4 million (yes million) in use in turkey as
electronic mass transit tokens and an interesting application using
thermochrons (iButton temperature loggers) for measuring fish habitat.
The last place I worked had a bunch of them stuck to walls in different
parts of the building and parking lots, the night security people had a
recording device they read all the buttons with as they made their rounds.
(Proved they were doing their job)

-Denny





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

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu

2004\08\13@142849 by Roland

flavicon
face
>>I suppose I could, but then what would I do with all these Ibutton samples
>>I've got?
>>
>>

Sell them to a Dullus fanatic;-]
I think you could get far better security with a 10-pin pic and a bit of
code to suit your fancy.
The pic can perform simple operations on a seed input and return a string,
that would take a huge amount of computing to decipher.

(sigh, another pet project someones going to make millions out of)

Regards
Roland Jollivet

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestRemoveMEspam@spam@mitvma.mit.edu

2004\08\14@044953 by Peter L. Peres

picon face
If you would use a challenge/response type of authentication implemented
in a single chip micro with internal storage then it would not be
worrysome if someone pinched it. Especially if you'd need a pin code to
make it work right. And nobody copies a secured micro in seconds or
minutes (unless there are backdoors in the programming/securing
algorythm).

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\14@193904 by Howard Winter

face
flavicon
picon face
Robert,

On Fri, 13 Aug 2004 12:36:54 -0400, 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.

I think you missed a subtelty in my suggested scheme (you weren't the only one!) - the door only emits a
password when it sees the correct iButton's serial number.  So you would have had to have had the iButton's
serial number "sniffed" first.

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

Not if you follow the scheme I described - a given password-value would only ever be valid for one out-in
excursion, which limits the intrusion opportunity to the time you are out that one time, during which they
have to get access to your button to sniff the data, having previously sniffed the serial number from the
button, and the current password from the door, then get back to your door for the intrusion.

I've just realised that with the change-the-last-password idea, you would find yourself locked out in two
entries' time... which is inconvenient, but also tells you there was an intrusion, if a bit late!  :-)  There
are other options, for example you can use two passwords at a time, with the second one issued only when the
first key has been confirmed, so further complicating the process needed to get past it.  But you have to ask
yourself:  is anyone really going to go to the trouble of deducing your scheme, and developing a way to defeat
it, rather than just breaking in by traditional methods?  And all this depends on your being careless with
your keyring... might I suggest a belt-clip?  :-)

One thing you could do regardless of the lock mechanism, is for the door to always tell you the time/date when
you last entered, so you would be able to detect an intrusion whatever the keep-out method.

> I wonder if these problems are why ibuttons aren't as widespread as they
> might be..

They are used a lot, but not for high-security applications, as far as I know.  One problem seems to be buying
the darned things - I had a quick Google and couldn't find anyone selling them hereabouts (they used to be
sold by Maplin, the biggest chain of electronic component shops in Britain - they had quite a range from the
evaluation kit, the buttons themselves, the little plastic holders for attaching to a keyring, to
panel-mounted touch-pads - now they don't sell any of it).

Cheers,


Howard Winter
St.Albans, England

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\17@025522 by Nate Duehr

face
flavicon
face
On Thursday 12 August 2004 22:41, Robert B. wrote:

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

Three rules of system security:

Something you have: Key
Something you know: Password
Something you are: Biometrics

Those are the "basics"... it of course, can get more complicated from there...

It's all about psychology though -- putting up signs that you have a security
system (even if you don't) and a real or fake camera staring at the property
will give more theives pause than an innocuous iButton reader next to the
front door.

And the iButton only fills the first rule anyway.  Someone mentioned a keypad
and a password, that's rule #2...

And as Olin and others have said, no thief is coming in through the front door
anyway -- they're coming in the basement window with a large rock.

Think about who you're trying to keep out and how they THINK and you'll end up
with a better security system than an iButton-based idea.  The trick is to
frighten off the dumb ones, that covers 99% of security.  The rest are going
to get in if they want to anyway -- and on those you just have to decide how
badly you want to a) know they were there, and b) identify them.

An iButton-based lock is a neat toy, but has absolutely nothing to do with
"security".

There are plenty of unlocked but highly-secure places in the world.  Of
course, many of them have found that paying 18-year-olds with M-16 rifles is
the easiest way to both identify visitors and scare off people who shouldn't
be there.

It's all about finding a balance, but I don't think the iButton lock buys you
much over a decent quality mechanical lock.  Heck, the iButton requires
power, metal gears don't... it actually has some very distinct disadvantages.

--
Nate Duehr, EraseMEnateRemoveMEspamnatetech.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamlistserv.....spamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\08\17@093138 by Olin Lathrop

face picon face
Nate Duehr wrote:
> It's all about finding a balance, but I don't think the iButton lock
> buys you much over a decent quality mechanical lock.  Heck, the
> iButton requires power, metal gears don't... it actually has some
> very distinct disadvantages.

People should also consider that a mechanical key is merely the embodiment
of a small password.  A standard pin and tumbler lock has a fixed number of
pins, usually 6 for a normal house lock.  For manufacturing and accuracy
reasons, each of these pins will be unlocked at one of a small number of
fixed levels for that model of lock.  Five levels is common.  Therefore the
key is merely a mechanical embodiment of a 6 digit base 5 password.  The
chance of any random key opening the lock is 1 / (5 ** 6) = .0064%, or 1 in
16K keys.

There are other wrinkles however.  In a large installation with many rooms
or buildings like a school, there are usually master keys that open all
locks or a set of locks.  Sometimes there are hierachical master keys, like
one for each building, with high level master keys that open any lock in a
group of buildings or the whole installation.  This is done by adding more
cuts to the pins of each lock.  This means that each pin in each lock
actually responds to more than one cut level on the key.  There are now a
large number of possible keys that could open a particular lock.  If each
pin has 3 cuts, then the chance of a random cut level matching a pin are
3/5.  For all 6 pins, the chance of a random key opening the lock is (3/5)
** 6 = 4.7%, or about 1 in 21 keys.

And it gets worse.  Again in large organizations, various locks need to be
changed on a regular basis as people come and go, rooms take on new uses,
things break, etc.  Removing and replacing the whole lock as you would do
with your house front door is way too tedious and expensive.  Instead, the
locks essentially have two independent tumblers, one to open the lock and
the other to remove the core.  The locksmith (a full time job at a large
installation) has a "core puller" key that is used to remove and replace
lock cores in the doors.  This can be done in matter of seconds.

Someone that is very familiar with a particular series of key at such an
installation can look at a key and immediately read off the cut levels.  I
know that because I've done it.  A two second close up look of the key is
all that's required.

When I was at RPI from 1974 thru 1980, the key system was divided into 5
different trees.  There was a "grand master" key for each tree, plus
building masters and sometimes departmental master keys within buildings.
By the time I left, I had figured out how to make 3 of the 5 grand master
keys, and a core puller that worked for two of the trees.  The biggest
breakthru came when the key guy came to change the locks of one of the labs
I was working in.  I already knew about core pullers and master keys, but
played dumb.  I said something like "Gee, this key looks just like any other
key but can take the lock out!?".  That allowed me to hold it in my hand for
a couple of seconds, during which time I read off and memorized the cut
levels.  As soon as he left I wrote them down and made my own core puller.
After that treeing out to more locks is trivial since you can take out the
core and determine the various cut levels that would unlock each pin.  After
examining only a few locks, the grand master cut levels are usually pretty
obvious.


*****************************************************************
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 listservspam_OUTspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2004\08\19@105517 by Howard Winter

face
flavicon
picon face
Olin,

On Tue, 17 Aug 2004 09:30:28 -0400, Olin Lathrop wrote:

> By the time I left, I had figured out how to make 3 of the 5 grand master keys, and a core puller that
worked for two of the trees.

I'm sure a lot of electronics enthusiasts (professional or otherwise) have a fascination for mechanisms like
locks.  I know I have!  :-)  However security people tend to take a dim view of people breaching their
systems, even if it's "for fun"... they have no sense of humour about this sort of thing!

However I was astounded to find out how easily I could get into the security system we had at my previous firm
- it was controlled by a PC (logon password found by looking round the room for likely candidates) and the
password data was held in an Access database, with the passwords encrypted.  It took 15 minutes (including
writing a little program to help) for me to deduce the encryption scheme and get access to all the passwords.
The encryption was very naieve (probably about the 5th simplest substitution cypher you could come up with,
where "shift each letter one along the alphabet" is the 1st) but I bet the programmer thought it was
brilliant.

The thing is that the designer of something secure, at least those who are new to it, tends to think that
coming up with something "complicated" means nobody will think of trying that, whereas cracking it doesn't
usually require thinking up how they could have done it.  Any system that relies on a potential cracker not
knowing how it works is just not going to be secure for very long!

Cheers,




Howard Winter
St.Albans, England

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\08\28@222304 by hilip Stortz

picon face
which is why cryptography should be done by people who've bothered to
study it, and preferably using a method that others (not just the
programer) think is good, and then it has to be implemented correctly.
there's a lot of really bad cryptography out there on all sorts of
programs, much of which has been cracked, for some there are even
"utilities" for when someone forgets a password, hopefully seeing that
there is such a utility will make them realize what a waste of time the
password/"encryption" was.  a lot of people think they are more clever
than they are, and very often their schemes are trivial to crack.

Howard Winter wrote:
-------
{Quote hidden}

--
<www.informationclearinghouse.info/article3267.htm>
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...