How can a bootloader be protected from user applications?

[kai_liu]

Actually it is not A questions, but a series of questions.

I have a bootloader to support user application reloading. In order to support commercial license, I am considering use UID as seed for certain authentication functions in the bootloader.

Here comes the problem, if I embed the  authentication functions inside the bootloader, I have to protect my bootloader from user applications.

How to protect my bootloader? It is quite easy to read all the contents from ROM if it supports user application reloading. A simple hacker code can be reloaded and print out all ROM code to external terminal.

In my mind, some ROM region should be protected from reading. Where is the implemeation detail for KL and K?

And if so, can a user application access call ROM functions in bootloader when it is in secure situation? If not, how to call the authentication function anyway? By copying these functions to RAM?

[mjbcswitzerland · Accepted solution]

Hi

I think that the typical method is to set secure mode in the Flash configuration (flash security register - unsecure bit set to '0') which protects all flash accesses from JTAG or EZPORT without first performing a mass erase (which also destroys all information that was in flash and so protects all content).

If you divide the SW into boot software and application each can access all flash memory and so you can call boot functions from the application without any restrictions.

The boot loader must not allow rogue applications to be loaded since these could then read out internal flash. This means that the boot loader that you use should also support authentication so that foreign applications can't be loaded. It would usually also support encyrption so that you can distribute new application software without it being reverse engineeded (either to obtain the application code or to obtain authentication information).

The uTasker boot loaders support optional authentication and encyrption in some configurations. The one that I have often used is the one described here (together with flash security) : http://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf

Regards

Mark

P.S. There are some access options that can be set in the flash memeory controller but these are not protected against manipulation from a rogue program, thus are not fully secure.

Once I had a situation where I could run code from the Flash but the processor couldn't 'read' the content of code - a bus error was generated. This suggests that it is possible to allow the procesor to read instructions from flash but not the program to read the content of the flash (normal read access and not instruction load access). This happened once when debugging and I couldn't repeat it so I didn't see exactly what setting (possibly corrupted once) was affecting it...so don't know whether it may be possible to use such a setting (if the setting is also secured) to benefit such a requirement.

[kai_liu]

Thanks, Mark.

Very useful & helpful information. I raised such question since some other vendors do offer some "secure" ARM to protect being read by rogue code. Maybe NXP's ARM7? Or code running from external flash can not access internal flash.  I can not recall it very clearly.

Now I got the idea from you that the user application SHOULD BE authenticated before loading into internal memory. Otherwise it can be hacked very easily.

Yours sincerely

Allan K Liu

[mjbcswitzerland]

Hi Allan

Most modern devices have good flash protection (mainly to protect IP) - the Coldfire and Kinetis solution is good as long as only internal memory is used or course.

In fact I have developed EMV compliant credit card terminals (HW and SW) using older NXP ARM7 devices which have no protection and ISP, which allows all content to be read. The device had to be physically protected in that case since also security keys stored in RAM have to be protected against an attack - the actual program in memory is not a big issue since it is useless without the keys or cerificates that are primed in protected (volatile) memory, but it would have been nicer to also protect that.

But that sort of protection is rather different from 'basic' IP protection because the incentives are very different (the rewards to stealing secret keys from POS terminals are potentially much higher) so physical protection is critical (see for example the DryIce module in the Kinetis K70 which works with such systems). The requirements are that critical information is stored only in volatile memory which is immediately and irreversibly destroyed when a tamper is detected, including

- unexpected temperature changes (big time thieves will shock cool the electronics to stop oscillators working and freezing SW states, hoping to also get by active software protection mechanisms)

- physical entrance to the internal parts of the module (drilling with extremely thin bits need to be detected otherwise they may be able to hook up a contact on a data line that gives away information)

- overvoltages attempting to destroy specific protection circuits must knock out the sensitive information first,

and such theives will probably still get to data in flash anyway by micro-grinding into the package to expose the flash die and connect directly....

Regards

Mark

[kai_liu]

Thanks, Mark. It is really nice to discuss with you.

Now I found its description from NXP's datasheet. The so-called CRP feature actually is protected flash memory to be read via ISP and JTAG, not reloaded user applications.

As a conclusion, the user application has to be authenticated and authorized BEFORE loading. The system has to be a protected environment like COS or Java VM.

If I want to authenticated an user application in MSC device bootloader, then the user application has to embed a random seed, encrpted key in hex code, since I can not embedded extra mutal authentication algorithm in USB transactions. Especially there is no way to authente bootloader in reverse direction.

The other bootloaders like UART/VCP/CDC, DFU, CAN, Eithernet, may introduce mutual authenticaion in bootloader. The MSC host can not either.

If I deploy a 'secure' bootloader, then I can not deploy open source (lite or demo) version in same hardware. It will by hacked anyway. Unless I issue license for them as well.

At last, thanks for your information for hacking. :smileyhappy:  In my preivous experience of promoting RFID/ICC, I did meet some people who is working on reverse engineering projects and their "products". It is dangerous to push silicon to extreme conditions sometime, but interesting though.

[mjbcswitzerland]

Hi

I think that adding authentication to a binary file to be loaded by MSC is a matter of adding a hash to it (eg. added as a fixed header to the start of the binary, with length information). The loader must check that the hash matches the content before it starts the application - if it doesn't it is compromised and so it refuses to start it or deletes it.

The loader will need to check each time it runs (short start delay).

The hash algorithms are typically taken from OpenSSL or similar. Open source security software gives good security as long as used correctly.

Regards

Mark