KL17 Security - Please Confirm my thoughts

[JHinkle]

I'm developing a KL17 application that is going to be manufactured at a suppliers location.

The initial code to be flashed into the device by the supplier will be a combination of a bootloader and manufacturing test program.

The intent is to have the bootloader security open as it leaves the supplier.

When the boards arrive into our facility we want to load the "real application", secure the device, and enable a backdoor key.  Since the FSEC is programmed to 0xfe by the supplier, the 1K flash block that holds the backdoor key and other security and flash related fields has to be erased and reprogrammed ... Is THAT a correct understanding.

As long as the bootloader code does NOT start in that 1K sector, I should be able to update my security information without affecting the bootloader code (just wasting 1K of flash to make this option possible).

Is my understanding correct?

Thanks.

Joe

[JHinkle]

Mark:

You are correct.

After sleeping on it, my old fart brain realized that internally I did not need keys to perform a reflash -- they are there to protect outside access.

Thanks for keeping up with my question.

Joe

[mjbcswitzerland]

Joe

In fact (to round off) if one were to start with the first 8 bytes of the Flash configuration at 0xffffffffffffffff it would be possible to overwrite them once without needing to erase the sector - therefore it would be possible to start with these as initial backdoor keys (and block protection) and later change them once (valid for long word and phrase programming - therefore generic for all parts).

Regards

Mark

[mjbcswitzerland]

Joe

Your initial boot loader always occupies the first sector of Flash (due to its reset vector). It also defines the security (which will be left unprotected initially).

To change the security you need to erase (at least) the first sector and reprogram (at least) the reset vectors plus the new security setting.

There is no advantage of avoiding the first sector with the rest of the boot loader code since it has to update at least 'a part' of itself anyway and if there is a reset/power cycle at that point the board will no longer be operational (without reloading with debugger).

I have added the method that I have used in several products where the boot loader has needed to be exchanged in the field (and which can be used to lock the device if the new boot loader code sets the appropriate flash configuration value). It uses the uTasker Flash programming interface (which can be replaced by whatever ones you are using) and integrates the new boot loader code by including it as an array in a header file called serialArray.h (to create such an array the utility uTaskerFileCreate can be used: uTasker Utilities ).

This code is put into an application (your normal application can always include the latest boot loader version and update whenever necessary) that is loaded using your original loader. It can be called to check that the boot loader is up-to-date (when it does nothing) or to update a new version whenever needed. If you look carefully the flash configuration is programmed as priority as soon as the first sector has been erased.

Regards

Mark

P.S. Note also that you can immediately set the security in the first boot loader since it doesn't restrict the reprogramming of future applications and boot loaders anyway.

P.P.S. The fnUpdateSerialLoader() can also be added to an application at any time since it doesn't need to be foreseen at the outset.

Kinetis for professionals: http://http://www.utasker.com/kinetis.html

#include "serialArray.h"

static void fnUpdateSerialLoader(void)
{
    if (memcmp(serial_loader, fnGetFlashAdd((unsigned char *)0x00000000), sizeof(serial_loader)) != 0) { // if the loader in Flash is different to the one embedded in code
        unsigned char *ptrFlashDestination;
        unsigned char *ptrSerialLoader = serial_loader;
        if (memcmp(serial_loader, fnGetFlashAdd((unsigned char *)0x00000000), _FLASH_GRANULARITY) != 0) { // check whether the first sector requires modifying
            _fnEraseFlashSector((unsigned char *)0, _FLASH_GRANULARITY);  // delete first sector
            _fnWriteBytesFlash((unsigned char *)0x400, &serial_loader[0x400], 16); // program critical flash configuration
            _fnWriteBytesFlash((unsigned char *)0, &serial_loader[0], 0x400); // program start
            _fnWriteBytesFlash((unsigned char *)0x410, &serial_loader[0x410], (_FLASH_GRANULARITY - 0x410)); // program end
        }
        ptrFlashDestination = (unsigned char *)_FLASH_GRANULARITY;
        ptrSerialLoader += _FLASH_GRANULARITY;                           // after critical first sector has been programmed continue with the rest
        while (ptrFlashDestination < (unsigned char *)(32 * 1024)) {     // for each sector in the serial loader area
            _fnEraseFlashSector(ptrFlashDestination, _FLASH_GRANULARITY);// erase all boot loader sectors
            _fnWriteBytesFlash(ptrFlashDestination, ptrSerialLoader, _FLASH_GRANULARITY); // program sector
            ptrSerialLoader += _FLASH_GRANULARITY;
            ptrFlashDestination += _FLASH_GRANULARITY;
        }
    }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[JHinkle]

Mark:

Your comments are correct for sector sizes greater than 1K.  The Vectors occupy the first 1K and then the security/protection bytes start at the second 1K boundry.

The sector size for a KL17 is 1K in size ... So I could just not place code in the second sector and reflash it alone.

On my K64 application, I have to deal with a 4K sector which will encompass the vector table.

My thoughts are to copy the first sector to ram, modify the security bytes as required and the reprogram the sector again -- all from RAM.

[mjbcswitzerland]

Joe

You are right - I used the code for two K parts (which can have 2k or 4k granularity).

KLs have 1k and KE/KEAs have 512 byte granularity so you are rights that it would be possible to program just the second (in KL) or third (in KE/KEA) to modify the flash configuration.

It is generally possible to do this also by copying the original content to SRAM, erasing and then re-programming (with just the Flash config settings modified). If you run the swap code from SRAM you also don't need to keep the sector free of any other code.

The only thing to be aware of is the slight risk that if there is a reset or power failure before the new Flash configration values have been programmed your device will be locked (recoverable) and possibly other behavior is changed (like internal bo loader activated, NMI line enabled, etc.) which may or may not cause a problem.
the advantage of keeping this sector free of other boot code is that such a faire may still leave the orignal loader operational. even if the chip is secured.

If you have a selection of devices I would tend to to go for a single compatible solution (K64 couldn't erase just the flash config as you know). To make the code that I have used device independent I would need to change the first three uses of _FLASH_GRANULARITY to a suitable value for the chip in question, or to the fixed value of 4k to be type independent.

Regards

Mark

[JHinkle]

I keep getting the feeling you have tried to convey to me a way of updating sector 1 (or more) without fear or loosing power or a reset.

If that is so --- I apologize for not grasping what you have stated.

Right now I see multiple ways of updating the complete bootloader or the first sector but all have the terrible failure mode if power is removed or reset occurs before the reflash is complete.

 If you have a way around that fault condition, please attempt to tell me again.

Thanks.

Joe

[mjbcswitzerland]

Joe

Erasing the sector that contains the Flash configuration and rewriting different values is always risky since a reset or loss of power in the process will leave them either erased (chip secured, NMI and EzPort enabled [depending on chip]) or possibly undefined. There is no way to avoid this 100%. If the board is not usable it will need to be mass-erased/reprogramed - if it is not at a customer's site it s not a big deal.

- Reset can be more or less excluded when the code is correct, interrupts are blocked and the watchdog just triggered to give enough programming time

. Power down is not in our control so could happen. Best to keep the window of risk as small as possible (note that my code expressly programmes the flash config first to do its best)

The only way to avoid this (quite small) risk is to not do it. In fact, as I noted before, I don't know why you don't program security in your first loader already since if you use this loader to load your final application it can stay that way anyway. Securing the device stops its internal flash from being viewed (by EzPort or debugger) but doesn't stop the boot loader doing its normal work. I use encryption (and authentication) of SW that customers can load themselves (when this distributed code needs to be protected - in fact if the code in the chip is to be protected this will need to be the case otherwise the protection has no meaning because the content will already be freely available).

Regards

Mark

[JHinkle]

You ask why I don't just secure the bootloader with initial installation.  The reason is the backdoor key is available to the supplier who is doing the initial build since they will have the S-Record file to perform the initial flash.  The supplier is a potential competitor, so I don't want to give them after-the-fact access by letting them have the backdoor keys.

Joe

[mjbcswitzerland · Accepted solution]

Joe

What do you need back-door keys for? You don't need to use or enable them, then no one needs to use keys or keep them safe from anyone else.

Simply secure the processor so that it cannot be accessed by EzPort or the debugger, which is perfect for a product.

If you ever need to access it again (would only be to be able to use the HW for debugging) you can simply command a mass erase and the device is back in its delivered state and you can use it for debugging or to program the loader and application again.

In your case your manufacturer can manipulate the original file (eg. remove security) but you can easily detect this with your application that you load later (via the boot loader). It can check the state and give you a warning, refuse to run or whatever and you can then contact the manufacturer to tell them that they have breached your contact by modifying code (you should best put in the boot loader check as in my code since the manufactuerer could always modify the SREC to put in other ways to add back-door access to code so even having secret back-door keys woudln't save you). Simply state that any code modifications (which you will then be able to detect) are not allowed and if such modification were to be detected you reserve the right to claim damages (maybe $100k or $1M damages should be enough to keep the roguest manufacturer at bay).

Regards

Mark