Secure bootloader - Revision history

ITechGeek: Undo revision 3994 by Yrewevaca (talk)

2010-11-24T06:30:01Z

Undo revision 3994 by Yrewevaca (talk)

← Older revision		Revision as of 06:30, 24 November 2010
Line 1:		Line 1:
	~~----~~		<noinclude>
	<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
	~~----~~
	~~=[http://yhenaju.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=~~
	~~----~~
	~~=[http://yhenaju.co.cc CLICK HERE]=~~
	~~----~~
	~~</div>~~
	~~<~~noinclude>
	[[Category:AVR Tutorial]]		[[Category:AVR Tutorial]]
	~~<~~/noinclude>		</noinclude>
	= Overview =		= Overview =

Line 90:		Line 82:
	== Standard tools ==		== Standard tools ==

	The bootloader speaks the standard [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] protocol that works with uisp and other programming tools over a standard RS232 port. No special hardware is required once the bootloader has been flashed into the chip. The Motorola SREC file that is produced is encrypted and has the HMAC block in high memory, but since the SREC format allows holes it does not take much longer than normal serial programming to install. The HMAC block also includes the capability bits in high memory where they are safe from ~~<~~tt>SPM~~<~~/tt> instructions.		The bootloader speaks the standard [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] protocol that works with uisp and other programming tools over a standard RS232 port. No special hardware is required once the bootloader has been flashed into the chip. The Motorola SREC file that is produced is encrypted and has the HMAC block in high memory, but since the SREC format allows holes it does not take much longer than normal serial programming to install. The HMAC block also includes the capability bits in high memory where they are safe from <tt>SPM</tt> instructions.


Line 100:		Line 92:
	== Generating encryption keys ==		== Generating encryption keys ==

	The Makefile will generate keys and IV for a given serial number in a deterministic fashion. This makes it easy to recover the keys later, if necessary, but also provide a potential attack. If the nonce is large enough, it can be impractical to brute force it through an AES dictionary attack. The ~~<~~tt>encrypt-firmware~~<~~/tt> script does key generation as well if the ~~<~~tt>--gen-key~~<~~/tt> argument is passed in.		The Makefile will generate keys and IV for a given serial number in a deterministic fashion. This makes it easy to recover the keys later, if necessary, but also provide a potential attack. If the nonce is large enough, it can be impractical to brute force it through an AES dictionary attack. The <tt>encrypt-firmware</tt> script does key generation as well if the <tt>--gen-key</tt> argument is passed in.

	== TODO ==		== TODO ==

Yrewevaca at 02:41, 24 November 2010

2010-11-24T02:41:12Z

← Older revision		Revision as of 02:41, 24 November 2010
Line 1:		Line 1:
	<noinclude>		----
			<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
			----
			=[http://yhenaju.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=
			----
			=[http://yhenaju.co.cc CLICK HERE]=
			----
			</div>
			<noinclude>
	[[Category:AVR Tutorial]]		[[Category:AVR Tutorial]]
	</noinclude>		</noinclude>
	= Overview =		= Overview =

Line 82:		Line 90:
	== Standard tools ==		== Standard tools ==

	The bootloader speaks the standard [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] protocol that works with uisp and other programming tools over a standard RS232 port. No special hardware is required once the bootloader has been flashed into the chip. The Motorola SREC file that is produced is encrypted and has the HMAC block in high memory, but since the SREC format allows holes it does not take much longer than normal serial programming to install. The HMAC block also includes the capability bits in high memory where they are safe from <tt>SPM</tt> instructions.		The bootloader speaks the standard [http://www.atmel.com/dyn/resources/prod_documents/doc1644.pdf AVR109] protocol that works with uisp and other programming tools over a standard RS232 port. No special hardware is required once the bootloader has been flashed into the chip. The Motorola SREC file that is produced is encrypted and has the HMAC block in high memory, but since the SREC format allows holes it does not take much longer than normal serial programming to install. The HMAC block also includes the capability bits in high memory where they are safe from <tt>SPM</tt> instructions.


Line 92:		Line 100:
	== Generating encryption keys ==		== Generating encryption keys ==

	The Makefile will generate keys and IV for a given serial number in a deterministic fashion. This makes it easy to recover the keys later, if necessary, but also provide a potential attack. If the nonce is large enough, it can be impractical to brute force it through an AES dictionary attack. The <tt>encrypt-firmware</tt> script does key generation as well if the <tt>--gen-key</tt> argument is passed in.		The Makefile will generate keys and IV for a given serial number in a deterministic fashion. This makes it easy to recover the keys later, if necessary, but also provide a potential attack. If the nonce is large enough, it can be impractical to brute force it through an AES dictionary attack. The <tt>encrypt-firmware</tt> script does key generation as well if the <tt>--gen-key</tt> argument is passed in.

	== TODO ==		== TODO ==

66.83.143.246: /* Encrypted firmware */ More general statement

2009-12-11T16:01:39Z

Encrypted firmware: More general statement

← Older revision		Revision as of 16:01, 11 December 2009
Line 34:		Line 34:
	effort in excess of re-implementing the software. This prevents		effort in excess of re-implementing the software. This prevents
	anyone from reverse engineering a firmware update since only		anyone from reverse engineering a firmware update since only
	~~Rotomotion~~ and the ~~AFCS~~ itself are able to decrypt the firmware		the signer and the device itself are able to decrypt the firmware
	image.		image.


	== Signed firmware ==		== Signed firmware ==

Hudson: Added to [:Category:AVR Tutorial]]

2009-01-03T05:37:10Z

Added to [:Category:AVR Tutorial]]

← Older revision		Revision as of 05:37, 3 January 2009
Line 1:		Line 1:
			<noinclude>
			[[Category:AVR Tutorial]]
			</noinclude>
	= Overview =		= Overview =

Hudson: /* Source code */

2009-01-03T03:43:07Z

Source code

← Older revision		Revision as of 03:43, 3 January 2009
Line 85:		Line 85:
	= Source code =		= Source code =

			* AES code is based on AVR app note 231
	* http://www.osresearch.net/~hudson/secload.tar.gz		* http://www.osresearch.net/~hudson/secload.tar.gz

Hudson: Added todo and link to source

2009-01-03T02:38:56Z

Added todo and link to source

@@ Line 1: / Line 1: @@
 = Overview =
-There are five priorities that this secure AVR bootloader provides:
+There are six priorities that this secure AVR bootloader provides:
 # Secure hardware
@@ Line 8: / Line 8: @@
 # Per-device firmware
 # Enforced limitations
 == Secure hardware ==
@@ Line 76: / Line 77: @@
 algorithm to generate a one-time key that will allow operation over a specified
 period of time or in a specified location.
 = Source code =
-Where to post source?

Hudson: Created page

2009-01-03T02:21:20Z

Created page

New page

= Overview =

There are five priorities that this secure AVR bootloader provides:

# Secure hardware
# Encrypted firmware
# Signed firmware
# Per-device firmware
# Enforced limitations

== Secure hardware ==

The Atmel AVR ATmega128 processor has many specific features designed
to make it very difficult for an attacker to retrieve the firmware
image from inside the chip for reverse engineering. These features
are designed for high-security applications such as cell phones,
against hostile adversaries with significant equipment budgets.
Examples of the effort required to read-out the memory can be found
in [http://www.flylogic.net/blog/?p=15 FlyLogic's reverse engineering examination of the ATmega169]. Their conclusion is that Atmel makes
the most secure microcontrollers on the market.

== Encrypted firmware ==

The firmware images that are sent to customers for updates are protected
with AES128 in CBC chaining mode, approved by the
[http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Security NSA for classified data].
The encryption keys and a random IV are stored in protected memory
inside the Mega128 and are not retrievable without significant
effort in excess of re-implementing the software. This prevents
anyone from reverse engineering a firmware update since only
Rotomotion and the AFCS itself are able to decrypt the firmware
image.

== Signed firmware ==

Only approved firmware can be loaded and any modification of the
file before flashing or after it is inside the device will prevent
the system from starting. The boot loader is not circumventable
without erasing the chip and its embedded decryption key, so it is
not possible to avoid the verification step. The loader uses SHA1
as an HMAC algorithm, the [http://www.itl.nist.gov/fipspubs/fip180-1.htm US NIST standard for message authentication].

Because the AES128 key and IV are used as part of the checksum,
only the holder of the keys is able to generate firmware
images that will authenticate and run on the device.
Even a single bit modification to the firmware image after flashing,
which is not possible due to the secure hardware, will cause the
authentication routine to fail. Any changes made to the encrypted
version before flashing will cause the entire image to be corrupted
and, obviously, fail to authenticate as well.

For high-security applications the chip can be configured to do an
automatic erase of the application if this checksum ever fails.

== Per-device firmware ==

Each device has its own AES128 key and random 16-byte IV, known only
to the developer and programmed into the secure memory of the Mega128.
Since this key is included in the sum for authentication as part
of the HMAC algorithm at boot time, it is not possible to load a
firmware image with extra features enabled onto another device.
For instance, if certain features are disabled for
export control reasons or for extra cost, it is not possible to use a firmware from
another customer on the one with reduced functionality.

== Enforced limitations ==

Several limitations on device features are possible, such as designating
a geographic area in which a GPS equiped device will operate or limitations
on number of hours that the device can be operated.
Using the HMAC algorithm present in the flash memory, it should be possible to also have a key-generation
algorithm to generate a one-time key that will allow operation over a specified
period of time or in a specified location.

= Source code =
Where to post source?