MDK, APPROTECT, debug port protection.

[SeanHowsonTB]

Hi Folks,

SDK17.1.0, MDK8.40.3, S140

My goal is to lock out access to the debug port of an NRF52840-QIAA-T (revision 3), so that the port cannot be used to alter or read the memory of the chip in any way.

1: What is the standard way to include the defintions discussed in IN-141 ("ENABLE_APPROTECT") ? - Do i manually make these definitions? or are they already in a file, waiting to be enabled? similar to the SDK_config.h file?

2: How can I ensure I do not suffer the vulnerability discussed in IN-133?

I found the following blow post:  Working with the nRF52 Series' improved APPROTECT 

and have reviewed the infocentre: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fuicr.html

3: The code listed in this post to set the UICR.APPROTECT register, will this code work standalaone? With no prerequisites required to run the NVMC?

4: What is the MDK licence.msi file for? I installed it to see what would happen... but i'm not clear on it's purpose.

5: Much of the documentation makes reference to the CTRL-AP, I have read the info centre documentation for this. Regardless, what i'd like to know is how one would typically modify these registers, via SWD?

I found quotes such as: 

After an ERASEALL operation is executed (by nrfjprog or manually via the CTRL-AP) the device should be accessible to a debugger until it executes a pin, power, or brownout reset.

What does is mean, "manually"? Can someone explain the options for how to issue an ERASEALL operation?

6: I am also seeing some confusing notes on the naming cultures for the build revisions to the chip. Any confirmation that the T model i see with many suppliers is definitely revision 3 would be useful. Exactly what revision is the chip i am seeing advertising as NRF52840-QIAA-T?

Best regards,

Sean

IN-133:

https://infocenter.nordicsemi.com/pdf/in_133_v1.0.pdf

IN-141:

https://infocenter.nordicsemi.com/pdf/in_141_v1.1.pdf

[SeanHowsonTB]

Note: I have of course found the nrf52_approctect.h files in the MDK folder, But this merely examines whether or not ENABLE_APPROTECT is defined, it does not actually provide a facility for defining it. (hence question 2)

I also notice reference to definition of an errata, (249), in this file. Some explanation of how to approach this would be appreciated to.

[Hung Bui]

Hi Sean, 

1&2: The standard way of defining ENABLE_APPROTECT is define it in the Preprocessor Definitions. It's mentioned in Daniel's blog "In the nRF5 SDK the ENABLE_APPROTECT symbol can be added to a project's preprocessor defines". If you use SES it should look like this: 

3. I assume you are asking about this line "3. Write Enabled (0x00) to UICR.APPROTECT" ? 
It's the instruction to write to UICR.APPROTECT from the programmer/debug not from the firmware. My understanding is that the programmer (nrfjprog or Jlink Commander) will enable write automatically before the write. 

Let me try to explain what has been changed in version 3 in an easier to understand way. You can read more about this in the product specification here.

Before version 3, we only disable/enable the APPROTECT feature by only one single UICR register value APPROTECT. It's stored in flash. When the chip booting up, it checks this register. And based on the value of this register the chip enable or disable the debug port for accessing to the chip. The attack described in IN-133 introduces a glitch at this check of the booting up and in some corner cases can overpass the check. 

From version 3, we introduce a better protection against the glitch in the hardware, but more importantly we added an extra layer of checking if APPROTECT is disable or enable or not in the software. APPROTECT is controlled by hardware and software. And in the software it's enabled by default. This means any glitch in the hardware will make no difference because it will be stopped if it can't control the software (application running on the chip). If the software doesn't explicitly disable APPROTECT then APPROTECT will be enabled by default. 

It's what you see in nrf52_hanle_approtect() code:

 #if NRF52_ERRATA_249_PRESENT
        #if defined (ENABLE_APPROTECT)
            if (nrf52_errata_249())
            {
                /* Prevent processor from unlocking APPROTECT soft branch after this point. */
                NRF_APPROTECT->FORCEPROTECT = APPROTECT_FORCEPROTECT_FORCEPROTECT_Force;
            }
        #else
            if (nrf52_errata_249())
            {
                /* Load APPROTECT soft branch from UICR.
                   If UICR->APPROTECT is disabled, POWER->APPROTECT will be disabled. */
                NRF_APPROTECT->DISABLE = NRF_UICR->APPROTECT;
            }
        #endif
    #endif

If you define ENABLE_APPROTECT in the preprocessor definitions, the code will not write to NRF_APPROTECT->DISABLE, meaning that the chip will be protected and the debugger port will be blocked. In addition to not write to NRF_APPROTECT->DISABLE, it will write to NRF_APPROTECT->FORCEPROTECT as an extra layer of security as mentioned in the specification. 

If you don't define ENABLE_APPROTECT in your preprocessor definitions, the code will write to NRF_APPROTECT->DISABLE. The value it writes to NRF_APPROTECT->DISABLE is the value in NRF_UICR->APPROTECT. This is to make the behavior align with what we have in older versions of the chip. And, in my opinion, it was what Daniel wanted to tell when he mentioned "Then a function in MDK version 8.45.0 (or newer) is executed during startup to complete the firmware step. If the firmware step is skipped then the device may appear locked but it will not be completely protected." 

If you don't define ENABLE_APPROTECT, and then you only write to NRF_UICR->APPROTECT to enable APPROTECT, you are basically removing the software protection of the APPROTECT, and only rely only on the UICR.APPROTECT. This makes the chip not much more protected compare to version 2 and earlier.

4. I assume you are asking about nrf_mdk_8_52_0_keil4_bsdlicense.msi ? It will install the MDK files to the default MDK folder on KEIL. Most likely you will have the MDK files installed when you install the SDK. 

5. My mentioning "manually", it means you access the CTRL-AP by using Jlink Commander program instead of nrfjprog . This is what Daniel showed in the second part of his blog with "J-Link>" command. 

6. If you look at the Order code here, you can find that the T code you see is the Container Code. T stands for Tray, the other options are R or R7 which are  the Reel. It's just the packaging of the delivery of the chips. Here is Tray: 

[SeanHowsonTB]

Hi Hung

Thanks for a prompt & full reply.

regarding Q3:

Your explanation makes a lot of sense, but it seems there are several ways to do all of the operations listed across the blog posts & info centre.

You did answer many things i was unsure about, but i'm afraid my original question was intended to be much simpler.

The blog post, shows the following peice of code:

#ifdef ENABLE_APPROTECT
	if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) !=
		(UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos)) {

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->APPROTECT = ((NRF_UICR->APPROTECT & ~((uint32_t)UICR_APPROTECT_PALL_Msk)) |
		    (UICR_APPROTECT_PALL_Enabled << UICR_APPROTECT_PALL_Pos));

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
   	}
#else
	if ((NRF_UICR->APPROTECT & UICR_APPROTECT_PALL_Msk) !=
		(UICR_APPROTECT_PALL_HwDisabled << UICR_APPROTECT_PALL_Pos)) {

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->APPROTECT = ((NRF_UICR->APPROTECT & ~((uint32_t)UICR_APPROTECT_PALL_Msk)) |
		    (UICR_APPROTECT_PALL_HwDisabled << UICR_APPROTECT_PALL_Pos));

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
	}
#endif

This code amoung other things, shows the "NRF_UICR->APPROTECT " register being written to, which as i understand it, is in flash. The code also shows the NVMC registers being used. I've not used these before on nordic chips. My question is: Are there any pre-prequisites required (such as initialising the NVMC system for example), or will this snippet of code work "standalone", "copy&paste" (or course i want to understand it properly first). But i want to know if I dump it into my code. The NVMC code above will work ok?

Regarding Q5:  (i've never used Jlink commander program) before: If some command is sent, can i assume that this will write to the specified memory location in flash (the CTRL_AP register locations)? presumably these locations are then examined CPU & acted upon accordingly? Or is the CTRL_AP process more complex than this?

Regarding Q6: A colleague of mine spoke to a nordic rep recently at a conference who explained the "R" model to be the oldest, the "F-R" model to be previous model and the "T" model to be the lastest. This didnt really sound right to me. I couldn't see why Nordic would switch between using a 1 or 2 character extension. I have reviewed the order code page, thanks for that. My question is this: Some of the listed models have the build code "F" listed (yellow highlighter below, revision 3 i assume?) and some of them, seemingly do not have a build code listed (purple highlighter below). What is the build code of the ones in purple, with no build code listed?

For example, a regular supplier of ours linked below has the "T" model, but no mention of a build code? (I know there is a picture of the chip, but these aren;t always accurate).

https://www.digikey.co.uk/en/products/detail/nordic-semiconductor-asa/NRF52840-QIAA-T/15929814?s=N4IgTCBcDaIHYCcBmBWMAOALABgLQEcBLAQ2NwBUQBdAXyA

[Hung Bui]

Hi Sean, 

3. My understanding about the code is that it's the solution for this sentence in bold : However, the code in the MDK does not set the UICR.APPROTECT value.
The code in the MDK doesn't check or write the UICR.APPROTECT and leave the responsibility of writing to UICR.APPROTECT to the one who flashes the firmware to the chip. By default the value of it is 0xFF Disabled. 
What the code suggested by Daniel does is to enforce UICR.APPROTECT to follow what defined in the application ENABLE_APPROTECT. The code will write to UICR.APPROTECT if it's not set accordingly to the ENABLE_APPROTECT configuration of the code. 
The NVMC code    NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;  is to enable writing to UICR from the application code. And NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren is to disable writing to UICR. 

The code work without any extra initialization needed. It accesses the NVMC and UICR registers directly. 

From my point of view, it's up to the designer to choose to let the application has full control over both the hardware (UICR) and the software (the register) of the APPROTECT or not.  I'm thinking of a situation when a glitch introduced in the application would manipulate the quoted application code and causing this code disable UICR.APPROTECT hardware protection. 

It should be fine not having the code to write to UICR.APPROTECT if you make sure you explicitly write to UICR.APPROTECT when in production.

5. The CTRL-AP simply writes to the register in CTRL-AP domain. The effect of those commands are described in the specification. It's similar to other registers, just slightly different that the registers can only be accessed via CTRL-AP port,  not from the application and not from SWD debug port.

6.  We at tech support wouldn't be the best to answer question about order code. I would suggest to check with Ms. Claire Steed, our Sales Manager for UK, for information about ordering.  I will send send her a message. 

[SeanHowsonTB]

Hung,i've

Thanks again for a full answer.

I will work backwards through reply here:

6 - Thank you very much, I will happily contact Ms. Steed myself if this is outside your domain, if you happen to have any contact details for her, feel free to message them to me privately. If you message her, key question is "What build code/revision are the "NRF52840-QIAA-T" models, the "non-F-T" models, as per my previous screenshot". - Thanks.

5: Thanks for clearing this up, i just wanted a little context/ understanding.

3: I think i may have a followup question but i need to continue reading before i post, so may post again later on.

Thanks again,

Sean