This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Will there be new silicon version of nrf52 to fix this APPROTECT loophole

According to this blogpost https://limitedresults.com/2020/06/nrf52-debug-resurrection-approtect-bypass/ the APPROTECT feature to prevent code readout can be circumvent quite easily. What are the plans of Nordic to address that issue?

For our project, protecting the firmware is very essential and we planned to use that feature to protect our man year worth of software and to protect keys for signed firmware updates.

best regards,

Torsten

Parents
  • Hi Torsten, 

    We have released the official Information Notice as pointed by Hugh. 
    If you have a specific questions please let me know. You may want to convert the case to private if there is sensitive information. 

    Regarding protecting keys for signed firmware update, please be aware that the key for DFU update stored the bootloader is the public key. The expose of this public key wouldn't compromise the security protection of the Secure DFU signing scheme. The public key is only used to verify the authenticity and integrity of the image. The attacker can't use this public key to generate his own DFU package.


Reply
  • Hi Torsten, 

    We have released the official Information Notice as pointed by Hugh. 
    If you have a specific questions please let me know. You may want to convert the case to private if there is sensitive information. 

    Regarding protecting keys for signed firmware update, please be aware that the key for DFU update stored the bootloader is the public key. The expose of this public key wouldn't compromise the security protection of the Secure DFU signing scheme. The public key is only used to verify the authenticity and integrity of the image. The attacker can't use this public key to generate his own DFU package.


Children
  • Hi Hung,

    yes there one essential question open: Are there plans to fix this issue in a future hardware version? (and if so, when can we expect to have them available?)

    According to the cited article above, Nordic knows about this issue for 2 month. So I'm sure, that Nordic has plans to either fix this, or to not fix this. Not letting us know, how Nordic is going to handle this, feels unfair.

    Our bootloader used AES GCM, to both decrypt and sign the binaries with a symmetric key that needs to stay private.

  • At this moment we don't have a plan to release a new version of silicon of the nRF52 to prevent this voltage fault infection technique.


    I just want to emphasise that this attack tampering the voltage condition outside of the normal operation condition of the chip and most of the standard microcontroller circuits don't have protection against this type of attack. 

Related