nRF52840 Security Discussion

[Omnigamer]

Hello,

I'm trying to get an idea of the level of security provided by various security features described in the nRF52840 specification and several of the application notes. I'm hoping to get a bit more insight on how some protections work. Though they aren't published often, some other MCU manufacturers have had advertised security features compromised, and I'm trying to get an idea of how susceptible this part might be to similar attacks. My end goal is to determine whether the protections offered by the nRF52840 are sufficient for my application or if I should plan for including additional security ICs.

• What is the actual mechanism that prevents the debugger from accessing the AHB when APPROTECT is enabled? In documentation it appears as a disconnected line. Is it made by some sort of gate, or is it enacted by some microcode on system boot before reaching user bootloader?
• Is there a way to disable the TPIU/ETM/ITM? Can the flash patch and breakpoint unit be disabled? Specification isn't clear on whether disabling debug disables these units as well.
• Is there any conflict with using the MPU and ACL concurrently? It seems they cover RAM and flash respectively, but I'd just like to confirm they won't have issues with one another.
• Are there any in-system options for quickly erasing RAM outside of explicitly overwriting address contents individually?
• Communicating with the CC310 portion of the system using the crypto library is shown to use some amount of RAM. Are those addresses explicitly cleared after use? Do any of them place data on the stack? Is it possible to know which ranges those addresses occupy, so they can be protected with the MPU or otherwise?
• ERASEALL is a mechanism to clear all flash memory on the system, including UICR. I am curious how it actually functions. Are flash banks erased sequentially or all at once? If sequentially, which banks are first? Does ERASEALL explicitly clear RAM as well or is it assumed that RAM is cleared on reset?

I understand that some of the answers to the above may involve trade secrets, but I'm interested in whatever information can be shared publicly. I may also misunderstand how some system features function, so please correct me if so. If nothing else, I hope there can be a good discussion about using nRF products for secure applications.

Thanks,

~Omni

[Susheel Nuguru]

Below are answers to your questions

What is the actual mechanism that prevents the debugger from accessing the AHB when APPROTECT is enabled? In documentation it appears as a disconnected line. Is it made by some sort of gate, or is it enacted by some microcode on system boot before reaching user bootloader?

Debugger access to the system is disabled by default in hardware. Any value in UICR->APPROTECT other than 0xFFFF_FFFF will keep the debugger disabled. If the value 0xFFFF_FFFF is present in this address location, the hardware will automatically enable debug access during the power-on sequence before taking the CPU out of reset. There is no microcode or bootloader involved in enabling debug access.

Is there a way to disable the TPIU/ETM/ITM? Can the flash patch and breakpoint unit be disabled? Specification isn't clear on whether disabling debug disables these units as well.

On nRF52840 you can control this from UICR->DEBUGCTRL, where there are individual fields for disabling FPB and non-intrusive debugging features like e.g. trace. Intrusive debugging features are tied to UICR->APPROTECT, so enabling APPROTECT will consequently disable intrusive debug features in the CPU as well.

Is there any conflict with using the MPU and ACL concurrently? It seems they cover RAM and flash respectively, but I'd just like to confirm they won't have issues with one another.

No conflict between these two, and as noted they complement each other. But there is a subtle difference; ACL can be configured to block all R/W requests regardless of which master initiate the transaction, while the MPU only blocks transactions initiated by the CPU. This means that the MPU cannot guard against a malicious thread that uses e.g. EasyDMA to read or modify data outside of the boundary configured by the MPU. ACL on the other hand does not distinguish between this (but then again there is no DMA access to flash in nRF52 series, so in practice this is of no consequence).

Are there any in-system options for quickly erasing RAM outside of explicitly overwriting address contents individually?

There is no in-system option for quickly erasing RAM. The RAM content needs to be explicitly overwritten with the value zero. E.g. disabling and re-enabling the SRAM is not enough, and you might see retention effects on the RAM content if you try this.

Please note that if a CTRLAP->ERASEALL is requested from the debugger side, then all internal memories will be erased automatically. First the flash main region is erased, then the internal SRAM and finally UICR. If the erase sequence is interrupted the ERASEALL request will need to be re-started from the debugger side.

 

Communicating with the CC310 portion of the system using the crypto library is shown to use some amount of RAM. Are those addresses explicitly cleared after use? Do any of them place data on the stack? Is it possible to know which ranges those addresses occupy, so they can be protected with the MPU or otherwise?

The CC310 crypto library will automatically zeroised sensitive data stored in RAM after use. It is possible to protect the stack from overflowing using the MPU.

ERASEALL is a mechanism to clear all flash memory on the system, including UICR. I am curious how it actually functions. Are flash banks erased sequentially or all at once? If sequentially, which banks are first? Does ERASEALL explicitly clear RAM as well or is it assumed that RAM is cleared on reset?

 ERASEALL only erases flash and UICR and not the RAM contents. It really should not matter if the erase is happening sequentially or in some other order since the CPU is halted during the process if it is executing code from the Flash. 

Hope these answers your question Omnigamer.

[Omnigamer]

Thank you, that does clarify things quite a bit! I understand that answers for zeroization, FPB disable, cryptocell library operations, and ERASEALL.

Regarding the debug disable mechanism, I'm interpreting that as some sort of enable signal based on an AND of all bits in the APPROTECT. Is that a fair characterization, or is there something else happening before the processor comes out of reset?

I am not clear on the extent of MPU protections from your answer, or possibly I am just not clear on how the MPU is intended to be used. If I'm understanding right, you suggest that an EasyDMA read/write region can be configured for a peripheral from privileged code and protected at a privileged level. But then unprivileged code could exercise the peripheral, and those regions would still be read/written by the peripheral? Or is it a different case that unprivileged code can set up an EasyDMA region anywhere in RAM regardless of MPU protections, some configurations of which would allow readback?

[Susheel Nuguru]

Omnigamer said:

Regarding the debug disable mechanism, I'm interpreting that as some sort of enable signal based on an AND of all bits in the APPROTECT. Is that a fair characterization, or is there something else happening before the processor comes out of reset?

 This is a decent characterization to be understood. Nothing fancy in terms of the startup is happening before the processor comes out of reset.

Omnigamer said:

But then unprivileged code could exercise the peripheral, and those regions would still be read/written by the peripheral?

Normally, if the peripheral is accessing privileged memory sections, then the peripheral itself could be placed in privileged mode, in a way that a non privileged code cannot initiate or configure the EasyDMA. Any attempts of non privileged code trying to configure such peripheral's EasyDMA would then create a hardfault.