How to protect chip from reflashing

[Konrad Traczyk]

Lets say, that I've got a chip with program in its flash. I know I can protect it from being read back, but can I protect it from flashing anything else through debugger interface? The thing I want to achieve is to disable the possibility of "program injection" which would steal the data.

[endnode]

Hi Konrad,

It's true that you cannot by SW (= through registers) prevent erasing the chip and programming again (which saves a lot to SW guys who don't have time and budget to build custom HW - just pick some nRF5x based product with accessible JTAG/SWD on eBay/Aliexpress/anywhere and "hijack" it for your project - I know what I'm taking about;). However by design there should be no way how to "inject" the code and dump the memory. The only way to work with such a "locked" chip is to erase the flash (+UICR) and just benefit from the HW but not original FW.

It's true that nRF51x22 has weaker read back protection and there already exists pretty detailed guidelines on the internet how to dump the FW (with a bit of luck and knowledge of SWD&OCD). However that particular attack isn't real program injection but rather problem with CPU registers being accessible (JTAG/SWD debugger isn't killed completely when read back protection is ON). So if you are really concerned about your FW reverse engineering then you should go with nRF52 which has this bug fixed (of course nRF5x isn't meant to be temper resistant HW so you should have in your HW separate IC - e.g. some smart card chip - to hold all your secrets and also perform all sensitive operations if possible). On nRF51 I can imagine only some HW ways how to make the attack more difficult (e.g. by shorting the SWD lines after production testing, using "hard" casing - e.g. complete plastic or epox shield - or similar). However if your FW is really valuable to the attacker then he can carefully extract the chip from PCB and explore the SW vulnerability anyway.

Cheers Jan

[endnode]

(2-2)

• Explore bugs/vulnerabilities in your FW (e.g. allowing to use your OTA DFU to write new code into the flash - remember that access to NVM from FW code isn't restricted by RBPCONF unless you use REGION 1&0 division).
• Explore bugs in SWD implementation by Nordic.
• Invasive methods which will access NVM controller inside the silicon (traces) - this is very expensive but achievable on 180nm technology which nRF51 is using.
• Probably others...

As I said using nRF5x for storing some hard secrets (e.g. cryptographic keys which should protect some valuable property such as car/house/banking account/etc.) is stupid idea, for heart rate monitor (including your super smart FW and IP in it;) it's probably OK (your product will be very likely outdated earlier then anyone would bother with HW and SW copy of it...)

Cheers