This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[NRF52833] Secure firmware protection method

Hi everyone,

I have this problem with the firmware protection method in nRF52833. As far as I know, when using secure boot-loader, it can prevent other programmers to flash their own codes to our products without having the public key as well as using the APPPROTECT register to stop the access to debug port . However, this means that every time i need to update the code I have to do it by erase all the code first then flash the whole thing again. This is a little bit too much for me since we produce thousands of unit and if there is any update, the amount of work to Bluetooth OTA them in the field would be tremendous. Also I want to protect our hardware to be used by others.

So I notice that in ESP32 SoC there is a method to secure firmware by flash encryption that is it store encrypting keys inside the SoC in a one time programing block and then the SoC will decrypt the encrypted firmware to run the program (i have tested it in development mode). (it can be seen here  ESP Flash Encryption). So when the key is set, even after a fully erase the flash memory, the eFuse block is till there and other firmware without the key can not be used with the hardware.

So I have 2 questions in mind,

1) Is using Bootloader APP_SIGN_CHECK and APPPROTECT are the only method to protect the firmware? If not can you give me some other methods.

2) Is there a hack or a walk-around to have the equivalent of flash encryption in ESP32? If yes please let me know.

Hope to receive your response soon, good day to you all.

Best regards,

Hoang Ngoc Tu

  • Hi Vidag,

    I do not think that you understand what I ask and the answers you gave me are really vague even when i tried to explicitly explain my situation so I do not think that we should go further but thank you for answering.

    So the final thing I want to confirm is that there is no way for Nordic SoC to have some equivalent function like Flash Encryption like in ESP32. Is it correct.

    Thank you for your time,

    Tu

  • Hi Tu,

    My problem is that we are not doing an apples-to-apples comparison. First of all, you are not enabling the debug interface on the ESP32, which is basically the same as having APPROTECT enabled on the nRF. Secondly, I find nothing in the datasheet indicating that the ESP supports execution of encrypted code from on-chip memory. And no, the nRF does not support this either.

    Again, if you want equivalent function on the nrf, then you need to implement a UART programming interface similar to the one on the ESP32 and keep the debug port locked. The debug lock helps prevent external access to the flash content.

    I also fail to see how programming over UART is more convenient than doing it wirelessly. You could have had a custom BLE DFU controller that automatically performed the update for every node within range.

    Best regards,

    Vidar

  • Hi Vidar,

    I think that the discussion have gone to far since talking more about ESP32 because it may be off-topic here since me proving that ESP32 can encrypt on-chip memory (since I have done it and a lot of people on the internet have done it too) or explaining to you that its function of flash encryption is really something else than just nRF52 APPPROTECT have nothing to do with the problem that I have asked.

    But this one "And no, the nRF does not support this either."  is good enough for me. Since in the beginning I know that STM32 which is also arm-based have a somewhat similar function of encryption with ESP32 so I guess that Nordic SoC may be have it too. But your last reply is enough to answer my question.

    My only problem that I have is that I failed to figure out that you misunderstand the term "equivalent function" although i have explained what I mean in detail before. In addition, the way you refuse to answer right on the point in the beginning by giving meaningless suggestion then pointing out that it is not a good pracice is really make me crossed. 

    But once again, i appreciate the help you gave me, have a good day.

    Best regards,

    Tu

Related