Software Security of NRF52832

RE: Software Security of NRF52832

manoj12345 — Thu, 19 Dec 2019 13:26:38 GMT

RE: Software Security of NRF52832

Simonr — Thu, 19 Dec 2019 13:22:23 GMT

We are starting to move off-topic from software security now. Please create a new support ticket for these issues, as we strive to keep each ticket to one subject to make it easier for people with similar problems in the future to find what they're looking for.

Best regards,

Simon

PS: The Holiday season is upon us, which will leave us understaffed until January 6th, 2020, so delayed replies will occur during this time. Sorry for the inconvenience and happy Holidays!

RE: Software Security of NRF52832

manoj12345 — Thu, 19 Dec 2019 12:26:07 GMT

okay thank you so much. Two more things simon,

1. Will nrf52 will only get connected to apps provided by nordic? I want to it to get connected to serial blueooth terminal which is not happening.

2. How to implement serialization.

RE: Software Security of NRF52832

Simonr — Thu, 19 Dec 2019 08:22:17 GMT

We don't have any examples implementing APPROTECT, as that would cause the device to have to recover every time it is flashed, but there are two rather simple ways of implementing it. Either, you can set it in your application code like my colleague explains in this thread. Or, you can download nrfjprog on your computer and enable APPROTECT by calling the command nrfjprog --rbp all in a command window when your device is connected. In both cases, you will have to recover the chip/ do a full chip erase in order to access the memory of the chip.

Yes, anyone with a debugger will be able to erase the flash of your device, unless you remove that option by not connecting the debug pins. I assume you won't be reprogramming the device when it's released.

Best regards,

Simon

RE: Software Security of NRF52832

manoj12345 — Wed, 18 Dec 2019 11:52:13 GMT

The whole flash can be deleted by any one who have programmer/debugger right ?. I only should have access for that. Also is there any reference code available in which this is APPROTECT is implemented ?

RE: Software Security of NRF52832

Simonr — Wed, 18 Dec 2019 11:39:25 GMT

By using APPROTECT, no one will be able to read the memory on your chip, as the only way to disable it will be to delete the whole flash, which will delete your application as well, which is what makes this a safe way to protect the memory on your device.

Best regards,

Simon

RE: Software Security of NRF52832

manoj12345 — Wed, 18 Dec 2019 08:57:29 GMT

OK. But I don't want anyone else to disable the protection except me.

RE: Software Security of NRF52832

Simonr — Wed, 18 Dec 2019 07:51:36 GMT

APPROTECT (Access port protection) blocks the debugger from read and write access to all CPU registers and memory-mapped addresses and can only be disabled by issuing an ERASEALL command via the CTRL-AP.

BPROT (Block Protection) is a mechanism for protecting non-volatile memory and can be used to prevent erroneous application code from erasing/writing to protected blocks. Non-volatile memory can be protected from erases and writes depending on the settings in the CONFIG registers. One bit in a CONFIG register represents one protected block of 4kB. On reset, all protection bits are cleared. To ensure safe operation, the first task after a reset must be to set the protection bits.

Best regards,

Simon

RE: Software Security of NRF52832

manoj12345 — Tue, 17 Dec 2019 11:26:37 GMT

Simon I am not able understand the difference APPROTECT and BPROT. Can you please clarify ? and if we enable the protection then how to disable it again whenever we want ?

RE: Software Security of NRF52832

manoj12345 — Tue, 17 Dec 2019 05:58:15 GMT

Ok simon thank you so much. I will get back to you for further queries

RE: Software Security of NRF52832

Simonr — Mon, 16 Dec 2019 14:39:01 GMT

Quote from the blog: "LE Secure Connections is an enhanced security feature introduced in Bluetooth 4.2." This module is not for Bluetooth 4.1, as it was introduced in version 4.2, and is present in version 5 and 5.1 as well. You're right that the module link is better suited once you start development, but the blog link should be a nice introduction to the LE Secure Connections.

Best regards,

Simon

RE: Software Security of NRF52832

manoj12345 — Mon, 16 Dec 2019 13:57:32 GMT

I your last reply https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Fgroup__nrf__ble__lesc.html&resultof=%22%4c%45%53%43%22%20%22%6c%65%73%63%22%20. it just the information of the statements used regarding LESC. It doesn't tells how it works.

One more thing, is LESC module is only for Bluetooth 4.1. because in the blog https://www.bluetooth.com/blog/bluetooth-pairing-part-4/ it is mentioned liked that.

RE: Software Security of NRF52832

Simonr — Mon, 16 Dec 2019 13:49:38 GMT

I linked to the LESC module in my last reply with this link https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Fgroup__nrf__ble__lesc.html&resultof=%22%4c%45%53%43%22%20%22%6c%65%73%63%22%20. You can also check out this thread from the official Bluetooth blog: https://www.bluetooth.com/blog/bluetooth-pairing-part-4/

RE: Software Security of NRF52832

manoj12345 — Mon, 16 Dec 2019 13:32:41 GMT

can you refer me any document or link to study about LESC

RE: Software Security of NRF52832

manoj12345 — Mon, 16 Dec 2019 13:12:09 GMT

Ok. I want know what is this LESC before peeping into the code

RE: Software Security of NRF52832

Simonr — Mon, 16 Dec 2019 12:38:01 GMT

Hi Manoj

There are multiple ways to ensure the safety of your data during Bluetooth communication. I suggest you check out the ble_app_hrs and ble_app_hrs_c examples, which uses the LESC module and bonding to keep the data safe.

Best regards,

Simon