Difference between revisions of "Secure iButton"

From RevSpace
Jump to: navigation, search
(Set up new page from project template)
 
(Add more links, remove redundant information)
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Project
 
{{Project
 
   |Name=Secure iButton
 
   |Name=Secure iButton
   |Status=Initializing
+
   |Status=In progress
   |Contact=Bertrik Sikken
+
   |Contact=User:Bertrik Sikken
 
}}
 
}}
 +
 +
This project is about investigating and using the secure features of the iButton that people currently use for physical access to RevSpace. See also [[Doorduino2]] and the [https://github.com/RevelationSpace/doorduino2.5 Doorduino 2.5] GitHub project.
 +
 +
Planned project phases are:
 +
* phase 1: investigate possbilities of the iButton and experiment with it
 +
* phase 2: write software for the iButton functionality and package it into a library
 +
* phase 3: apply knowledge and software for application within RevSpace
 +
 +
==iButton investigation==
 +
The iButton used at RevSpace is the DS1961, with the following features:
 +
* 4 pages of 32-byte user data each
 +
* an 8-byte write-only "secret"
 +
* SHA-1 algorithm that can calculate a hash over a 32-byte user data page stored on the iButton, the 8-byte secret, a 3-byte "challenge" and the unique iButton id.
 +
 +
===Bus pirate experimentation===
 +
Investigation of the DS1961-specific commands can be done with a Bus Pirate.
 +
A bus pirate speaks the 1-wire protocol that any iButton-like device uses.
 +
 +
Examples of bus pirate commands to communicate with the DS1961:
 +
* Initialise the bus pirate
 +
  # (reset the bus pirate)
 +
  M (select mode)
 +
  2 (1-wire mode)
 +
  W (enable power)
 +
* Reset the iButton and get iButton unique id
 +
  (240)
 +
* Example exchange for command 0xA5 (Read Auth Page), which is the secure read command
 +
<pre>
 +
1-WIRE>0xa5 0 0 r:32 r r:2 &:1500 r:20 r:2
 +
WRITE: 0xA5
 +
WRITE: 0x00
 +
WRITE: 0x00
 +
READ 0x20 BYTES:
 +
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
 +
READ: 0xFF
 +
READ 0x02 BYTES:
 +
0x6D 0x0D
 +
DELAY 0xDCuS
 +
READ 0x14 BYTES:
 +
0x45 0x31 0x40 0x42 0xAE 0xD3 0x4B 0xC5 0x18 0xCC 0x10 0x43 0x27 0x56 0x33 0xD0 0xEB 0x47 0xA7 0x81
 +
READ 0x02 BYTES:
 +
0xAA 0x6D
 +
</pre>
 +
 +
Conclusion: the bus pirate has proven to be an excellent tool for initial prototyping with the DS1961 iButton.
 +
 +
==DS1961 library==
 +
This library provides an API for the DS1961 specific functions.
 +
It will be targeted at the Arduino microcontroller, to run on top of the existing [http://playground.arduino.cc/Learning/OneWire Arduino OneWire] library.
 +
 +
Experimental code is available on the GitHub [https://github.com/bertrik/ibutton-test ibutton-test] project.
 +
 +
==Application==
 +
We could apply this to improve the security of RevSpace access for example.
 +
to be discussed.
 +
 +
Stuff to be considered for access control:
 +
* an extra initialisation step to install the secret before use is needed
 +
* how can we handle the transition of the current iButton system to a more secure system?
 +
* how advanced do we make the authentication scheme / how is key management handled?
 +
** Simplest: one secret for all revspace iButtons. Disadvantage: cracking one iButton means that *all* revspace iButtons are cracked.
 +
** More advanced: different secret for each revspace iButton (e.g. calculated from a master secret and the iButton serial number, or just generated every time and stored)
 +
 +
===Concrete proposal===
 +
The following protocol extension for communication with the Arduino is proposed.
 +
 +
On the Arduino side, the following command/response exchange is added:
 +
* an extra command to send the 3-byte '''C'''hallenge (in hex-ascii), example
 +
<pre>C AB34EF</pre>
 +
* a corresponding response to return the 32-byte data and the 20-byte hash, example
 +
<pre>C 0000000000000000000000000000000000000000000000000000000000000000 D54A4731DC5EDF675D7B0A23A6D83534FAE12E3F</pre>
 +
TODO: what to respond if communication with the ibutton fails somehow?
 +
 +
On the server side, the access control sequence is extended as follows:
 +
* receive an ibutton id from the Arduino
 +
* lookup the id in the access control list
 +
* if the id is not present, don't open the door
 +
* if the id has no associated secret, open the door
 +
* if the id has an associated secret, generate the 3-byte challenge and perform the challenge/response sequence
 +
* if the response matches the expected response, open the door
 +
 +
==External Links==
 +
[http://www.maximintegrated.com/products/ibutton/software/1wire/wirekit.cfm Maxim iButton 1-wire public domain kit]

Revision as of 18:28, 21 January 2013

Project Secure iButton
Status In progress
Contact User:Bertrik Sikken
Last Update 2013-01-21

This project is about investigating and using the secure features of the iButton that people currently use for physical access to RevSpace. See also Doorduino2 and the Doorduino 2.5 GitHub project.

Planned project phases are:

  • phase 1: investigate possbilities of the iButton and experiment with it
  • phase 2: write software for the iButton functionality and package it into a library
  • phase 3: apply knowledge and software for application within RevSpace

iButton investigation

The iButton used at RevSpace is the DS1961, with the following features:

  • 4 pages of 32-byte user data each
  • an 8-byte write-only "secret"
  • SHA-1 algorithm that can calculate a hash over a 32-byte user data page stored on the iButton, the 8-byte secret, a 3-byte "challenge" and the unique iButton id.

Bus pirate experimentation

Investigation of the DS1961-specific commands can be done with a Bus Pirate. A bus pirate speaks the 1-wire protocol that any iButton-like device uses.

Examples of bus pirate commands to communicate with the DS1961:

  • Initialise the bus pirate
  # (reset the bus pirate)
  M (select mode)
  2 (1-wire mode)
  W (enable power)
  • Reset the iButton and get iButton unique id
  (240)
  • Example exchange for command 0xA5 (Read Auth Page), which is the secure read command
1-WIRE>0xa5 0 0 r:32 r r:2 &:1500 r:20 r:2
WRITE: 0xA5
WRITE: 0x00
WRITE: 0x00
READ 0x20 BYTES:
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
READ: 0xFF
READ 0x02 BYTES:
0x6D 0x0D
DELAY 0xDCuS
READ 0x14 BYTES:
0x45 0x31 0x40 0x42 0xAE 0xD3 0x4B 0xC5 0x18 0xCC 0x10 0x43 0x27 0x56 0x33 0xD0 0xEB 0x47 0xA7 0x81
READ 0x02 BYTES:
0xAA 0x6D

Conclusion: the bus pirate has proven to be an excellent tool for initial prototyping with the DS1961 iButton.

DS1961 library

This library provides an API for the DS1961 specific functions. It will be targeted at the Arduino microcontroller, to run on top of the existing Arduino OneWire library.

Experimental code is available on the GitHub ibutton-test project.

Application

We could apply this to improve the security of RevSpace access for example. to be discussed.

Stuff to be considered for access control:

  • an extra initialisation step to install the secret before use is needed
  • how can we handle the transition of the current iButton system to a more secure system?
  • how advanced do we make the authentication scheme / how is key management handled?
    • Simplest: one secret for all revspace iButtons. Disadvantage: cracking one iButton means that *all* revspace iButtons are cracked.
    • More advanced: different secret for each revspace iButton (e.g. calculated from a master secret and the iButton serial number, or just generated every time and stored)

Concrete proposal

The following protocol extension for communication with the Arduino is proposed.

On the Arduino side, the following command/response exchange is added:

  • an extra command to send the 3-byte Challenge (in hex-ascii), example
C AB34EF
  • a corresponding response to return the 32-byte data and the 20-byte hash, example
C 0000000000000000000000000000000000000000000000000000000000000000 D54A4731DC5EDF675D7B0A23A6D83534FAE12E3F

TODO: what to respond if communication with the ibutton fails somehow?

On the server side, the access control sequence is extended as follows:

  • receive an ibutton id from the Arduino
  • lookup the id in the access control list
  • if the id is not present, don't open the door
  • if the id has no associated secret, open the door
  • if the id has an associated secret, generate the 3-byte challenge and perform the challenge/response sequence
  • if the response matches the expected response, open the door

External Links

Maxim iButton 1-wire public domain kit