Posted on May 17, 2011 at 14:11It’s easy enough to encrypt a file on your development system. Your encryption may need to avoid encrypting “little things�? like load address and length.
The bootloader should always decrypt before writing flash. The decryption algorithm / key has to be part of the bootloader. An alternative: use an unmodified bootloader. Then decrypt the recently downloaded flash in place. (Be sure to have a flag telling your startup code when decryption is needed.)
Be careful if you use the alternative. A smart code breaker could download simple code that outputs the entire flash.
The above assumes that the decryption code will not have to be updated. But given enough flash new encryption code could be loaded and then when decrypted used to reflash the decryption code.
Whatever you do be sure to understand all flash protection options. Then weigh complexity vs. security. Simple obfuscation may be enough. I.e. complement each 32-bit word then rotate 3 bits. If you need AES-level protection be sure to protect your key and have serious cryptographic AND procedural analysis of your entire update process. Think like a determined attacker.
I am currently dealing with a related but much simpler problem in the 8-bit world. Microcontroller is a 40-pin DIP. Code protection bits prevent read back. Updates are shipped with a whole new microcontroller. It costs more to mail the new processor than it costs. (Customer base is very low tech.)
My concern is wholesale code reproduction. Over half of the development cost is in the code. A competent machine shop could reproduce the hardware. A junior EE could reproduce the PCB.
