• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 64 subscribers
  • Views 1952 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 276486
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
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

nRF53 access port protection

rookie

I would like to enable access protection on my device, ie no debugger or flash access. Going through the docs, it looks like I’d have to do a few registers to get access protection fully enabled. I would like to confirm the following steps are necessary:

  • set UICR.APPROTECT to 0
  • set UICR.SECUREAPPROTECT to 0
  • set CTRL_AP.APPROTECT.LOCK to locked state
  • set CTRL_AP.SECUREAPPROTECT.LOCK to locked state

There is also ERASEPROTECT register. I would like to know if enabling erase protection means that a development device may never be able to be re-programmed? For example, will my nRF5DK stop accepting programming requests once this is set? Looks like it is possible to get it in this state by using it with APPROTECT according to this post: https://devzone.nordicsemi.com/f/nordic-q-a/69075/nrf5340-hardware-security-features-fuses-and-bus-protections/283484#283484

that points to this link (nRF9160):

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fnan_041%2FAPP%2Fnan_production_programming%2Fcheck_approtect_enabled.html

But I couldn’t find information in this app note that explicitly mentions that this is possible

The app note above has the following information. I am curious to know how we can use JLink to perform this operation(ie write a known value to the register before being able to connect to the device):

To unlock the device, it must have compatible firmware that provides a 32-bit non-zero KEY value to ERASEPROTECT.DISABLE. When both the debugger and firmware provide the same 32-bit non-zero KEY value to ERASEPROTECT.DISABLE, the device does a Control Access Port (CTRL-AP) erase all operation. The access port is re-enabled on the next reset once the erase sequence is done.

Parents
  • 0

    Hi, 

    There is also ERASEPROTECT register. I would like to know if enabling erase protection means that a development device may never be able to be re-programmed?

    Almost. It can be used (when combined with APPROTECT) to ensure that the device can never be re-programmed as long as the attacker does not have access to the 32 bit key value. Anyone with access to the 32 bit key value can erase and reprogram the device. Note that this means that if you play with this feature it is easy to brick your device (if you forget the key).

    The app note above has the following information. I am curious to know how we can use JLink to perform this operation(ie write a known value to the register before being able to connect to the device):

    To unlock the device, it must have compatible firmware that provides a 32-bit non-zero KEY value to ERASEPROTECT.DISABLE. When both the debugger and firmware provide the same 32-bit non-zero KEY value to ERASEPROTECT.DISABLE, the device does a Control Access Port (CTRL-AP) erase all operation. The access port is re-enabled on the next reset once the erase sequence is done.

    It is as stated here. The firmware and debugger must write the same key to the ERASEPROTECT.DISABLE to unlock and erase the device. You can also see this from the CTRL-AP section in the product specification. The documentation for ERASEPROTECT.DISABLE states "The ERASEALL sequence will be initiated if value of the KEY fields are non-zero and the KEY fields match on both the CPU and debugger sides."

  • 0 in reply to Einar Thorsrud

    Hi,

    Thank you for the explanation, Can you confirm the first part of my question ie, I need to set UICR AND CTRL_AP LOCKS to fully secure the device (eraseprotect is probably separate)? In the nRF52 family, locking CTRL_AP is not required(correct me if I'm wrong here), so this is a requirement in the nRF53 family?

    Secondly can you provide an example of how the debugger can write a value to the device prior to connecting? If the device is locked, how can JLink even connect to the device to do a memwr ?

  • +1 in reply to rookie

    Hi,

    rookie said:
    Can you confirm the first part of my question ie, I need to set UICR AND CTRL_AP LOCKS to fully secure the device (eraseprotect is probably separate)?

    By this, do you mean secure against reading or modifying memory content using a debugger? If so, the APPROTECT mechanism is what you need. With the nRF53 series APPROTECT is enabled by default, so unless you explicitly disable it it the debug interface will be protected (and only opened after a full chip erase). It is possible in firmware to lock it to ensure that it is never enabled again also, by writing to APPROTECT.LOCK. I suggest you refer to the product specification for details, and you can also see how this is done in code by referring to system_nrf53_approtect.h which handles this for you.

    rookie said:
    locking CTRL_AP is not required(correct me if I'm wrong here), so this is a requirement in the nRF53 family?

    I am not sure about the question here. locking CTRL_AP is not required in either the nRF52 series or nRF53, but it is an option in both if you want to prevent debugger access, primarily to prevent memory dumping. The mechanism has been improved in the nRF53 though (and the just released new nRF52 revisions). (preventing erase operations is not available on the nRF52 series though, only on nRF53 and nRF91.)

    rookie said:
    Secondly can you provide an example of how the debugger can write a value to the device prior to connecting? If the device is locked, how can JLink even connect to the device to do a memwr ?

    This is because there are two separate access ports. One normal debug access port (DAP), and one CTRL-AP port, which is the one that controls access to the DAP. This is available even though the debug interface (DAP) has been disabled. See introductory part of CTRL-AP chapter for details. Note that this typically must be combined with the mailbox interface to tell the CPU to disable ERASEPROTECT as well, as it must be disabled both by the CPU and by the debugger. (In this case the idea is to use a form of challenge-response mechanism so that the application can validate the debugger before opening up).

    Regarding example I must admit this is not a common request, and I have not found any. Moreover, the tools support is also lacking at this point, so we do not have what you need to demonstrate/use this feature at this point. That is, locking is possible, but re-opening. I will make a feature request for this, but I cannot promise that it will be available in the near future.

    You can also do it without special tools support, but it is not straight-forward. See this thread about CTRL-AP access using GDB.

Reply
  • +1 in reply to rookie

    Hi,

    rookie said:
    Can you confirm the first part of my question ie, I need to set UICR AND CTRL_AP LOCKS to fully secure the device (eraseprotect is probably separate)?

    By this, do you mean secure against reading or modifying memory content using a debugger? If so, the APPROTECT mechanism is what you need. With the nRF53 series APPROTECT is enabled by default, so unless you explicitly disable it it the debug interface will be protected (and only opened after a full chip erase). It is possible in firmware to lock it to ensure that it is never enabled again also, by writing to APPROTECT.LOCK. I suggest you refer to the product specification for details, and you can also see how this is done in code by referring to system_nrf53_approtect.h which handles this for you.

    rookie said:
    locking CTRL_AP is not required(correct me if I'm wrong here), so this is a requirement in the nRF53 family?

    I am not sure about the question here. locking CTRL_AP is not required in either the nRF52 series or nRF53, but it is an option in both if you want to prevent debugger access, primarily to prevent memory dumping. The mechanism has been improved in the nRF53 though (and the just released new nRF52 revisions). (preventing erase operations is not available on the nRF52 series though, only on nRF53 and nRF91.)

    rookie said:
    Secondly can you provide an example of how the debugger can write a value to the device prior to connecting? If the device is locked, how can JLink even connect to the device to do a memwr ?

    This is because there are two separate access ports. One normal debug access port (DAP), and one CTRL-AP port, which is the one that controls access to the DAP. This is available even though the debug interface (DAP) has been disabled. See introductory part of CTRL-AP chapter for details. Note that this typically must be combined with the mailbox interface to tell the CPU to disable ERASEPROTECT as well, as it must be disabled both by the CPU and by the debugger. (In this case the idea is to use a form of challenge-response mechanism so that the application can validate the debugger before opening up).

    Regarding example I must admit this is not a common request, and I have not found any. Moreover, the tools support is also lacking at this point, so we do not have what you need to demonstrate/use this feature at this point. That is, locking is possible, but re-opening. I will make a feature request for this, but I cannot promise that it will be available in the near future.

    You can also do it without special tools support, but it is not straight-forward. See this thread about CTRL-AP access using GDB.

Children
  • 0 in reply to Einar Thorsrud

    > Regarding example I must admit this is not a common request, and I have not found any

    Given this is a new-ish feature, I think it would be useful to have some example of doing so via JLink. Technically, it does seem possible as the product specification makes this claim. I'll probably try it out myself too. Thank you.

Related