Securing K22 Code

[burgeh]

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!

[burgeh]

Final clarification.

"Yes, don't use JLINK command to connect it again, it will unlock it automatically.

Please note, secure but allow the mass erase, other people can't erase it, but can't read or write the code, so it will protect the code from accessing through the SWD interface. Erase won't be protected."

Do you mean other people CAN erase, if they connect a J-Link to it? That makes sense, but I want to be sure. Since you also said, "erase won't be protected".

Also should the JTag header be physically disabled or can firmware do this permanently?

Thank you so much, I really appreciate the help.

[kerryzhou]

Hi Christopher,

    1. About the JLINK flash erase

      If you enable the SWD/JTAG pin function, and you also allow the mass erase, even you secure the chip, external debugger still can do the mass erase, but they can't read or write the flash, that is the flash secure. secure used to protect write and read, mass erase bit used to protect the flash mass erase function.

    Actually, you don't need to worry about it, because other people won't steal your code through the SWD interface after the chip is secured.

  2. should the JTag header be physically disabled or can firmware do this permanently?

    Yes, Just disable the mass erase enable bit in flash address 0x40c bit4.5.

  You can refer to this application note:

https://www.nxp.com/files-static/microcontrollers/doc/app_note/AN4507.pdf 

page 3

Don't worry, this bit just influence the SWD JTAG and EZport mass erase, the kinetisflash tool still can erase the chip with backdoor key.

You can try it on your side.

Wish it helps you!

Have a great day,
Kerry

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

[mjbcswitzerland]

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

[burgeh]

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.

[mjbcswitzerland]

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

[burgeh]

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?

[mjbcswitzerland]

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

[burgeh]

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?

[kerryzhou]

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!
-----------------------------------------------------------------------------------------------------------------------

[burgeh]

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

[kerryzhou]

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

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

[mjbcswitzerland]

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

[burgeh]

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.

[kerryzhou]

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

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

[burgeh]

   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.

[kerryzhou]

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

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

[burgeh]

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!

[kerryzhou]

Hi Christopher Burg,

    You are near the success, but you have a mistake.

  Please check my operation:

1. add the backdoor key in the bootloader, and secure the chip.

Please note, the back door key is:0000000001000000

You also can find it in the .hex file:

You are using the wrong backdoor key, I am using the uart port to update the app, and test board is the FRDM-K22 board, this is the test result:

You can find, I can download the code with backdoorkey sucessfully.

Please try it again on your side.

Wish it helps you!

Have a great day,
Kerry

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

[burgeh]

Thanks! I am a little bit confused as to why the backdoor key is 0000 0000 0100 0000 and not 0000 0000 0000 0001? Could you explain a bit more? Because we set the first 8 bytes to 0x0000000000000001. I confirmed that I can flash it now with the key you told me. I also saw how it is set in the hex file thanks!

[kerryzhou]

Hi Christopher,

  Good, from your picture, you also make it works, now answer your new two questions:

1.why the backdoor key is 0000 0000 0100 0000 and not 0000 0000 0000 0001?

    .section .FlashConfig, "a"
    .long 0x00000000
    .long 0x00000001
    .long 0xFFFFFFFF
    .long 0xFFFFFFBD

Please note:

.long is the LE, not BE. LE means little end, BE means Big end.

So, 0X00000001, 0x01 is the address 0x404.

    .long 0xB3B2B1B0
    .long 0xB7B6B5B4

In the backdoor key is:B0B1B2B3B4B5B6B7

I think this is good to understand now.

2. jlink commander

 Yes, don't use JLINK command to connect it again, it will unlock it automatically.

Please note, secure but allow the mass erase, other people can't erase it, but can't read or write the code, so it will protect the code from accessing through the SWD interface. Erase won't be protected.

Wish it helps you!

Have a great day,
Kerry

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