NRF5 Read Back Protection

  • Contest Winner

    I think about implementing Read Back Protection to avoid accessing Signing/Encryption Keys via debug interface. This functionality is not part of arduino-nRF5.

    The Read Back Protection must enabled once from Firmware by flashing User Information Configuration Registers.

    There are two options to implement this. First one is to add this feature to arduino-nRF5 and the second one is to add this feature to MySensors.

    I prefer MySensors to force this functionality because the additional step to activate this feature via Arduino menu can be forgotten or not enabled by ignorance.

  • Mod

    @d00616 IMHO this functionality is way too specific to the actual hardware used. Nrf5 can do it through software, avr requires fuses to be programmed and esp doesn't even support it (or at least I'm not aware of it).
    This means adding it to the library would add a new function that is only implemented for Nrf5, for all other platforms it will be a dummy function.
    If I were you I would take a different approach and just add the required code to your sketch, preferably wrapped in some library if it is more than a few lines of code.

  • Contest Winner

    Now I think the Read Back Protection can't be enabled by MySensors. After enabling this feature, flashing is only allowed after deleting the whole flash. The flash is containing the emulated EEPROM data. Enabling the Read Back Protection should be a Part of an OTA bootloader.

  • Contest Winner

    I agree. In general, security mechanisms other than OTA/message related (signing/encryption) should be part of the bootloader, since that is the area where absolute control can be enforced on what to execute (fw validation, etc).

Log in to reply

Suggested Topics