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

[Konrad Traczyk]

Thanks for your answer. We're preparing our device for production, so we're searching for the way to protect it in every possible way. Thanks for some useful guidelines how to achieve that. As far as I understood, you are writing about entire program erase and reflashing. But is possible the scenario, that someone flashes a piece of his own code somewhere in the device, which will dump the memory from flash on the SPI lines and read the valuable data stored in the device and forces it to execute?

[endnode]

That's what I've tried to say (and what I believe product specification describes clearly): NO, you cannot "flash a piece of code somewhere to the device flash" once you enable readback protection (UICR->RBPCONF register set to ALL = 0xFFFF00FF). The only way how to flash the code over SWD is to erase entire chip (again through UICR registers) and then flash it with your own code (but entire flash is set to default 0xFF..FF value at that moment so you cannot see the previous FW). However this is theory and in practice there are some (less comfortable but known and documented) ways how to defeat such a chip:

(1/2 - continue)

[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

[energy]

Hi, I search on the net and found out quickly how to dump the memory ! That's crazy Is this problem still in last revision nRF51822 chips ?

We don't need protection against reflashing but against dumping our code. We're thinking of stopping our production launch because of this problem. We can't affort cheap HW copy of our product with our software on them ...

Is the nRF52 better protected or also have such dramatic flaw ?

Thanks