topic Re: Securing K22 Code in Kinetis Microcontrollers

Securing K22 Code

burgeh — Fri, 29 Jun 2018 20:44:13 GMT

Greetings,

I am using KDS v3.2 with Processor expert and a custom board.

I am wondering what some of my resources are for securing my firmware on my K22FN256LH12. Reading through this document https://www.nxp.com/docs/en/application-note/AN4507.pdf

1. I see there is a basic "Security Enable" for JTag, which I use to access the chip. This allows for me to just not be able to debug, without erasing the whole chip correct? Once it is flashed, it can no longer be debugged, only re-flashed correct?

2. Backdoor key enable. Once this is used, a person cannot do anything to the chip without the 64 bit key? This includes flashing, erase, reading and debug correct? If I get in, I have full control again to flash right? Also I am unsure how to issue the Verify Backdoor Access Key command, is there a method I can use/ Where is this value stored that I can use to compare?

3. Mass erase disable. Is this like a one shot? Once you flash it, that's how it stays forever?

4. Freescale Access, I assume I should not allow access. Since I'll do the analysis.

Is there anything I missed or any suggestions? I like the backdoor key if it allows full access if the right key is entered (can I change this key after I've gained access and reflash?), but it seems to need a lot of structure for it to setup.

Thanks!

Re: Securing K22 Code

mjbcswitzerland — Fri, 29 Jun 2018 22:17:50 GMT

Hi Christoper

Usually setting the secure mode is adequate for code protection since it is then not possible to read the content without first issuing a mass erase (resulting in a fresh chip again).

Be very careful with JTAG lockout with mass erase disable since this restricts any further external programming or debugging and results in a bricked development unit in most cases.

Regards

Mark

uTasker developer and supporter (+5'000 hours experience on +60 Kinetis derivatives in +80 product developments)
Kinetis: http://www.utasker.com/kinetis.html

Re: Securing K22 Code

burgeh — Tue, 10 Jul 2018 14:03:13 GMT

Would I be able to use the KinetisFlashTool to access my chip since it has a section for the backdoor key?

The reason why I don't want to try this for my self is because of this image below. My application code (I believe, unless PE did something) does not have anything like this. However, it seems KinetisFlashTool can do this.

Re: Securing K22 Code

mjbcswitzerland — Wed, 11 Jul 2018 00:58:00 GMT

Christopher

Since the K22 doesn't have KBOOT built in as a BOOT ROM it represent an 'application' to the processor and as such fulfills the requirement to be able to run the validation command (KBOOT requires the FlashSecurityDisable option to be enabled for it to work).
Your usual application can do the same thing if it uses the same validation code (and has a method of the validation being commanded when the application is running)..

In both cases it will only be possible if either the boot loader mode can be entered or the application is operational - if for any reason one of these fails (something unforeseen) it will not be able to work anymore.

Note also that the backdoor key validation is a temporary unlocking and after a reset it is secured again. This may not always be practical so it depends on the requirements to temporarily set the unsecured state.

Note that KBOOT also has a "erase all to unlock" command which is a mass erase - this means that the chip then becomes more or less a fresh chip and you can reconnect without any restrictions via EzPort, SWD or JTAG.

A simple way to at least allow the chip to be fully unsecured is to have a command in the application that performs a mass erase (if you prefer in addition to the backdoor unlock) since this will always ensure recovery. A pull-up or pull-down on a free pin at reset to cause this to execute is a fairly effective way to ensure that it works, even if the loaded application subsequently runs away due to some new error.

It depends on what your exact security requirement is - if you just need to protect Flash content and have a Jtag programmer available simply setting the secure state would be adequate (no debugger blocking) and no internal recovery method will ever be needed.

Regards

Mark

Re: Securing K22 Code

burgeh — Wed, 18 Jul 2018 21:39:18 GMT

My goals are to not have the firmware accessible (readable) and to not allow anyone to just mass erase it and reprogram it. I enable the security and the backdoor key as shown below.

However, I am still able to erase with J-Link Commander (no key needed) and reflash with KBoot (No key needed). Is there something I am missing? I do have a bootloader on here. Below is an image of KBoot after I loaded the "secure" firmware on, and then tried loading another firmware. I was able to and it seems to be UNSECURE.

Re: Securing K22 Code

mjbcswitzerland — Wed, 18 Jul 2018 22:49:10 GMT

Christopher

If KBOOT displays the device as UNSECURE (as in the image) it is not secure - how do you program to the board? - some tools don't let you program the security state (attempting to avoid you locking the chip unintentionally) without setting up its configuration to allow it.

If the device is un-secure KBOOT will also ignore the mass erase and backdoor key settings (they an be set but no command is sent).

Also, note that features in KBOOT (at the processor) are optional and the mass erase and backdoor key settings are only supported when the options are enabled (they probably are enabled but make sure to avoid bricking the device).

It is your requirement to neither allow the device to be erased nor reprogrammed externally that probably means that you need to enable security (blocks read) and disable the mass erase (can't un-secure via Jtag or EzPort) - or you could probably just as well disable the Jtag EzPort (which does both).

Finally since you don't want a mass erase to be possible you will also need to configure the Kboot option to remove the support, otherwise anyone will still be able to do this using using KBOOT utility.

Regards

Mark

Re: Securing K22 Code

burgeh — Thu, 19 Jul 2018 14:21:42 GMT

Thanks for the reply,

My mistake, I should have specified, I don't want some average Joe to mass erase. If they have the backdoor key (they would have permission from me) to mass erase and re-flash. I don't want to completely disable mass erase, since I would like to go back and occasionally update it.

I currently use J-Link commander to load a tower_bootloader (provided by KBOOT) and then use a USB connection to the board after reset to communicate with the KinetisFlashTool. Using the flash tool flash the application.

I know for sure that when I flash the board using KDSv3.2 with just the security bit set that it informs me of the security protection.

Re: Securing K22 Code

mjbcswitzerland — Thu, 19 Jul 2018 15:46:19 GMT

Christopher

The SECURE / USECURE state displayed by KBOOT is the result of it requesting the board its flash security state using the PROPERTY_FLASH_SEC_STATE (17) property request.

When the Flash is unsecured the response is a 0 and when it is secured the response is 1.

If you know that you have secured Flash but the tool is not showing it the problem is in the KBOOT version you have loaded to the K22. You will need to check whether it has additional options to allow this or whether it doesn't correctly identify the secured state.

Without the chip correctly signalling its secured state the KBOOT utility will also not attempt to unlock the device even if the check boxes are set, meaning that this must first be resolved before being able to move on.

Regards

Mark

Re: Securing K22 Code

burgeh — Thu, 19 Jul 2018 16:34:40 GMT

Is there some bits that need to be set within the bootloader to reflect the fsec register within the application? I have no problem flashing it even though it should be secured with a backdoor key. Is there a headfile within the bootloader with some defines that I could check to ensure it is being set? I mostly see that it is pointers check registers within the CPU therefore if it is set on the application it should update the bootloader values (image one). The second and third images, this is in my application, below seems to be that it has values.

Thoughts?

Re: Securing K22 Code

mjbcswitzerland — Thu, 19 Jul 2018 18:05:09 GMT

Christopher

You must secure the chip in the boot loader and not in the application. The application values have no relevance and can be removed - > therefore you much make the same security setting in the loader and re-flash the boot loader for them to apply.

Regards

Mark

Re: Securing K22 Code

burgeh — Thu, 19 Jul 2018 18:29:48 GMT

Thank you,

kerryzhou‌

Is there a place within the tower_bootloader code for the K22FN256 where I can set the FSEC register as well as the backdoor key values?

Re: Securing K22 Code

kerryzhou — Fri, 20 Jul 2018 01:16:03 GMT

Hello Christopher,

Of course, you can!

Please check my following picture:

FlashConfig used to configure the flash configuration field.

Wish it helps you!

Have a great day,
Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Securing K22 Code

burgeh — Fri, 20 Jul 2018 01:48:35 GMT

Is that just setting the FSEC register? Where I do I enter the backdoor key value, and enable backdoor key?

Re: Securing K22 Code

kerryzhou — Fri, 20 Jul 2018 03:05:35 GMT

Please refer to the user manual,the flash configuration field is the 16byte space, it is the same as the code __FlashConfig , if you want to modify the backdoor key, just modify the front 8bytes in __FlashConfig.

Have a great day,
Kerry

Re: Securing K22 Code

mjbcswitzerland — Sat, 21 Jul 2018 01:51:46 GMT

Christopher

__FlashConfig
DCD 0xffffffff <- backdoor keys1
DCD 0xffffffff <- backdoor keys2
DCD 0xffffffff <- program protection
DCD 0xfffffffe <- (data flash protection / EEPROM protection / non-volatile options / security setting)

but I don't know why it is done in assembler since it is rather cryptic.

In the uTasker loader it is done as follows, which is more use friendly:

const KINETIS_FLASH_CONFIGURATION __flash_config
= {
    KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY,
    KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION,
    KINETIS_FLASH_CONFIGURATION_SECURITY,
    KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION,
    KINETIS_FLASH_CONFIGURATION_EEPROM_PROT,
    KINETIS_FLASH_CONFIGURATION_DATAFLASH_PROT
};

// FLASH configuration settings (these are plugged into the KINETIS_FLASH_CONFIGURATION_BACKDOOR_KEY area)
//
#define BACKDOOR_KEY_0     0x00       // note that values with all 0x00 or all 0xff are not valid
#define BACKDOOR_KEY_1     0x00
#define BACKDOOR_KEY_2     0x00
#define BACKDOOR_KEY_3     0x00
#define BACKDOOR_KEY_4     0x00
#define BACKDOOR_KEY_5     0x00
#define BACKDOOR_KEY_6     0x00
#define BACKDOOR_KEY_7     0x01

#define KINETIS_FLASH_CONFIGURATION_SECURITY           (FTFL_FSEC_SEC_SECURE | FTFL_FSEC_FSLACC_GRANTED | FTFL_FSEC_MEEN_ENABLED | FTFL_FSEC_KEYEN_ENABLED)
#define KINETIS_FLASH_CONFIGURATION_PROGRAM_PROTECTION (0xffffffff) // PROT[31:24]:PROT[23:16]:PROT[15:8]:PROT[7:0] - no protection when all are '1'
#define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION      (FTFL_FOPT_EZPORT_ENABLED | FTFL_FOPT_LPBOOT_NORMAL | FTFL_FOPT_NMI_DISABLED)
#define KINETIS_FLASH_CONFIGURATION_EEPROM_PROT        0xff
#define KINETIS_FLASH_CONFIGURATION_DATAFLASH_PROT     0xff

A possible secure setting for your case is thus 0xbc

Regards

Mark

Re: Securing K22 Code

burgeh — Tue, 24 Jul 2018 16:12:26 GMT

I have these values set, so this would set the FSEC to secure, and set the backdoor key to 000...001. However, I still get Unsecure from KBOOT as well as I can erase easily from J-Link Commander.

kerryzhou‌ I seem to have it set correctly. I am using the tower_bootloader code on the K22FN256. Not quite sure why it would not be securing. I've built it a few times as the release version. Any other place I need to change? I attached my current tower_bootloader. I don't recall any changes other than the flashconfig.

Re: Securing K22 Code

kerryzhou — Thu, 26 Jul 2018 08:34:25 GMT

Hi Christopher,

Don't worry, please generate the .hex file, and in the hex file, check the according flash address, whether the data is configured as your defined? If yes, it is correct.

Besides, when you use the JLINK, as you know, there will have a chip partnumber select, you need to select the partnumber with allow security, that means when you use the JLINK, the flash configuration field can be modified, otherwise JLINK won't update the flash configuration field.

Please also note, even your secure the SWD, but you still can use the SWD to unlock it, if you enable the mass erase bit. this is correct. But others can't read or write directly through the SWD if it is unlocked, unlock is just the mass erase.

Wish it helps you!

Have a great day,
Kerry

Re: Securing K22 Code

burgeh — Thu, 26 Jul 2018 14:26:41 GMT

Besides, when you use the JLINK, as you know, there will have a chip partnumber select, you need to select the partnumber with allow security, that means when you use the JLINK, the flash configuration field can be modified, otherwise JLINK won't update the flash configuration field.

What do you mean by this exactly? When I use J-Link commander below is an image of my typical settings, is there something I'm missing?

How can I confirm this? This image tells me the address, but I do not see where this is.

Re: Securing K22 Code

kerryzhou — Tue, 31 Jul 2018 09:21:00 GMT

Hi Christopher,

Your selection is not correct, please check my side:

You can find two items, one is allow security, another won't allow security, this is the JLINK driver. If you don't select the allow security, even you secure the chip, when you download the code, the JLINK debugger will still won't modify the flash configuration field.

So, please select the chip as MK22FN256xxx12(allow security), then try it again.

About your hex, your picture still not in the 0X400 side, it is just contains 0x40 address. You can share me your whole .hex file.

Please note, in the IDE JLINK inteface, you also need to select the chip as MK22FN256xxx12(allow security), this is very important.

Have a great day,
Kerry

Re: Securing K22 Code

burgeh — Tue, 31 Jul 2018 17:03:56 GMT

Perfect, I was unaware of that setting with the J-Link. Almost there! The image below shows my attempt at flashing. As you can see the chip is now secure, however, I am having an issue with the backdoor key. I believe it is enabled, I have my flash config in the second image below, and according the image 3 it should be enable. Also I do not wish to disable the mass erase, to clarify, I want to not allow others to mass erase without the backdoor key.

Image 1. Successful FSEC setting, but not Backdoor Key

Image 2. Code used I believe to set FSEC and KEYEN. "0xBD" is 10 11 11 01 to enable FSEC and KEYEN

Thanks!