Why would one use non-secure memory regions

[Frikkie Badenhorst]

Hi there, 

According to our understanding, on CPU reset the entire core is set to the secure except for non-secure peripherals. Is this understanding correct?

We are trying to figure out why one would want to use non-secure regions at all, instead of just running the entire application as secure, which is the default at CPU reset above. Is it possible to provide is with some simple use cases just so that we can better understand this?

Kind regards,

Frikkie

[Sigurd Hellesvik]

Security by Separation (Secure and Non-secure)

Applications running on microcontrollers are made up of multiple different parts.
These parts use different peripherals, modules and areas of flash/RAM.

To increase security, the application can be separated into two different parts, with a "wall" between, referred to as Security by Separation.
One side is called Secure and the other is called Non-Secure. See figure below, found under "Trusted Base System Architecture for M" from the Arm Developer site for Platform Security, Figure 2. You can also read more about the concept at this link, in chapter 3.1 Security by Separation and onward.

To build with this separation, Secure Partition Manager (SPM) or TF-M needs to be added to the application.

When building for boards with the postfix "_ns",  a SPM child image is automatically added.
When building for boards with the postfix "_ns" and using "BUILD_WITH_TFM=y" configured,  a TF-M child image is added instead.

The secure partition is often refereed to as Secure Processing Environment (SPE).
The non-secure partition is often refereed to as Non-Secure Processing Environment (NSPE).

A common misunderstanding is from the naming of the builds. For example from Working with nRF9160 DK:

nrf9160dk_nrf9160 for firmware in the secure domain

nrf9160dk_nrf9160_ns for firmware in the non-secure domain

If your firmware is in the secure domain, everything in your application will be in the same domain, and you will not have Security by Separation.
If your firmware is in the non-secure domain, it will be separated from the secure domain, and you will have Security by Separation.
Therefore, it is more secure to build for non-secure boards, such as nrf9160dk_nrf9160_ns.

Does this answer your questions?

Regards,
Sigurd Hellesvik

[Frikkie Badenhorst]

Hi Sigurd,

Thanks for your response, however I am not sure my question is answered.

Sigurd Hellesvik said:

To increase security, the application can be separated into two different parts, with a "wall" between, referred to as Security by Separation.

Sigurd Hellesvik said:

To build with this separation, Secure Partition Manager (SPM) or TF-M needs to be added to the application.

What if we do not add this separation? The entire core will then be in the secure domain right, as this is the default when the CPU reboots?

Why would one want to use non-secure firmware, if everything can be secure?

[Sigurd Hellesvik]

Hi

If everything is in the secure domain, you do no longer have Security by Separation.

If you have everything in one domain, I would argue there is no longer a Secure Domain, since the reason the Secure Domain is named secure is that it is not the Non-Secure domain.

Personally, I think the naming Secure Domain and Non-Secure domain can be misleading sometimes.
Try to think of it as Security by Separation.

Use-case example:
Not realistic for the use of nRF9160, but I think it gets the point across.

I have a nRF9160 which is connected to my web-server.
Say this nRF9160 is controlling something which could be dangerous, such as an elevator using UART.

If my web-server get compromised, the Attackers can reach my elevator.
Now the attackers could use the UART connection to control the elevator directly, for example making it go very fast. That would be bad.

To defend against this, I separate the web-server communication from the rest of my device.
Now the web-server communication is in its own separate partition, and can not access the UART.

Then I make an API in the UART-partition, with functions like goto_floor_one() and stop_elevator().
Now if attackers get access to the webserver, and the device, they can only reach the web server communication partition, and all they can do are my predefined safe actions.

In this example, the "webserver communication partition" would be what we call the non-secure domain.

Did this make sense to you?

Regards,
Sigurd Hellesvik

[mrono]

Sigurd Hellesvik said:

I think the naming Secure Domain and Non-Secure domain can be misleading sometimes.

In the picture attached to the first reply, at the bottom the parts are called Trusted World and Non-Trusted World. I think this conveys the meaning better.

[Frikkie Badenhorst]

I see... so essentially the secure domain is not secure if there is not a non-secure region...

If a hacker gains access to your system and ALL firmware is running on the secure domain, he will still be able to control the elevator even though it is in the "secure domain"? Is this understanding correct? I can see where the confusion comes from.

What other security features are there that we can use in order to prevent someone from accessing our firmware? For example most chips I know, has a lock bit which you can write, and when set, you can only connect with a debugger after erasing the chip.

[Sigurd Hellesvik]

Hi

Frikkie Badenhorst said:

If a hacker gains access to your system and ALL firmware is running on the secure domain, he will still be able to control the elevator even though it is in the "secure domain"? Is this understanding correct? I can see where the confusion comes from.

Yes, from what you write it looks like you understand the example.
To learn the technical details on the topic, I recommend that you have a look at the Arm Developer site for Platform Security.

Frikkie Badenhorst said:

What other security features are there that we can use in order to prevent someone from accessing our firmware? For example most chips I know, has a lock bit which you can write, and when set, you can only connect with a debugger after erasing the chip.

I think what you are looking for here is the access port protection mechanism.
For 52 Series, also see our recent blogpost: Working with the nRF52 Series' improved APPROTECT.

Regards,
Sigurd Hellesvik