Encrypted bootloader on Arduino

Has anyone ever tried an encrypted bootloader on an Arduino, such as the Atmel AVR230 or AVR231?

The idea being that lock bits prevent code from being read from the AVR, but if a hex file is put up for download publicly it could be deciphered. An encrypted bootloader contains a set of decryption keys that are able to decrypt an encrypted hex file that is uploaded to the device, thus protecting the code as it changes hands.

I've read through the Atmel documents on the DES and AES encrypted bootloaders...seems complicated, at least when you compare it to normal Arduino programming. :fearful:

DES and AES encrypted bootloaders...seems complicated

I would hope so! I have used the lock bit once, I was using AVR dude and set the fuses wrong :fearful:

I suspect that many of our members that are involved in commercial AVR products do use the lock-bit, but I suspect any use of encryption/decryption is probably only applicable to the Digital Rights folks and that would not be, typically, in the bootloader but rather in the runtime code. Commercial uses of the AVR generally will not contain a bootloader; rather if code changes are required, ISP will be utilized (or chip-swap.) This may be changing slowly however as more devices are Internet connected and the concept of code updating of thousands of devices become thinkable. It was not too long ago that the idea of updating a smartphone Over-The-Air would have been considered insane! Now, it is done all the time.

Ray

mrburnette:

DES and AES encrypted bootloaders...seems complicated

I would hope so! I have used the lock bit once, I was using AVR dude and set the fuses wrong :fearful:

I suspect that many of our members that are involved in commercial AVR products do use the lock-bit, but I suspect any use of encryption/decryption is probably only applicable to the Digital Rights folks and that would not be, typically, in the bootloader but rather in the runtime code. Commercial uses of the AVR generally will not contain a bootloader; rather if code changes are required, ISP will be utilized (or chip-swap.) This may be changing slowly however as more devices are Internet connected and the concept of code updating of thousands of devices become thinkable. It was not too long ago that the idea of updating a smartphone Over-The-Air would have been considered insane! Now, it is done all the time.

Ray

More so considering an consumer scenario where a firmware update is provided for a device. The user downloads the .hex file (encrypted), and connects their device via USB (AtMega8 or 16 USB to serial) and via the bootloader installs the update. The encrypted bootloader then decrypts the firmware with the decryption keys. Providing an unencrypted .hex file for public download could result in reverse engineering and firmware hacks.

AFAIK, no one has done this. It's a bit contrary to the open source nature of Arduino.

The big problem is that you have a key management problem. You would have to provide chips containing the bootloader (with keys) (at which point, maybe you should just provide chips containing protected code, rather than downloads.) Or you'd have to invent some other way to enter keys for the bootloader to use, and make sure that THOSE don't fall into "the wrong hands."

It seems to be a lot of trouble. If reports are correct, there are places that will read the hex from a chip (even if protected) for a couple hundred bucks. So if someone is determined to get your code, they will anyway.