We are in need of a bootloader that can be "locked&q...

[Skippy]

We are in need of a bootloader that can be "locked" into FLASH on a 9S08AW60.  Plan is to use it to upload application revisions to deployed equipment.  Really don't want to re-invent the wheel - something simple sort of like SWTBUG.  AN-2295 is interesting but seems a bit overkill-ish. Just polling for comments at this point - getting a few design ideas.  Anyone willing to share their experiences / findings? 

[tonyp]

Something simple?  If this is for a commercial product, I think you would be interested in security against copying.  A very simple bootloader means that with each firmware update you give out the whole application in a way that it may be easily cloned.

Encryption is one method of protecting your app.  But it alone may not be enough.

I go one step further by making the 'bootloader' app include the whole OS (if you don't use an OS, replace the term with 'commonly used library functions').  This is well-tested code proven over time that is very unlikely to require modifications, and even if a bug is found after deployment, it can be worked-around in the application itself.  It also allows the device to be upgradeable in a more professional way (e.g., over the Internet for network-enabled devices) that the simple bootloader with limited code resources could not provide.

This method means the application file given out is always far less than the complete code needed to run it.  The bootloader is always loaded at the factory and the MCU's internal security protects it from being cloned.

Possible firmware updates are always small, encrypted, and never complete apps that someone may clone in the unlikely yet possible event encryption is broken.

I should also point out that if encyption is broken, someone could write a small app to copy your bootloader off your device, getting access to your complete app code.  If you need to protect against this possibility, make sure you add some proprietary CRC checking while loading the firmware file so that 'foreign' files won't be accepted.


Message Edited by tonyp on 2008-11-15 12:22 PM

[Skippy · Accepted solution]

Certainly we're interested in security. I was fishing for an answer to see if someone had already written something that could be used in the design.  No sense re-inventing the wheel for every requirement.

Without going too deeply into detail, the plan is to immediately apply encryption, by means of a seperate appl, at the point where the compiler/assembler finishes.The encrypted file will then be burnt to CD/DVD, emailed or ftp'd to the end user who will use the proprietary gui to "load" the encrypted file to the embedded application over a proprietary comm channel.  At that point the file will be decrypted and programmed into FLASH.  I believe that will provide adequate protection to keep honest folks honest.  

Your idea of placing the core parts of the OS in the bootloader makes perfect sense and we used that method on previoius designs which allowed, as you noted, portions of the underlying code body to be revised and updated.

CRC-nn is already in use.  Checks the executable at power up and at timed intervals thoughout execution. Any mis-matches and the appl is shutdown, the code attempts to emit a message to the gui and if the gui does not answer properly and promptly the application is erased from FLASH.