Secure bootloader
From HacDC Wiki
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 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 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 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?