AnsweredAssumed Answered

Securing K22 Code

Question asked by burgeh on Jun 29, 2018
Latest reply on Aug 2, 2018 by Kerry Zhou

Like • Show 0 Likes0
Comment • 24

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!

No one else has this question

Outcomes

24 Replies

Mark Butcher Jun 29, 2018 3:17 PM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
burgeh Jul 10, 2018 7:03 AM
Mark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions
- Mark Butcher @ burgeh on Jul 10, 2018 5:58 PM
  Mark Correct
  Correct Answer
  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
  1 person found this helpful
  Like • Show 0 Likes0
  Actions
  - burgeh @ Mark Butcher on Jul 18, 2018 2:52 PM
    Mark Correct
    Correct Answer
    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.
    Like • Show 0 Likes0
    Actions
Mark Butcher Jul 18, 2018 3:49 PM
Mark Correct
Correct Answer
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
Like • Show 0 Likes0
Actions
- burgeh @ Mark Butcher on Jul 19, 2018 7:21 AM
  Mark Correct
  Correct Answer
  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.
  Like • Show 0 Likes0
  Actions
  - Mark Butcher @ burgeh on Jul 19, 2018 8:46 AM
    Mark Correct
    Correct Answer
    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
    Like • Show 0 Likes0
    Actions
    - burgeh @ Mark Butcher on Jul 19, 2018 9:34 AM
      Mark Correct
      Correct Answer
      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?
      Like • Show 0 Likes0
      Actions
      - Mark Butcher @ burgeh on Jul 19, 2018 11:05 AM
        Mark Correct
        Correct Answer
        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
        1 person found this helpful
        Like • Show 0 Likes0
        Actions
        burgeh @ Mark Butcher on Jul 19, 2018 11:29 AM
        Mark Correct
        Correct Answer
        Thank you,
        
        Kerry Zhou
        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?
        Like • Show 0 Likes0
        Actions
        Kerry Zhou @ burgeh on Jul 19, 2018 6:16 PM
        Mark Correct
        Correct Answer
        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!
        -----------------------------------------------------------------------------------------------------------------------
        1 person found this helpful
        Like • Show 1 Like1
        Actions
        burgeh @ Kerry Zhou on Jul 19, 2018 6:48 PM
        Mark Correct
        Correct Answer
        Is that just setting the FSEC register? Where I do I enter the backdoor key value, and enable backdoor key?
        Like • Show 0 Likes0
        Actions
        Kerry Zhou @ burgeh on Jul 19, 2018 8:05 PM
        Mark Correct
        Correct Answer
        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!
        -----------------------------------------------------------------------------------------------------------------------
        Like • Show 0 Likes0
        Actions
        Mark Butcher @ Kerry Zhou on Jul 20, 2018 6:51 PM
        Mark Correct
        Correct Answer
        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
        Like • Show 0 Likes0
        Actions
        burgeh @ Mark Butcher on Jul 24, 2018 9:53 AM
        Mark Correct
        Correct Answer
        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.
        
        Kerry Zhou 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.
        Attachments
        tower_bootloader.zip1.6 MB
        Like • Show 0 Likes0
        Actions
        Kerry Zhou @ burgeh on Jul 26, 2018 1:34 AM
        Mark Correct
        Correct Answer
        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!
        -----------------------------------------------------------------------------------------------------------------------
        Like • Show 0 Likes0
        Actions
        burgeh @ Kerry Zhou on Jul 26, 2018 7:55 AM
        Mark Correct
        Correct Answer
        
           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.
        Like • Show 0 Likes0
        Actions
        Kerry Zhou @ burgeh on Jul 31, 2018 7:25 PM
        Mark Correct
        Correct Answer
        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!
        -----------------------------------------------------------------------------------------------------------------------
        1 person found this helpful
        Like • Show 1 Like1
        Actions
        burgeh @ Kerry Zhou on Jul 31, 2018 11:18 AM
        Mark Correct
        Correct Answer
        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!
        Like • Show 0 Likes0
        Actions
        Kerry Zhou @ burgeh on Jul 31, 2018 8:22 PM
        Mark Correct
        Correct Answer
        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!
        -----------------------------------------------------------------------------------------------------------------------
        1 person found this helpful
        Like • Show 1 Like1
        Actions
        burgeh @ Kerry Zhou on Aug 1, 2018 7:16 AM
        Mark Correct
        Correct Answer
        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!
        Like • Show 0 Likes0
        Actions
        Kerry Zhou @ burgeh on Aug 1, 2018 9:10 PM
        Mark Correct
        Correct Answer
        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!
        -----------------------------------------------------------------------------------------------------------------------
        1 person found this helpful
        Like • Show 1 Like1
        Actions
burgeh Aug 2, 2018 1:31 PM
Mark Correct
Correct Answer
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.
Like • Show 0 Likes0
Actions
- Kerry Zhou @ burgeh on Aug 2, 2018 7:21 PM
  Mark Correct
  Correct Answer
  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!
  -----------------------------------------------------------------------------------------------------------------------
  1 person found this helpful
  Like • Show 1 Like1
  Actions

Securing K22 Code

Outcomes

Attachments

Related Content

Recommended Content