Hello, I am interested on nordic devices that support:
1) 802.15.4 (eg. Openthread)
2) secure storage for storing keys (e.g LWM2M credentials)
3) zephyr - rtos
I have seen the 1)nrf9160dk which has not 802.15.4 radio but according this SPU is supported, 2) nrf9160 dk - nrf52840 with 802.15.4. radio but there is nothing about SPU. Does SPU applies to secure storage too? Any other options?
Thank you
Hi,
The only Nordic device that has both a 80215.4 radio and a key management unit is the nRF5340. This also has a SPU (as part of the Arm TrustZone support).
The nRF52840 has some security features, but no KMU nor an SPU. However, it does have a volatile secure key storage inside the CC310 peripheral, and ability to protect flash using ACL, so it may be good enough depending on your requirements.
Really fast reply. Thanks. As I can see in zephyr rtos documentation there are two types nrf5340dk_nrf5340_cpuapp and nrf5340dk_nrf5340_cpunet. The first mention about SPU but nothing about Radio and the second mention Radio but nothing about SPU. What are the differences? I don't think that these two are different devices.
Nikos Karamolegkos said:So I could just use the KMU to store in a secure way my keys without, let's say, tricks like in nrf52840?
Yes, you can. Note that the nRF53 does not have secure flash though, so it would probably be possible to extract the key by decapping and probing directly on the die. You can read more about the KMU features in the KMU chapter in the PS. If that is part of your thread model, then the only option is to use a secure element, but in most products that would be overkill.
Nikos Karamolegkos said:Also, does this device have any unique identifier?
Yes. The DEVICEID in FICR is a 64 bit random number generated in production. Given the size of the numbers they are unique for all practical purposes.
Oh nice. The FICR is really useful. I will check how can read this information by my code. As I can see nr52840 supports this too..
Yes, all nRF5 devices has a 64 bit DEVICEID in FICR.
Help with that " nRF53 does not have secure flash though". So somebody can read the flash. Thus, what SPU (as part of the Arm TrustZone support) offers? For my application I need firstly secure storage of some keys (credentials to connect to a server) and secondly, if possible, to avoid reading the entire flash (the flow of my firmware) from a malicious.
Hi,
Nikos Karamolegkos said:Help with that " nRF53 does not have secure flash though". So somebody can read the flash.
Perhaps I should have been more clear. My point was that unlike secure elements etc. the nRF53 is not a hardened device and do not have tamper protection or similar. If an attacker is willing to pay a good amount of money to decap the IC, he would be able to read out the entire memory content, including KMU. This is outside of the threat model for the nRF53.
Nikos Karamolegkos said:what SPU (as part of the Arm TrustZone support) offers?
The KMU offer secure key storage in the sense that it can be configured to for instance prevent readout of the key, and only allowing it to be pushed to the CryptoCell peripheral for crypto operations, without ever being part of the system memory. Therefor, there would be no way to access the key via code or debug interface.
The SPU handles separation of memory and peripherals between secure and non-secure region. So that non-secure code will not be able to access anything that is allocated to secure region only. This can be utilized in several ways to reduce the attack surface etc.
Nikos Karamolegkos said:For my application I need firstly secure storage of some keys (credentials to connect to a server) and secondly, if possible, to avoid reading the entire flash (the flow of my firmware) from a malicious.
There is no such thing as complete security. How secure does your product need to be? The reason I mentioned this is that if it is not acceptable that an attacker willing to spend a good sum of money to pay a lab to decap and extract memory, then it is good to know. But for most products that is an acceptable risk.
Hi,
Nikos Karamolegkos said:Help with that " nRF53 does not have secure flash though". So somebody can read the flash.
Perhaps I should have been more clear. My point was that unlike secure elements etc. the nRF53 is not a hardened device and do not have tamper protection or similar. If an attacker is willing to pay a good amount of money to decap the IC, he would be able to read out the entire memory content, including KMU. This is outside of the threat model for the nRF53.
Nikos Karamolegkos said:what SPU (as part of the Arm TrustZone support) offers?
The KMU offer secure key storage in the sense that it can be configured to for instance prevent readout of the key, and only allowing it to be pushed to the CryptoCell peripheral for crypto operations, without ever being part of the system memory. Therefor, there would be no way to access the key via code or debug interface.
The SPU handles separation of memory and peripherals between secure and non-secure region. So that non-secure code will not be able to access anything that is allocated to secure region only. This can be utilized in several ways to reduce the attack surface etc.
Nikos Karamolegkos said:For my application I need firstly secure storage of some keys (credentials to connect to a server) and secondly, if possible, to avoid reading the entire flash (the flow of my firmware) from a malicious.
There is no such thing as complete security. How secure does your product need to be? The reason I mentioned this is that if it is not acceptable that an attacker willing to spend a good sum of money to pay a lab to decap and extract memory, then it is good to know. But for most products that is an acceptable risk.
Thank you. Yes for me is acceptable too. I just want to store the keys securely without maximize the cost. Therefore, compared to this I am looking for the best option. For now, I have some nrf52840-dk devices and I am wondering if it's worth investing in something else (like nrf53) which may offers something more at a reasonable cost
I see. The nRF5340 has more security features than the nRF51840, so it may be sensible. Most importantly the nRF52840 lack a KMU and SPU.
