What precautions can be taken to avoid getting compromised due to the proprietary radio stack?

[Avamander]

In the light of recent news like this one, https://arstechnica.com/information-technology/2018/11/bluetooth-bugs-bite-millions-of-wi-fi-aps-from-cisco-meraki-and-aruba/, I was wondering what precautions could I take to avoid any vulnerabilities in the radio stack from affecting the rest of my application, given that the stacks are all totally proprietary I can't really recompile them with safety measures, what else could I do? Does NordicSemi have some kind of a hardening guide somewhere? 

[haakonsh]

You need to use a secure DFU with a secure bootloader, use the latest version of our SoftDevices, use LE Secure Connections, and enable readback protection. 

The nRF52840 has an ACL — Access control lists that can prevent the CPU from reading and/or writing to a region of flash. ie you can protect you application from getting overwritten by malicious code. The only way to disable the ACL is to reset the device. It's then up to your secure bootloader to enable the ACL and verifying the application before booting it. 

The nRF52840 also has an ARM CC310 cryptocell that enables the MCU to establish a root of trust in a key stored in flash. The secure bootloader can store a key in the CC310s SRAM and use ACL to prevent the CPU from reading the key that is stored in flash. 
The only way to get to this key is an optical read of the flash. 

[Avamander]

But how would one avoid malicious reads of RAM that could be caused by a bug in SDs? Or is that not a risk?

[haakonsh]

All RAM used by the SoftDevice (0x2000000 to APP_RAM_BASE - 1) is protected using the MWU. See section 'Memory isolation and runtime protection ' in the s140 sds

[Avamander]

Thanks for the reply!