nRF9160 Questions related to Immutable, MCUBoot & application

RE: nRF9160 Questions related to Immutable, MCUBoot & application

shibshab — Wed, 28 Oct 2020 07:23:01 GMT

Good stuff, didn't see your question before now 🙂

RE: nRF9160 Questions related to Immutable, MCUBoot & application

kk2mkk — Wed, 28 Oct 2020 07:19:10 GMT

Never mind i will take it to new thread.

RE: nRF9160 Questions related to Immutable, MCUBoot & application

kk2mkk — Tue, 27 Oct 2020 12:05:26 GMT

[quote userid="6433" url="~/f/nordic-q-a/67024/nrf9160-questions-related-to-immutable-mcuboot-application/275564#275564"]As long as MCUBoot is in the build, you will still have keys in regular flash[/quote]

B0+App is not a workable solution because in this case i lose App upgrade capability which MCUBoot can only do.

Isn't it possible to place the MCUBoot keys in OTP area?

regards

RE: nRF9160 Questions related to Immutable, MCUBoot & application

shibshab — Mon, 19 Oct 2020 10:35:46 GMT

As long as MCUBoot is in the build, you will still have keys in regular flash, as its only B0's keys that are in OTP, so the attack surface does not decrease by adding B0 to a build configuration which already has MCUBoot included. Does that make sense?

The most tamper proof key storage configuration would be B0 - app (unfortunately for you I guess) since then all key material is stored in OTP.

RE: nRF9160 Questions related to Immutable, MCUBoot & application

kk2mkk — Mon, 19 Oct 2020 09:25:06 GMT

Thanks for the clarification, so irrespective what all features the MCUboot & SB provides if your primary concern is to have tamper proof key storage, one should go for B0+MCUBoot+app, right?

regards

RE: nRF9160 Questions related to Immutable, MCUBoot & application

shibshab — Mon, 19 Oct 2020 05:59:30 GMT

You are correct that B0 makes us of the OTP area in the UICR, which require a special argument for the programmer to delete it. This, however, only makes it more difficult for an attacker to tamper with the metadata used by B0, compared to the MCUBoot where the metadata is stored in regular flash alongside the image.

In the NCS fork of MCUBoot there is flash protection in place
https://github.com/nrfconnect/sdk-mcuboot/blob/master/boot/zephyr/main.c#L434

Here MCUBoot use the same library (fprotect) as B0, and hence the flash locking itself should be considered equally safe.

RE: nRF9160 Questions related to Immutable, MCUBoot & application

kk2mkk — Mon, 19 Oct 2020 04:15:04 GMT

[quote userid="6433" url="~/f/nordic-q-a/67024/nrf9160-questions-related-to-immutable-mcuboot-application/274989#274989"]You only need B0 and mcuboot if you have a requirement that the bootloader should be upgradeable (protect against future crypto attacks etc)[/quote]

Are you sure that MCUBoot locks the flash? i dont think so, the reason is when we have B0 in place and when we try to flash new image we need to erase the entire chip to ensure the UICR OTP area is been erased for any flash security, but when we have the MCUBoot as a only bootloader and the we try to flash new image it never ask for full chip erase, is my understanding correct?

regards

RE: nRF9160 Questions related to Immutable, MCUBoot & application

kk2mkk — Thu, 15 Oct 2020 17:56:22 GMT

I was wondering since secure boot and app upgrade features are provided by MCUBoot, do i still need to have an option for MCUBoot upgrade? do you foresee any hard requirement to have mcuboot upgrade...your experience can help me to make a better decision

[quote userid="6433" url="~/f/nordic-q-a/67024/nrf9160-questions-related-to-immutable-mcuboot-application/274989#274989"]I don't follow you, could you explain exactly what you want an example of?[/quote]

Does DFU of the mcuboot and application both can be done using SMP Server approach?

I have issues in building the SMP server sample, better i will take in to different thread.

regards

RE: nRF9160 Questions related to Immutable, MCUBoot & application

shibshab — Thu, 15 Oct 2020 07:24:26 GMT

You can achieve secure boot without b0, in the NCS fork of mcuboot it will lock its own flash area, making it an "immutable bootloader" - which satisfies the secure boot requirement.

You only need B0 and mcuboot if you have a requirement that the bootloader should be upgradeable (protect against future crypto attacks etc)

[quote userid="78215" url="~/f/nordic-q-a/67024/nrf9160-questions-related-to-immutable-mcuboot-application/274930#274930"]I think in question 2 we are discussing about the mucboot upgrade does the same applicable for application upgrade as well? it will great you you could point to some example.[/quote]

I don't follow you, could you explain exactly what you want an example of?

RE: nRF9160 Questions related to Immutable, MCUBoot & application

kk2mkk — Wed, 14 Oct 2020 14:23:19 GMT

I have a requirement to have secure boot, so is it possible without having b0 just with mcuboot+app?

At present we are using SLM application since it needs to be build on non secure mode, i need SPM as well along with my application.

As i also need my application upgrade support i need to have MCUBoot to do that as well, so the bottom line is i should have b0+mcuboot+(smp+app).

Let me go through and try it

[quote userid="6433" url="~/f/nordic-q-a/67024/nrf9160-questions-related-to-immutable-mcuboot-application/274813#274813"]For your use case, if the image is to be transferred over serial, you would need the feature discussed in question 2.[/quote]

I think in question 2 we are discussing about the mucboot upgrade does the same applicable for application upgrade as well? it will great you you could point to some example.

regards

RE: nRF9160 Questions related to Immutable, MCUBoot & application

shibshab — Wed, 14 Oct 2020 08:25:13 GMT

1.
- If you want an upgradeable bootloader you need b0 and MCUBoot (update the thing that updates the app)
- else if you have an application which consists of SPM and app you cannot use b0 - app
- else if you have an app which does not contain SPM you are free to choose between b0 - app and mcuboot - app

2.
- This would be done using smp over UART. Transfer the signed mcuboot image over serial to the secondary slot, and then on the next reboot MCUBoot perform the swap to the alternate b1 slot (s0 or s1).
- See this page for more information on the sample: docs.zephyrproject.org/.../README.html
- Some modifications would be needed for this to be capable of updating MCUBoot in addition to the application.
Specifically, you would need some way of communicating whether you want the MCUBoot candidate linked against slot S0 or S1.
Inspiration for how this is handled elsewhere can be seen here: github.com/.../fota_download.c

3.
- This is the "serial recovery" feature, it can not be done while the application is running. Instead (as you say) it requires some manual action during boot-up so that MCUBoot will start in a special mode.

For your use case, if the image is to be transferred over serial, you would need the feature discussed in question 2.

RE: nRF9160 Questions related to Immutable, MCUBoot & application

Øyvind — Wed, 14 Oct 2020 08:24:04 GMT

Hello KK,

Sorry for the late reply. I am talking with our NCS team to provide an answer for you.

Kind regards,
Øyvind