Implentation of Read-back protection on nRF52840

RE: Implentation of Read-back protection on nRF52840

Sigurd Hellesvik — Mon, 12 Aug 2024 12:50:59 GMT

I think you meant to suggest my answer, so I did that. Let me know if you disagree

RE: Implentation of Read-back protection on nRF52840

Anders Nelson — Wed, 07 Aug 2024 17:49:48 GMT

Suggesting as answer!

RE: Implentation of Read-back protection on nRF52840

clockis — Tue, 11 Jun 2024 12:55:05 GMT

Ok, thank you very much for your immediate responses, this made it so much clearer!

I will test and if nothing else comes up I will be closing this ticket!

RE: Implentation of Read-back protection on nRF52840

Sigurd Hellesvik — Tue, 11 Jun 2024 12:48:38 GMT

Here are some docs:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/security/ap_protect.html

Trying to sum it up

Old devices: HW APPROTECT
New devices: SW&HW APPROTECT

How to enable HW APPROTECT: "nrfjprog --rbp"
How to enable SW APPROTECT: CONFIG_NRF_APPROTECT_LOCK

So for old devices, you can do only the first, and for new devices you should do both

EDIT:
That being said, CONFIG_NRF_APPROTECT_LOCK will just be ignored on old devices, so you can set it for all revisions

RE: Implentation of Read-back protection on nRF52840

clockis — Tue, 11 Jun 2024 12:43:12 GMT

What about revision 2 nRF52840 devices? Is this true for them as well?

RE: Implentation of Read-back protection on nRF52840

Sigurd Hellesvik — Tue, 11 Jun 2024 12:37:05 GMT

[quote user="clockis"]Sorry to get back to this so much later, but I just managed to find the time to get back to this.[/quote]

Welcome back!

[quote user="clockis"]This information you shared is clear, so just enabling CONFIG_NRF_APPROTECT_LOCK=y is enough to enable the readback protection so that third parties cannot read the FW from the nRF52840 if it is a revision 3 chip, if I understand correctly. [/quote]

Since last time I learned that CONFIG_NRF_APPROTECT_LOCK is for half of it, and then you also need to do "nrfjprog --rbp ALL" after.

I am trying to talk our devs into making it so the config does both HW and SW locking

[quote user="clockis"]What is necessary to be done so that it is ensured readback protection is enabled and no one is allowed to read back our FW?[/quote]

nrfjprog --rbp ALL.

So it will be the same for both.

And in general, I recommend that you do testing on some devices to make sure that you indeed can not read anything from them. For example with "nrfjprog --memrd"

RE: Implentation of Read-back protection on nRF52840

clockis — Tue, 11 Jun 2024 12:18:56 GMT

Hi Sigurd,

Sorry to get back to this so much later, but I just managed to find the time to get back to this.

This information you shared is clear, so just enabling CONFIG_NRF_APPROTECT_LOCK=y is enough to enable the readback protection so that third parties cannot read the FW from the nRF52840 if it is a revision 3 chip, if I understand correctly.

What if the chips used are an older revision, for example, nRF52840 revision 2?

What is necessary to be done so that it is ensured readback protection is enabled and no one is allowed to read back our FW?

Thank you very much for your support and I look forward to hearing from you!

Best regards,

Stavros

RE: Implentation of Read-back protection on nRF52840

Sigurd Hellesvik — Wed, 27 Dec 2023 12:48:48 GMT

Hi,

To get the new an improved APPROTECT, you need a newer revision of the nRF52840. From Working with the nRF52 Series' improved APPROTECT :

New revisions of nRF52805 (revision 2, build codes Bx0), nRF52810 (revision 3, build codes Ex0), nrf52811 (revision 2, build codes Bx0), nRF52820 (revision 3, build codes Dx0), nRF52833 (revision 2, build codes Bx0), nRF52832 (revision 3, build codes Gx0), and nRF52840 (revision 3, build codes Fx0) include an improved implementation of the the access port protection mechanism.

With that, CONFIG_NRF_APPROTECT_LOCK enables APPROTECT without the vulnerability you refer to.

Does this answer your question?

Regards,
Sigurd Hellesvik