What APPROTECT is the most secure?

Does APPROTECT supersede SECUREAPPROTECT or do both need to be enabled for maximum security?

Similarly, do the HW protections (APPROTECT, SECUREAPPROTECT, ERASEPROTECT) supersede the software protections (ex: Kconfig option: CONFIG_NRF_APPROTECT_LOCK) or should they both be used?

Parents
  • Hi Andrew,

    Enabling APPROTECT and Secure APPROTECT (SECUREAPPROTECT) on the nRF53 series are separate mechanisms and must be configured independently. Setting APPROTECT does not automatically enable SECUREAPPROTECT. So no, neither supersedes one another.

    Same with HW and SW protection. They are complementary and does not supersede one another. You should use both together for maximum security. AP-Protect is controlled by both hardware and software. If only the hardware UICR register is set but the firmware does not lock AP-Protect in software, the software layer could potentially open the debug access port.

    I suggest that you go through the documentation here: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/security/ap_protect.html 

    Best Regards,

    Swathy

  • Thanks! Your description helps a lot.

    Does software AP-Protect prevent the "unlocking" described herehttps://docs.nordicsemi.com/bundle/nan_042/page/APP/nan_production_programming/approtect_eraseprotect_enabled.html

    Does software AP-Protect any future FW from disabling AP-Protect? Like, if the boot loader never changes and if it had AP-Protect enabled, can AP-Protect ever be disabled? Would the boot loader have to be updated?

  • Hi Andrew,

    BluePotion said:
    Does software AP-Protect prevent the "unlocking" described here?

    The unlock mechanism where firmware provides a 32-bit non-zero KEY to ERASEPROTECT.DISABLE is specifically for the case where both APPROTECT and ERASEPROTECT are enabled. I will elaborate on this a bit more below.

    BluePotion said:
    Does software AP-Protect any future FW from disabling AP-Protect?

    Yes, it does. The following is stated in the documentation that I've shared: "With this Kconfig option set, the MDK locks AP-Protect in SystemInit() at every boot. It also prevents CPU from disabling AP-Protect in software." Refer: https://docs.nordicsemi.com/bundle/ncs-latest/page/kconfig/index.html#CONFIG_NRF_APPROTECT_LOCK 

    If the bootloader permanently locks AP-Protect using the KCONFIG CONFIG_NRF_APPROTECT_LOCK, a simple firmware update does not disable APPROTECT.  This is because the lock happens in SystemInit() before any application code runs. The only way to regain debug access would be through hardware-side recovery (you can use nrfutil device recover, which will issue an ERASEALL), provided that ERASEPROTECT is not also enabled. If ERASEPROTECT is also enabled, then it blocks  ERASEALL functionality. So the only recovery path is the KEY-based handshake that you have linked. (this requires a compatible firmware as stated in the documentation).

    Best Regards,

    Swathy

Reply
  • Hi Andrew,

    BluePotion said:
    Does software AP-Protect prevent the "unlocking" described here?

    The unlock mechanism where firmware provides a 32-bit non-zero KEY to ERASEPROTECT.DISABLE is specifically for the case where both APPROTECT and ERASEPROTECT are enabled. I will elaborate on this a bit more below.

    BluePotion said:
    Does software AP-Protect any future FW from disabling AP-Protect?

    Yes, it does. The following is stated in the documentation that I've shared: "With this Kconfig option set, the MDK locks AP-Protect in SystemInit() at every boot. It also prevents CPU from disabling AP-Protect in software." Refer: https://docs.nordicsemi.com/bundle/ncs-latest/page/kconfig/index.html#CONFIG_NRF_APPROTECT_LOCK 

    If the bootloader permanently locks AP-Protect using the KCONFIG CONFIG_NRF_APPROTECT_LOCK, a simple firmware update does not disable APPROTECT.  This is because the lock happens in SystemInit() before any application code runs. The only way to regain debug access would be through hardware-side recovery (you can use nrfutil device recover, which will issue an ERASEALL), provided that ERASEPROTECT is not also enabled. If ERASEPROTECT is also enabled, then it blocks  ERASEALL functionality. So the only recovery path is the KEY-based handshake that you have linked. (this requires a compatible firmware as stated in the documentation).

    Best Regards,

    Swathy

Children
No Data
Related