9 Summary

This application note has presented a method for transferring data securely to an AVR microcontroller with bootloader capabilities. This document has also highlighted techniques that should be implemented when building a secured system. The following issues should be considered in order to increase the security of an AVR design.

Implement a bootloader that supports downloading in encrypted form. When the bootloader is first installed (during manufacturing) it must be equipped with decryption keys, required for future firmware updates. The firmware can then be distributed in an encrypted form, securing the contents from outsiders.

Use AVR lock bits to secure Application and Boot Loader sections. When lock bits are set to prevent reading from the device, the memory contents cannot be retrieved. If lock bits are not set, there is no use encrypting the firmware.

Encrypt the firmware before distribution. Encrypted software is worthless to any outside the entity without the proper decryption keys.

Keep encryption keys safe. Encryption keys should be stored in two places only: in the bootloader, which has been secured by lock bits, and in the firmware development bench at the manufacturer.

Chain encrypt data. When data is chained, each encrypted block depends on the previous block. As a consequence, equal plaintext blocks produce different encrypted outputs.

Avoid standard, predictable patterns in the firmware. Most programs have a common framework and any predictable patterns, such as an interrupt vector table starting with a jump to a low address, only serve to help the intruder. Also, avoid padding unused memory areas with a constant number.

Hide the method. There is no need to mention which algorithm is being used or what the key length is. The less the intruder knows about the system, the better. It may be argued that knowing the encryption method fends off some attackers, but knowing nothing about the method increases the effort and may fend off even more.

The bootloader may also be used to erase the application section, if required. Many attack attempts include removing the device from its normal working environment and powering it up in a hacking bench. Detecting, for example, that an LCD is missing or that there are CRC errors in the memory, the bootloader may initiate a complete erase of all memory (including the bootloader section and decryption keys).

In applications where it is not feasible or possible to use an external communications channel for updates, the firmware can be stored in one of the CryptoMemory® devices. The memory can be packaged as a removable smart card, which can easily be inserted in a slot of the device when an upgrade is needed. The microcontroller can check for the presence of a CryptoMemory upon start-up and retrieve a firmware upgrade as needed.

Use secure hardware. A strong encryption protocol is useless if the hardware has structural flaws. There are no reported security issues with the AVR microcontrollers.

This list can be made much longer but the purpose of it is merely to set the designer off in the right direction. Do not underestimate the wit or endurance of your opponent.