nrf5340 Hardware Security Features (Fuses and Bus Protections)

[mrrosen]

When evulating the nrf5340 for one of our projects, two questions came up regarding some of the security features used to mitigate tampering and malicious code:

1. What is the state of the debug port on reset? Is there a window of time before the APPROTECT fuse is used by the hardware to disable the port and reset were the port might be accessible?
2. For the DCNF that blocks the network core from reaching the app domain, are those registers only accessible from the network domain? Is there a way for the app core to block traffic from the network domain?

[Einar Thorsrud]

Hi,

What is the state of the debug port on reset? Is there a window of time before the APPROTECT fuse is used by the hardware to disable the port and reset were the port might be accessible?

The default state of the debug port on reset is that debug access is disabled/locked. It will only be subsequently enabled/opened when certain criteria are met:

• Magic word is written to NRF_UICR_S->APPROTECT in the persistent User information configuration registers (UICR) and firmware allows enabling the debug port by writing magic word to CTRL-AP.APPROTECT.DISABLE.
• Temporarily after a CTRL-AP.ERASEALL operation.

The configuration is independent for the network core an application core but handled in the same way. There are corresponding registers to those already mentioned that apply to the application core secure domain. This is described in more detail under Access port protection.

For the DCNF that blocks the network core from reaching the app domain, are those registers only accessible from the network domain? Is there a way for the app core to block traffic from the network domain?

The application core DCNF is able to block traffic from network core, using the application core's DCNF peripheral and the EXTPERI/EXTRAM/EXTCODE registers.

The following figure (Figure 26 from the nRF5340 product specification) shows the input connections to the AMLI from the network core. It is the EXTPERI[0], EXTRAM[0] and EXTCODE[0] registers that can be configured to prevent the network core accessing the application core ports.

If more precise access control is required, it is possible to use the Arm TrustZone security features of the nRF5340. E.g. by configuring the network core to be a non-secure domain, the System protection unit (SPU) provides configuration registers to grant access from network core only to peripherals and memories configured as non-secure.

[mrrosen]

For the first question. I want to make sure I understand the APPROTECT UICR and the CTRL-AP.APPROTECT.DISABLE registers. By default, APPROTECT is disabled correct (ie, it is not disabling the debug port)? I thought it was but the document changed suggesting otherwise (https://infocenter.nordicsemi.com/topic/ps_nrf5340/chapters/uicr/doc/uicr.html?cp=3_0_0_4_3_2_0_0#register.APPROTECT). Also, once enabled in the UICR, the CTRL-AP.APPROTECT.DISABLE overrides the UICR, correct? Or is this a separate register that must be set by the firmware to enable the debug port at all? If so, what happens when you do a complete chip erase and reset the chip, is it bricked since there is no firmware to write to the register?

For the second question, I understand we need to write to the EXTPERI/EXTRAM/EXTCORE registers but those seemed to be mapped to the network core domain (so on the APB in the network side), not the application core domain, meaning the application core cannot access them, correct? (https://infocenter.nordicsemi.com/topic/ps_nrf5340/dcnf.html?cp=3_0_0_6_7_0#concept_protection)

[Einar Thorsrud]

Hi,

mrrosen said:

By default, APPROTECT is disabled correct (ie, it is not disabling the debug port)?

No, that is not correct. By default APPROTECT is enabled, as the magic word it not written to either the APPROTECT UICR and the CTRL-AP.APPROTECT.DISABLE registers. For instance, after a full erase, the UICR register is all FF's (it's flash). 

mrrosen said:

Also, once enabled in the UICR, the CTRL-AP.APPROTECT.DISABLE overrides the UICR, correct?

No. APPROTECT must be disabled both in UICR and CTRL-AP.APPROTECT.DISABLE. If the magic word is not present in both registers, APPROTECT will stay enabled, preventing debugger access.

mrrosen said:

If so, what happens when you do a complete chip erase and reset the chip, is it bricked since there is no firmware to write to the register?

No, this is handled by a special case. As stated in the Access port protection section in the PS:  "The access port is also open after the completion of the CTRL-AP.ERASEALL operation. After completing the erase operation, CTRL-AP will temporarily unprotect AHB-AP".

mrrosen said:

but those seemed to be mapped to the network core domain (so on the APB in the network side), not the application core domain, meaning the application core cannot access them, correct?

Not exactly. You can see from the Registers section in the DCND chapter in the PS that there are three instances of all the registers, with separate base addresses for application secure domain, application non-secure domain and network. (Except EXTCODE, which does not exist for the network core).

[mrrosen]

For the DCNF question, I now see what you mean; thanks, I was misreading the note thinking those registers were only accessibly from the network domain, not that they were not accessible from the network domain.

For the APPROTECT, doesnt APPROTECT need to be disabled in order to flash the chip? If so, if its enabled by default, without doing a ERASEALL, how can you program the device (isnt the AHB-AP access needed to write to the flash)? Also, while the ERASEALL enables the AHB-AP, once the device loses power or preforms a hard reset, the APPROTECT would be 0xFFFFFFFF, thus disabling AHB-AP and making the chip unflashable, correct? And even if APPROTECT isnt in a state disabling the AHB-AP, if firmware is also required to enable the AHB-AP, wouldnt the chip be unflashable still? (Sorry for the misunderstanding, I might just be getting tangled up with the APPROTECT disabled means the the AHB-AP is enabled)

[Einar Thorsrud]

Hi,

The new APPROTECT scheme is a bit complicated, so I understand the confusion.

mrrosen said:

For the APPROTECT, doesnt APPROTECT need to be disabled in order to flash the chip?

 Yes.

mrrosen said:

If so, if its enabled by default, without doing a ERASEALL, how can you program the device (isnt the AHB-AP access needed to write to the flash)?

You cannot program an empty device without first doing an ERASEALL.

mrrosen said:

Also, while the ERASEALL enables the AHB-AP, once the device loses power or preforms a hard reset, the APPROTECT would be 0xFFFFFFFF, thus disabling AHB-AP and making the chip unflashable, correct?

Yes that is correct, unless you have written to UICR and flashed firmware that unlocks debugging. 

mrrosen said:

And even if APPROTECT isnt in a state disabling the AHB-AP, if firmware is also required to enable the AHB-AP, wouldnt the chip be unflashable still?

Yes, that is correct if you do a power cycle, reset or detach and reattach the debugger before attempting to program. A key here is that the normal condition for disabling APPROTECT (disabled in both UICR and CTRL-AP.APPROTECT.DISABLE) does not apply after an ERASEALL. When the IC is in a state where ERASEALL has occurred and there has been no reset and the debug session is active, you can program it.

The result of this is that in order to flash a device you must issue an ERASEALL, and then at the same time program the firmware. If you want to be able to subsequently debug, the you must enable APPROTECT in UICR while programing, and flash a piece of firmware that enables debugging by writing to CTRL-AP.APPROTECT.DISABLE. (For instance using nrfjprog, this is how it is doen behind the scenes when you call nrfjprog with the --recover option with a nRF5340 Engineering D or Rev 1 SoC.)

[mrrosen]

Thanks, that all makes sense. Then, writing to UICR.ERASEPROTECT will disable the ability to ERASEALL, and also, if APPROTECT is enabled as it is by default, will be unable to read/write to the flash via the debug port ever?

[Einar Thorsrud]

Hi,

Yes, with one reservation. Combining APPROTECT and ERASEPROTECT can be used to permanently prevent prevent re-programming as well as debugging. But note that you may use firmware that allows an erase operation also in this case, by providing a key as described under Troubleshooting in nAN-41:APPROTECT and ERASEPROTECT are enabled (this is for the nRF9160, but same applies to the nRF53 in this regard).