1 Description

Electronic designs with microcontrollers always need to be equipped with firmware, be it a portable music player, a hairdryer, or a sewing machine. As many electronic designs evolve rapidly there is a growing need for being able to update products that have already been shipped or sold. It may prove difficult to make changes to hardware, especially if the product has already reached the end customer, but the firmware can easily be updated on products based on Flash microcontrollers, such as the AVR. Many AVR microcontrollers are configured such that it is possible to implement a bootloader able to receive firmware updates and to reprogram the Flash memory on demand. The program memory space is divided in two sections; the Bootloader Section (BLS) and the Application Section. Both sections have dedicated lock bits for read and write protection so that the bootloader code can be secured in the BLS while still being able to update the code in the application area. Hence, the update algorithm in the BLS can easily be secured against outside access.

The problem remains with the firmware, which typically is not secure before it has been programmed into Flash memory and lock bits have been set. This means that if the firmware needs to be updated in the field, it will be open for unauthorized access from the moment it leaves the programming bench or manufacturer’s premises.

This application note shows how data to be transferred to Flash and EEPROM memories can be secured at all times by using cryptographic methods. The idea is to encrypt the data before it leaves the programming bench and decrypts it only after it has been downloaded to the target AVR. This procedure does not prevent unauthorized copying of the firmware, but the encrypted information is virtually useless without the proper decryption keys. Decryption keys are stored in only one location outside the programming environment - inside the AVR. The keys cannot be regenerated from the encrypted data. The only way to gain access to the data is by using the proper keys.

The following figure shows an example of how a product is first manufactured, loaded with initial firmware, sold, and later updated with a new revision of the firmware.

Figure 1-1. An Example of the Typical Production and Update Procedure
Note:
  1. During manufacturing, the microcontroller is first equipped with a bootloader, decryption keys, and application firmware. The bootloader takes care of receiving the actual application and programming it into Flash memory, while keys are required for decrypting the incoming data. Lock bits are set to secure the firmware inside the AVR.
  2. The product is then shipped to a distributor or sold to the end customer. Lock bit settings continue to keep the firmware secured inside the AVR.
  3. A new release of the firmware is completed and there is a need to update products, which already have been distributed. The firmware is therefore encrypted and shipped to the distributor. The encrypted firmware is useless without decryption keys and therefore even local copies of the software (for example, on the hard drive of the distributor) do not pose a security hazard.
  4. The distributor upgrades all units in stock and those returned by customers (for example, during repairs). The encrypted firmware is downloaded to the AVR and decrypted once inside the microcontroller. Lock bit settings continue to keep the updated firmware secured inside the AVR.