AnsweredAssumed Answered

Securing K22 Code

Question asked by Christopher Burg on Jun 29, 2018
Latest reply on Jul 20, 2018 by Mark Butcher

Like • Show 0 Likes0
Comment • 14

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

14 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
Christopher Burg 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 @ Christopher Burg 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
  - Christopher Burg @ 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
- Christopher Burg @ 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 @ Christopher Burg 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
    - Christopher Burg @ 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 @ Christopher Burg 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
        Christopher Burg @ 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 @ Christopher Burg 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!
        -----------------------------------------------------------------------------------------------------------------------
        Like • Show 0 Likes0
        Actions
        Christopher Burg @ 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 @ Christopher Burg 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

Securing K22 Code

Outcomes

Related Content

Recommended Content