Authenticated Debug Access (APPROTECT)

RE: Authenticated Debug Access (APPROTECT)

Raymond — Fri, 19 Sep 2025 19:35:09 GMT

Thanks Einar. I appreciate the help.

RE: Authenticated Debug Access (APPROTECT)

Einar Thorsrud — Fri, 19 Sep 2025 06:42:21 GMT

Hi,

[quote userid="9938" url="~/f/nordic-q-a/124416/authenticated-debug-access-approtect/549222"]It seems like that may be incorrect. The UICR.APPROTECT register is set to "disabled" when 0xFF, meaning the device is unsecured. [/quote]

That applies to the old revision 1 and 2, with hardware only based protection. For revision 3 devices with AP protect controlled by hardware and software, the magic word 0x5A (named HwDisabled in the table) is the only value that disables AP protect.

RE: Authenticated Debug Access (APPROTECT)

Raymond — Thu, 18 Sep 2025 17:46:09 GMT

Hi Einar Thorsrud , I'm working with J.P. Hutchins on this project.

Firstly, thank you for the detailed responses and providing clarification!

Regarding your comment about "PS: There's a twist here" extra level of protection: It seems like that may be incorrect. The UICR.APPROTECT register is set to "disabled" when 0xFF, meaning the device is unsecured. So when left in this state, the firmware would only be able to set the device to "HwDisabled" or "Enabled" (secured) by clearing bits.

RE: Authenticated Debug Access (APPROTECT)

Einar Thorsrud — Thu, 18 Sep 2025 06:56:34 GMT

Hi,

[quote user="J.P. Hutchins"]Our present approach of unconditionally writing "Disabled" to the UICR, via the factory HEX, is OK[/quote]

Yes, that is OK and a requierment for implementing authenticated debug. (If UICR.APPROTECT does nto have the magic word to unlock it, there is no way software can open the debug interface).

[quote user="J.P. Hutchins"]Which seems to write NRF_APPROTECT->DISABLE using the UICR. It's confusing, because if UICR is "doing something on its own", why is there this (disabled) runtime code to write the NRF_APPROTECT->DISABLE with it?[/quote]

This is mostly just a way of implementing it, the point is to write the magic word 0x5A. When doe like this, the correct magic word is only writen to NRF_APPROTECT->DISABLE if it is also in UICR.APPROTECT. I do not see a funcional difference if you had written a hard coded magic word not read from UICR (particularily as you know the magic word will always be present in UICR in your case as it is requiered when implementing authenticated debugging.

[quote user="J.P. Hutchins"]Does this mean that there would be a brief window at reset where the DAP is unlocked, unless UICR.APPROTECT is set to "Enabled"?[/quote]

No, the debug interface is locked down unless both the HW and SW path opens it up. However, we state in the product specification that you must lock both the UICR and SW path and recommend also writing to APPROTECT.FORCEPROTECT. However, this will make authenticated debugging impossible as there will be no way to unlock the debug interface.

[quote user="J.P. Hutchins"]So we need to know exactly what firmware function this is referring to to avoid the "device may appear locked but it will not be completely protected" state that the article warns of.[/quote]

This goes back to tha the article and the product specification specifies that you shall lock both the HW and FW path and this is to be on the safe side, in case one of the paths is compromized by a hypotetical attack. But by design, locking one path is enough. And again, it is the only way you can implement authenticated debuggign.

PS: There is a twist here. You can write to the UICR and flip bits from 1 to 0 during the lifetime of the product (but not the other way around as that would requier a full chip erase). That should make it possible to leave UICR.APPROTECT 0xFF and then when you have doen your authentication procedure and want to open the debug interface first write the magic word 0x5A to UICR.APPROTECT and perform a reset (which is requiered for UICR changes to take effect). After that authenticate again and proceee with opening the debug interface via NRF_APPROTECT->DISABLE. This would then keep UICR.APPROTECT alo locked until the first authenticate debug session (at which poit tthe device is probably no longer out in the field).

RE: Authenticated Debug Access (APPROTECT)

J.P. Hutchins — Wed, 17 Sep 2025 23:16:47 GMT

HI Einar Thorsrud ,

Thank you for confirming the approach! Just a few more clarifications:

[quote userid="7377" url="~/f/nordic-q-a/124416/authenticated-debug-access-approtect/549045"]UICR.APPROTECT need to be written to to open the debug interface.[/quote]

Our present approach of unconditionally writing "Disabled" to the UICR, via the factory HEX, is OK because it is only one half of the lock, the other half being NRF_APPROTECT->DISABLE? Would it be more secure to write "Enabled" via the factory HEX and then write "Disabled"/"Enabled" along with the authenticated application code that alters the NRF_APPROTECT->DISABLE?

Re: UICR, we are not setting APPPROTECT USE UICR, and because of our patch, we would never hit this:

        #else
            if (nrf52_configuration_249())
            {
                /* Load APPROTECT soft branch from UICR.
                   If UICR->APPROTECT is disabled, POWER->APPROTECT will be disabled. */
                NRF_APPROTECT->DISABLE = NRF_UICR->APPROTECT;
            }
        #endif

https://github.com/NordicSemiconductor/nrfx/blob/11f57e578c7feea13f21c79ea0efab2630ac68c7/mdk/system_nrf52_approtect.h#L50-L57

Which seems to write NRF_APPROTECT->DISABLE using the UICR. It's confusing, because if UICR is "doing something on its own", why is there this (disabled) runtime code to write the NRF_APPROTECT->DISABLE with it?

[quote userid="7377" url="~/f/nordic-q-a/124416/authenticated-debug-access-approtect/549045"]The debug interface will be locked by default after reset even if allowed in the UICR, and will not be open until NRF_APPROTECT->DISABLE. So until tha tis writte to, debug is not possible.[/quote]

That is what we've been assuming, but it seems to contradict this article: Working with the nRF52 Series' improved APPROTECT (emphasis mine)

"""

The new access port protection mechanism is configured in two steps: in the hardware and in the firmware. At reset, the UICR.APPROTECT value is fetched in hardware. 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 this quote is correct, then it indicates some problems for our approach, I think.

We have set UICR.APPROTECT to "Disabled" (0x5A), instead of "Enabled" (0x00) as suggested in the article. It says that UICR is fetched by the hardware at startup. Does this mean that there would be a brief window at reset where the DAP is unlocked, unless UICR.APPROTECT is set to "Enabled"?
It says "Then a function in MDK version 8.45.0 (or newer) is executed during startup to complete the firmware step." I think that we are OK as long as that firmware step is not the function that we have patched into a NOP. So we need to know exactly what firmware function this is referring to to avoid the "device may appear locked but it will not be completely protected" state that the article warns of.

Thanks again for your time!

RE: Authenticated Debug Access (APPROTECT)

Einar Thorsrud — Wed, 17 Sep 2025 13:42:42 GMT

Hi,

Thank you for sharing. I would like to start by a disclaimer, as I cannot guarantee the security of you design. But I can comment if I see any issues. Fundamentally the approach looks good. Revision 3 of the nRF52840 with the updated AP Protech mechanism has the requiered hardware features to implement authenticated debuging, as you have done.

[quote user=""]Thereby preventing unauthorized access to the integrated flash. Is this correct?[/quote]

Yes, this is a correct understanding. When debug is allowed in the UICR, it is up to software to enable/disable and potentially lock the debug interface which can be used to implement authenticated debugging.

[quote user=""]Is this simply an incomplete statement and it is in fact possible to safely unlock the debug access using the NRF_APPROTECT register described above?[/quote]

Yes, you are right. That block post covers the most typical use case of AP protection, and not does not cover or authenticated debugging in to account. The relevat features is documented in the product specification, though, under Access port protection controlled by hardware and software.

[quote user=""] Does this mean that authenticated debug is not possible on NRF52 or simply unimplemented and/or undocumented by Nordic?[/quote]

It is not supported in the sense that we do not provide any official guidance or tools for it, other than the description of the hardware features itself in the product specification. So implementing it will be up to you and it is your responsibility to ensure that it meets your requierments with regards to functionality and security.

As you have seen, CONFIG_NRF_APPROTECT_USER_HANDLING is not implemented for the nRF52 series devices (this goes all the way down to the MDK implementation, which does not support it, unlike for newer devices. However, your implementation of this looks good, and I do not have any comments regarding that.

[quote user=""]Looking at this now, I am concerned that it's DISABLING the APPROTECT on startup rather than ENABLING it. I think this is important because it is what mitigates the vulnerability in previous revisions? [/quote]

The debug interface will be locked by default after reset even if allowed in the UICR, and will not be open until NRF_APPROTECT->DISABLE. So until tha tis writte to, debug is not possible.

[quote user=""]"Step 2: Setting UICR.APPROTECT" from Working with the nRF52 Series' improved APPROTECT suggests writing this in the app (and bootloader?) and I suppose we should do that to make sure UICR is always "correct" - though, the app does not touch UICR, presently.[/quote]

UICR.APPROTECT need to be written to to open the debug interface. You can either do that in firmware, or via a debugger. For instance if you use "nrfutil device recover" that will among other things write to the UICR to open the debug interface (it will also write a small pice of firmware tha twrites to NRF_APPROTECT->DISABLE so that the device can subsequently be programmed via the debug interface without needing a new recover operation, but that is less relevant here).

The remaining point which I assume you have implemened but not share he details for is how you authenticate before opening the debug interface from the nRF. That needs to be doen in a secure manner, typically using some asyncroneous cryptography so that the firmware on the nRF can authenticate the debugger before opening up for debugging. I do not have specific advice there, though.

RE: Authenticated Debug Access (APPROTECT)

J.P. Hutchins — Tue, 16 Sep 2025 21:21:08 GMT

Corrections:

"which does not meet our requirements for authenticated debug access with erasing flash." should be "which does not meet our requirements for authenticated debug access without erasing flash."

"If I am understanding correctly, then this should be "Disabled", not "Enabled" - or "HwDisabled"?" should be "If I am understanding correctly, then this should be "Enabled", not "Disabled" or "HwDisabled"?"