Secure iButton - Bewerkingsoverzicht

Juerd: Juerd moved page SecureIButton to Secure iButton

2016-09-11T03:37:37Z

Juerd moved page SecureIButton to Secure iButton

← Oudere versie		Versie van 11 sep 2016 03:37
(geen verschil)

Juerd: /* Idee voor betere challenge */

2016-06-12T15:14:41Z

Idee voor betere challenge

← Oudere versie		Versie van 12 jun 2016 15:14
Regel 112:		Regel 112:
	Dit gaat van 2<sup>24</sup> naar minimaal 2<sup>24</sup> + 2<sup>24 + 64</sup> bij een nieuwe ibutton, maar omdat een hele datapagina wordt gebruikt terwijl er maar 8 bytes veranderen, kan het in het beste geval zelfs 2<sup>24</sup> + 2<sup>24 + 4 * 64</sup> worden.		Dit gaat van 2<sup>24</sup> naar minimaal 2<sup>24</sup> + 2<sup>24 + 64</sup> bij een nieuwe ibutton, maar omdat een hele datapagina wordt gebruikt terwijl er maar 8 bytes veranderen, kan het in het beste geval zelfs 2<sup>24</sup> + 2<sup>24 + 4 * 64</sup> worden.

	De vraag is vooral of het snel genoeg zal zijn om in het korte contactmoment allemaal te doen. Het aantal hashes dat berekend wordt door de iButton gaat van 1 naar 3 (dus 3 * T<sub>CSHA</sub> = 12 ms (want ruim gedefinieerd in DS1961.cpp)), het aantal 1-wire-command's na de initiele search gaat van 2 naar 10, waaronder 2x T<sub>PROG</sub> = 20 ms extra wachten.		De vraag is vooral of het snel genoeg zal zijn om in het korte contactmoment allemaal te doen. Het aantal hashes dat berekend wordt door de iButton gaat van 1 naar 3 (dus 3 * T<sub>CSHA</sub> = 6 ms (want ruim gedefinieerd in DS1961.cpp)), het aantal 1-wire-command's na de initiele search gaat van 2 naar 10, waaronder 2x T<sub>PROG</sub> = 20 ms extra wachten.

	'''Update:''' goed te doen na wat [https://github.com/revspace/doorduino/commit/09d93c0568d3ed95386befda44a8e7dcfef89c95 tweaks].		'''Update:''' goed te doen na wat [https://github.com/revspace/doorduino/commit/09d93c0568d3ed95386befda44a8e7dcfef89c95 tweaks].

Juerd: /* Idee voor betere challenge */

2016-06-12T15:10:23Z

Idee voor betere challenge

← Oudere versie		Versie van 12 jun 2016 15:10
Regel 93:		Regel 93:

	==Idee voor betere challenge==		==Idee voor betere challenge==
			'''Inmiddels [https://github.com/revspace/doorduino/commit/2bc8631bef87e64e34a68fe0ae96313420bbdec0 geïplementeerd].'''

	3 bytes challenge is nogal karig: 2<sup>24</sup> mogelijke antwoorden per secret betekent en ca. 3 ms per hash betekent dat je een iButton maar 2<sup>24</sup> * 3 ms = 14 h in bezit hoeft te hebben om genoeg informatie te krijgen om 'm volledig te na te bootsen met een [https://github.com/orgua/OneWireHub iButton slave]-emulator. Als je akkoord gaat met authenticatiefouten, kun je met een minder volledige (iButton-specifieke) rainbow table volstaan: 7 uur voor 50% kans, 3,5 uur voor 25% kans, 1 uur voor 14% kans.		3 bytes challenge is nogal karig: 2<sup>24</sup> mogelijke antwoorden per secret betekent en ca. 3 ms per hash betekent dat je een iButton maar 2<sup>24</sup> * 3 ms = 14 h in bezit hoeft te hebben om genoeg informatie te krijgen om 'm volledig te na te bootsen met een [https://github.com/orgua/OneWireHub iButton slave]-emulator. Als je akkoord gaat met authenticatiefouten, kun je met een minder volledige (iButton-specifieke) rainbow table volstaan: 7 uur voor 50% kans, 3,5 uur voor 25% kans, 1 uur voor 14% kans.

Regel 100:		Regel 102:
	* (data, hash) = ReadAuthPage(addr & 0xffe0, challenge)		* (data, hash) = ReadAuthPage(addr & 0xffe0, challenge)
	* check hash == sha1(...)		* check hash == sha1(...)
	* data[addr % 32 : 8] = ~~random string~~		* rs = random string van 8 bytes
	* sp = ReadScratchpad()		* data[addr % 32 : 8] = rs
	* mac = sha1(id; data; secret; sp; ...)		* mac = sha1(id; data; secret; rs; ...)
	* WriteData(addr, data, mac)		* WriteData(addr, data, mac)
	* nieuwe challenge		* nieuwe challenge
Regel 111:		Regel 113:

	De vraag is vooral of het snel genoeg zal zijn om in het korte contactmoment allemaal te doen. Het aantal hashes dat berekend wordt door de iButton gaat van 1 naar 3 (dus 3 * T<sub>CSHA</sub> = 12 ms (want ruim gedefinieerd in DS1961.cpp)), het aantal 1-wire-command's na de initiele search gaat van 2 naar 10, waaronder 2x T<sub>PROG</sub> = 20 ms extra wachten.		De vraag is vooral of het snel genoeg zal zijn om in het korte contactmoment allemaal te doen. Het aantal hashes dat berekend wordt door de iButton gaat van 1 naar 3 (dus 3 * T<sub>CSHA</sub> = 12 ms (want ruim gedefinieerd in DS1961.cpp)), het aantal 1-wire-command's na de initiele search gaat van 2 naar 10, waaronder 2x T<sub>PROG</sub> = 20 ms extra wachten.

			'''Update:''' goed te doen na wat [https://github.com/revspace/doorduino/commit/09d93c0568d3ed95386befda44a8e7dcfef89c95 tweaks].

	Onduidelijk is of RefreshScratchpad en LoadFirstScret, die instabiele EEPROM-data voorkomen, wel nodig zijn voor deze use-case. Als er een byte van het EEPROM onbetrouwbaar blijkt, wordt in het ergste geval een deur-opening geweigerd. De volgende keer zal ie waarschijnlijk wel werken, als de cel alsnog stabiliseert. Ik weet niet of dat gebeurt, en moet me verdiepen in failure modes van EEPROMs. Als we deze commando's kunnen overslaag scheelt dat 2 commando's en 1x T<sub>PROG</sub>.		Onduidelijk is of RefreshScratchpad en LoadFirstScret, die instabiele EEPROM-data voorkomen, wel nodig zijn voor deze use-case. Als er een byte van het EEPROM onbetrouwbaar blijkt, wordt in het ergste geval een deur-opening geweigerd. De volgende keer zal ie waarschijnlijk wel werken, als de cel alsnog stabiliseert. Ik weet niet of dat gebeurt, en moet me verdiepen in failure modes van EEPROMs. Als we deze commando's kunnen overslaag scheelt dat 2 commando's en 1x T<sub>PROG</sub>.

			'''Update:''' ja, is nodig. Gaat best vaak fout als je de refresh weglaat.

	De iButtons ondersteunen een snellere communicatie via "Overdrive mode". Uitgezocht moet worden hoeveel tijd hiermee kan worden bespaard en hoeveel moeite het is om dit is om te implementeren; de standaard OneWire-library voor Arduino ondersteunt het niet, maar er is een [http://forum.arduino.cc/index.php?topic=201776.0 fork uit 2013].		De iButtons ondersteunen een snellere communicatie via "Overdrive mode". Uitgezocht moet worden hoeveel tijd hiermee kan worden bespaard en hoeveel moeite het is om dit is om te implementeren; de standaard OneWire-library voor Arduino ondersteunt het niet, maar er is een [http://forum.arduino.cc/index.php?topic=201776.0 fork uit 2013].

			'''Update:''' Wordt op diverse plekken afgeraden voor 1-wire over lange kabels (tientallen meters), dus niet geprobeerd.

	Het aantal EEPROM-cycles lijkt geen probleem. Er zijn 16 stukken EEPROM van 8 bytes. In de worst case wordt willekeurig steeds hetzelfde blok overschreven. Uitgaande van de helft van de gespecte 50k writes kom je dan nog op 25k uit, of bijvoorbeeld 8 jaar lang, 3 keer per week 20 keer per bezoek...		Het aantal EEPROM-cycles lijkt geen probleem. Er zijn 16 stukken EEPROM van 8 bytes. In de worst case wordt willekeurig steeds hetzelfde blok overschreven. Uitgaande van de helft van de gespecte 50k writes kom je dan nog op 25k uit, of bijvoorbeeld 8 jaar lang, 3 keer per week 20 keer per bezoek...

Juerd op 2 jun 2016 om 03:12

2016-06-02T03:12:33Z

@@ Regel 8: / Regel 8: @@
 '''Project status: software library has been integrated in our hacker space physical access system.'''
-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/revspace/doorduino2.5 Doorduino 2.5] GitHub project.
+This project is about investigating and using the secure features of the iButton that people currently use for physical access to RevSpace. See also [[Doorduino]] and the [https://github.com/revspace/doorduino Doorduino] GitHub project.
 Planned project phases are:
@@ Regel 90: / Regel 90: @@
 ==External Links==
 [http://www.maximintegrated.com/products/ibutton/software/1wire/wirekit.cfm Maxim iButton 1-wire public domain kit]

FooBar op 13 jan 2016 om 22:48

2016-01-13T22:48:47Z

← Oudere versie		Versie van 13 jan 2016 22:48
Regel 3:		Regel 3:
	\|Status=Completed		\|Status=Completed
	\|Contact=User:Bertrik Sikken		\|Contact=User:Bertrik Sikken
			\|Picture=ibutton.png
	}}		}}

FooBar op 13 sep 2014 om 23:18

2014-09-13T23:18:57Z

← Oudere versie		Versie van 13 sep 2014 23:18
Regel 7:		Regel 7:
	'''Project status: software library has been integrated in our hacker space physical access system.'''		'''Project status: software library has been integrated in our hacker space physical access system.'''

	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.		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/revspace/doorduino2.5 Doorduino 2.5] GitHub project.

	Planned project phases are:		Planned project phases are:

Bertrik Sikken op 8 mrt 2014 om 09:23

2014-03-08T09:23:21Z

← Oudere versie		Versie van 8 mrt 2014 09:23
Regel 4:		Regel 4:
	\|Contact=User:Bertrik Sikken		\|Contact=User:Bertrik Sikken
	}}		}}

			'''Project status: software library has been integrated in our hacker space physical access system.'''

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

Bertrik Sikken: Status -> Completed

2013-08-26T15:54:37Z

Status -> Completed

← Oudere versie		Versie van 26 aug 2013 15:54
Regel 1:		Regel 1:
	{{Project		{{Project
	\|Name=Secure iButton		\|Name=Secure iButton
	\|Status=~~In progress~~		\|Status=Completed
	\|Contact=User:Bertrik Sikken		\|Contact=User:Bertrik Sikken
	}}		}}

Bertrik Sikken: Add more links, remove redundant information

2013-01-21T17:28:27Z

Add more links, remove redundant information

← Oudere versie		Versie van 21 jan 2013 17:28
Regel 5:		Regel 5:
	}}		}}

	~~<!--~~		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.
	~~[https://revspace.nl/mediawiki/index.php?title=SecureIButton&action=purge purge cache]~~

	~~{{#ask:[[Category:Smoel]]~~
	~~\| ?Name~~
	~~\| ?Nick~~
	~~\| ?Tagline~~
	}}
	~~-->~~

	This project is about investigating and using the secure features of the iButton that people currently use for physical access to RevSpace.

	Planned project phases are:		Planned project phases are:
Regel 26:		Regel 16:
	* 4 pages of 32-byte user data each		* 4 pages of 32-byte user data each
	* an 8-byte write-only "secret"		* an 8-byte write-only "secret"
	* SHA-1 algorithm that can calculate a hash over a 32-byte user data page, the 8-byte secret, a 3-byte "challenge" and the unique iButton id.		* 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.

	~~Basically authentication could work like this:~~
	* (the secret key has been installed on the iButton previously)
	* user presents iButton to the reader
	* reader reads the unique iButton id
	* reader generates a random number and uses this as the challenge to read a 32-byte user page
	* iButton sends the user page, followed by the SHA-1 hash
	* reader also calculates SHA-1 hash and compares it with the iButton hash
	* if the hash matches, the user data can be considered as authentic and the reader can interpret the user data as a "deelnemer id" (or something) for example.

	===Bus pirate experimentation===		===Bus pirate experimentation===
Regel 49:		Regel 30:
	* Reset the iButton and get iButton unique id		* Reset the iButton and get iButton unique id
	(240)		(240)
	* ~~Write scratchpad (~~command ~~0x0F) at address 0,0 with data 1 2 3 4 5 6 7 8~~		* Example exchange for command 0xA5 (Read Auth Page), which is the secure read command
	~~0x0f 0 0 1 2 3 4 5 6 7 8 r:2~~
	* Read scratchpad (~~command 0xAA)~~
	~~0xaa r:3 r:8 r:2~~
	* Read ~~auth page (command 0xA5~~), which is the secure read command
	~~0xa5 0 0 r:32 r r:2 &:1500 r:20 r:2~~
	~~Example response:~~
	<pre>		<pre>
	1-WIRE>0xa5 0 0 r:32 r r:2 &:1500 r:20 r:2		1-WIRE>0xa5 0 0 r:32 r r:2 &:1500 r:20 r:2
Regel 72:		Regel 47:
	0xAA 0x6D		0xAA 0x6D
	</pre>		</pre>

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

	==DS1961 library==		==DS1961 library==
	This library provides an API for the DS1961 specific functions.		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 1-~~wire library~~.		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==		==Application==
Regel 91:		Regel 70:
	The following protocol extension for communication with the Arduino is proposed.		The following protocol extension for communication with the Arduino is proposed.

	On the Arduino side, the following command/response is added:		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		* an extra command to send the 3-byte '''C'''hallenge (in hex-ascii), example
	<pre>C AB34EF</pre>		<pre>C AB34EF</pre>
	* a corresponding ~~'''R'''esponse~~ to return the 32-byte data and the 20-byte hash, example		* a corresponding response to return the 32-byte data and the 20-byte hash, example
	<pre>R 0000000000000000000000000000000000000000000000000000000000000000 D54A4731DC5EDF675D7B0A23A6D83534FAE12E3F</pre>		<pre>C 0000000000000000000000000000000000000000000000000000000000000000 D54A4731DC5EDF675D7B0A23A6D83534FAE12E3F</pre>
	TODO: what to respond if communication with the ibutton fails somehow?		TODO: what to respond if communication with the ibutton fails somehow?

Bertrik Sikken op 13 jan 2013 om 22:18

2013-01-13T22:18:54Z

← Oudere versie		Versie van 13 jan 2013 22:18
Regel 5:		Regel 5:
	}}		}}

			<!--
	[https://revspace.nl/mediawiki/index.php?title=SecureIButton&action=purge purge cache]		[https://revspace.nl/mediawiki/index.php?title=SecureIButton&action=purge purge cache]

Regel 12:		Regel 13:
	\| ?Tagline		\| ?Tagline
	}}		}}
			-->

	This project is about investigating and using the secure features of the iButton that people currently use for physical access to RevSpace.		This project is about investigating and using the secure features of the iButton that people currently use for physical access to RevSpace.
Regel 84:		Regel 86:
	* how advanced do we make the authentication scheme / how is key management handled?		* 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.		** 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)		** 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)
	** ~~More advanced~~: ~~master~~ secret ~~is re~~-~~newed every X time~~, ~~so we have multiple versions of~~ the ~~master secret (e.g. renewed each year)~~
			===Concrete proposal===
			The following protocol extension for communication with the Arduino is proposed.

			On the Arduino side, the following command/response is added:
			* an extra command to send the 3-byte '''C'''hallenge (in hex-ascii), example
			<pre>C AB34EF</pre>
			* a corresponding '''R'''esponse to return the 32-byte data and the 20-byte hash, example
			<pre>R 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==		==External Links==
	[http://www.maximintegrated.com/products/ibutton/software/1wire/wirekit.cfm Maxim iButton 1-wire public domain kit]		[http://www.maximintegrated.com/products/ibutton/software/1wire/wirekit.cfm Maxim iButton 1-wire public domain kit]