Getting into Cellular and security with nRF9160

[zazas321]

Hello. I am just getting into nRF and in particular cellular devices.

After playing around with nRF9160DK, I have come up with a number of questions that is not fully clear to me. I would appreciate if someone could help me with the questions 

1. I am particularly confused about multi image builds:

Is that something that happens behind the curtains when you select nRF9160DK as build target? Or do I need to manually configure my project for multi image build? I have followed lesson 2 in cellular IoT and I was able to build the simple application without enabling any of the configurations for the multi image and TFM.

Can I build just a single image (normal application as I usually do) for the nRF91? Or nRF91 strictly requires multi image builds to function properly?

2. Understanding TF-M

I have read through:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/security/tfm.html#ug-tfm

But it is still quite difficult to fully grasp why I would want to use it and what are the exact use cases where this is required? Perhaps you could suggest some reading material or could help me understand it further? How do I decide if I need this in my application or not? What are the differences between normal application and TF-M application from a normal user point of view and from a developer point of view?

3.The basic usage of nRF91

I am quite new to Cellular and LTE technology, but I had a chance to play with Quectel BG95 modem. From what I have learned, normally when you are interacting with Modem, you rarely need to flash any firmware to the modem (it comes with factory firmware that you can control with AT commands), and you normally use AT commands to communicate with the modem through host MCU. From what I understood, that is not exactly the case with the nRF91. In order for the Modem to respond to any AT commands, you still need to flash some application (such as serial LTE Modem application) or some other application. Is my understanding correct?

For example, I have tried to build and flash sample project zephyr\samples\tfm_integration\tfm_secure_partition

The serial terminal prints:

*** Booting nRF Connect SDK v2.5.0 ***
Digest: be45cb2605bf36bebde684841a28f0fd43c69850a3dce5fedba69928ee3a8991
Digest: 1452c8f04245d355722fdbfb03c69bcfd380b7dff911a3e425013397251f6a4e
Digest: d3b4349010abb691b9584b6fd6b41ec54596ef7b98d853fb4f5bfa690f50f222
Digest: 5afbcfede855ca834ff5b4e8a44a32206a51381f3cf52f5001a3241f017ac41a
Digest: 983318380c325099da63de2e7ca57c1630693b28b4754e08817533295dbfcfbb
No valid secret for key, received expected error code

I do not understand the relevance of this sample project? What is it intended to show? What could be the real world use for this sample?

[Øyvind]

Hello, 

As mentioned in lesson one of the Cellular IoT fundementals course, the nRF9160 has two domains, the secure and non-secure domain. 

At boot-up, the application always starts execution from the secure domain. From there, the Trusted Firmware-M (TF-M) is started (image one), which will configure part of the memory and peripherals as non-secure and then jump to the main application (image two) in the non-secure area.

This is all automated by the nRF Connect SDK when building your application for the non-secure domain. As you can see from the figure, the modem library, which interfaces with the LTE modem, is defined in the non-secure domain. Therefore, when building for the nRF9160, you should always build for the non-secure domain.

All nRF9160 applications (the parent image) require Trusted Firmware-M (the child image) to be programmed together with the actual application. When building an application for the non-secure domain, TF-M is automatically included as the child image, making it a multi-image build.

In your case, as you are new to this, I would recommend not thinking about the TF-M child image at this stage as it is automatically included. More information on secure build can be found under Build targets in our documentation. If you feel something is not covered or missing in course, please leave feedback in Feedback button on DevAcademy.

Have a look at our documentation for Working with the nRF91 series, and please test the Cellular samples in our nRF Connect SDK. We also have Precompiled application and modem firmware packages which includes our most used samples and applications to test with your development kit. These are found in the Downloads tab of the nRF9160DK product page. 

Kind regards,
Øyvind

[zazas321]

Thank you for your quick reply. Before we close this ticket, i would like to explain a scenario and I would like you to confirm this to ensure I understand this correct.

I could use TF-M and multi image in the following scenario:

Lets say I want to use MQTT TLS with the nRF91DK. TLS requires a certificate that I want to protect.

Normally, I would just include the certificate in the header file and just use it. That is a security vulnerability since everyone who have access to firmware hex file could extract the certificate if they put some effort ( it would not be easy because the certificate normally is a bunch of random characters) but this data would be somewhere within plain sight in the hex file I think.

1. By using the secure image, I can place the certificate there and just make the special API calls to get the credentials when needed. Is that how it works?

2. How does the merged hex file look like in that case? Does it hash the whole part of secure image to ensure is not availae to extract any information from it?

3. Can you recommend which sample project would be best suited for example that I have explained above? In the NCS sample directory there is quite a few different security and TF-M samples available. I can fully decide which one would suit my particular application best

I would appreciate if you could respond to each of my questions one by one. That way it would be very clear for me. Thanks!

[Håkon Alseth]

Hi,

 

zazas321 said:

1. By using the secure image, I can place the certificate there and just make the special API calls to get the credentials when needed. Is that how it works?

Certificates are stored in the modem, and you access them by referencing the specific security tag where you initially stored the credentials.

I think your questions are valid, like for instance this one:

How do I decide if I need this in my application or not?

The answer to this question is based on the nRF9160 hardware model.

The modem can only communicate with the application in a "non-secure mode", and the default boot-up mode for a Cortex M33 CPU core is "secure mode".

 

This means that if you want to use the modem, you have to do this in the non-secure mode, ie. with board "nrf9160dk_nrf9160_ns" (or other equivilant board _ns prefix'ed).

 

I hope this clarifies the reason why everything for nRF9160 will include TF-M.

 

That being said; you have several image sizes (feature sets) for TF-M. If you need crypto-acceleration in your application space, this will effectively be a non-secure callable function to the secure part.

 

Now, to answer your question directly: Where does the credentials go?

Normally you provision your device from a 3rd party, like a computer in production (or a webservice for that matter) - this way, credentials are never stored in the .hex, but rather fetched and stored into the modem from an external source.

zazas321 said:

2. How does the merged hex file look like in that case? Does it hash the whole part of secure image to ensure is not availae to extract any information from it?

You reference the sec_tag where you initially provisioned the certificates - they're now stored in the modem itself.

You can program the specific tag using our tools, for instance in nRF connect for desktop - Cellular monitor (PC application):

This takes in a certificate, and wraps it around the AT%CMNG call to write it into the modem itself.

zazas321 said:

3. Can you recommend which sample project would be best suited for example that I have explained above? In the NCS sample directory there is quite a few different security and TF-M samples available. I can fully decide which one would suit my particular application best

at_client can take in AT commands via uart.

If you want to use a CLI based tool, you can look at this blog post:

 Automating nRF91 TLS credential management via serial port AT commands 

And also this project:

https://github.com/NordicSemiconductor/nrfcredstore

 

Kind regards,

Håkon