HCS08 Bootloader with encryption

[ttom]

Hello,

our customer wants me to implement a bootloader on our HCS08SG16 via SCI and with encryption. Are there any libraries to do the decryption on the target? I did not find any information for the 8bit - Microcontrollers.

The encryption method is not defined - but it should not be the easiest method to break.

I want to take the doonstack - routines to do the erase and write access to the flash - this works already.

I think AES or DES or 3DES - encryption would be nice, but I did not find any hints according to this for my microcontroller - family.

Does somebody has an idea or a link for me?

Many thanks (and have a nice weekend)

Thomas

[tonyp]

You're using a 16KB device.  If you use most of the program space for storing the decryption code (by picking one of the more involved encryption algorithms), you've lost the game.  Furthermore, if you plan to squeeze all that by writing it in C, you've lost once more.  But if your application is small enough that it will fit, regardless, then it's probably not worth encrypting too much.

I think you can be more effective if you make your own tiny encryption scheme that will be 'secure enough' for the purpose of protecting the firmware from being cloned.

The whole idea with encryption is to attempt to make the cloning effort more expensive than the cost of writing the firmware from scratch.  For example, if your application is easily reproduced (because the firmware and the how-to is relatively simple), there is no point in using the best encryption money can buy.  On the other hand, if it's the gadget of the century but which also happens to use proprietary computations, or whatever know-how not easily derived by observing the gadget's function, then by all means, use the best you can (but I would still add a personal touch to the method because all publicly known algorithms are the ones someone will attempt to break first).

As I've already mentioned in other similar posts, you can also add CRC protection to prevent 'foreign' code from being loaded/executed in your device, and making the core of the stable library/OS functions a part of the bootloader, so that the distributable application is never even close enough to doing the job by itself, in case encryption is compromised.  Also, any proprietary methods could be inside the bootloader (provided they won't ever be updated.)

[rocco]

I agree with Tony. Using a standard secret-key style encryption is going to be pretty heavy. You may need to ask your customer if they wish to spring for a mcu with more flash to accommodate it.

Or you can do something lightweight and proprietary. Some simple methods to consider:

1) Send the program-data without addresses, and load them in an order defined by pre-rearranging the address bits. This would need to be done in two stages: First, scramble the page order, then scramble the addresses within the page. The scrambling order could also be embedded in the data stream.

2) Invert bits in each byte, either with a fixed XOR value, or with a changing XOR value. The XOR value could be embedded in the data stream, say, once per every 47 bytes. Or a variable number of bytes, embedded in the stream with the XOR value.

3) Throw in checksum or CRC bytes at (fixed or variable) intervals within the data stream. With this, you could detect attempts to bypass security, and possibly self-destruct. Or just use it to detect communication errors.

There are plenty of other non-intuitive and low cost methods you could come up with, and most firmware thieves wouldn't have a clue where to start.

mark

[ttom]

Hello,

thank you for your answers.

I come from the ATMEL(ATMega) - world.

For ATMEL, there is a AES Bootloader, which fits into 2 k Flash. When I have a controller running at 3,69 MHz, and I want to update 64k Application with AES (with 256bit key) via 115k2 UART, this action lasts 33 seconds. I know, this is a long time, but a deep encryption, too.

So I thought, that there is a similar bootloader available for freescales. In my 16k - Device, my application needs about 12 k, so about 4k are available.

According to your explanations, I have to consider about the security. I would prefer real encryption. But it seems I have to do my security in a way you wrote.

I have to do some more thoughts and will call back here when I have a good idea,

have a nice weekend and many thanks for your replies,

Thomas

[tonyp]

If you have access to the source code of that bootloader, why not try to port it to 9S08?

Judging by the size of it, I suspect (but I could be wrong, of course) that there is a PC-side app that talks to the bootloader.  And, the AES decryption is most-likely done on the PC side.  If that's the case, then the whole scheme is flawed.

If, however, you believe the 2K bootloader (of which about 0.5K-1K is the comms and Flash programming code) is the one that actually does the complete decryption job, it'd be nice to try to port it to 9S08.  If you post the source code (or a link to it), I think some of us might volunteer for the task.  And, how much RAM does it need?

[ttom]

Hello,

I will try to port it. I thought, there is already a implementation for that - this was the reason I asked here.

Only for information:

The according Application note at the ATMEL site is:

http://www.atmel.com/dyn/resources/prod_documents/doc2541.pdf (documentation)

http://www.atmel.com/dyn/resources/prod_documents/AVR231.zip (sources)

Thomas

[rere]

try TEA(tiny encpytion A) if your using assembly maybe around less than 1k . and i think motorola has some application note on it, or it was TI. with complete doc and source code i think its the only possible thing to implement on 8-bit, special on bootloader.