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

I want to protect nrf52 chip based application from getting OTA without authorization

Hi All,

I have developed application which will detect key press and perform he respective task ,using the  S132 (nrf52) with button-less dfu project (SDK15.3)which 

includes OTA , so now my aim is to protect the chip from getting updated non authorized users,only the user with proper password should be able to update

the device via OTA. 

Initially i had thought of Static passkey protection but it asks for peer for simple connection as well but my aim is to only protect OTA not connection.

How can this be achieved .? is it feasible ? or any other way to protect device..?

Plz  help ..!! All suggestions are appreciated.

Thanks in Advance.!!

Regards,

Atul

Parents
  • Hi Atul,

    First of all, I want to clarify that it will anyway only be possible to update to the firmware that you have signed since the bootloader validates the DFU package. Only the holder of the private key is able to sign the images. However, preventing users from putting the device in DFU mode is a different matter, and it seems that is what you want to limit?

    The obvious option is to require pairing/bonding in order to write to the DFU characteristic that puts the nRF in DFU mode. You could make sure that all other characteristics are open, and only require pairing for the DFU characteristic. Then you can use a static passkey to protect that, provided that it gives you good enough security (if the passkey is leaked, it collapses. Does that seem like a sensible solution? If not, can you clarify the requirements?

    Einar

Reply
  • Hi Atul,

    First of all, I want to clarify that it will anyway only be possible to update to the firmware that you have signed since the bootloader validates the DFU package. Only the holder of the private key is able to sign the images. However, preventing users from putting the device in DFU mode is a different matter, and it seems that is what you want to limit?

    The obvious option is to require pairing/bonding in order to write to the DFU characteristic that puts the nRF in DFU mode. You could make sure that all other characteristics are open, and only require pairing for the DFU characteristic. Then you can use a static passkey to protect that, provided that it gives you good enough security (if the passkey is leaked, it collapses. Does that seem like a sensible solution? If not, can you clarify the requirements?

    Einar

Children
  • Hi Einar,

    Thanks for the response...!!

    The suggestion you are proposing ,seems sensible ,but I had a try to make static passkey work but it didn't gone through well I had reference from gls example in peripheral examples , how can I make only DFU characteristics request pairing and then adding of passkey ? Could you suggest some reference where I can find only DFU uses pairing ?

    Can you guide me to implement the solution you suggested would be great!..!!

  • Hi,

    You can require pairing with a static passkey for the DFU service (without using bonds during DFU) by adjusting the implementation of ble_dfu_buttonless_char_add() in components\ble\ble_services\ble_dfu\ble_dfu_unbonded.c. Instead of using SEC_OPEN for cccd_write_access and write_access, you could set SEC_MITM. Then you also need to add support for a static passkey. You can refer to this post for a way to implement static passkey. You should also make sure that any other service you use have all characteristics set to SEC_OPEN if you want all of them to be accessible without pairing.

    There is one problem with the above approach, and that is that phone implementations differ and might change over time. So you cannot guarantee that the phone will to attempt to bond even though it is not needed unless you want to do DFU. Currently, iOS will not, but Android phones may. And it could change over time.

    You could devise another method for preventing others from entering DFU mode, for instance using a static key that is just sent together with a custom command that enters DFU mode. However, if you choose to send this without pairing that means that an attacker can listen in and subsequently use the same command to put the device in DFU mode. Whether that is acceptable or not depends on your security requirements. Note that an attacker will anyway not be able to upload unauthorized firmware if you use the secure bootloader from the SDK, since any DFU package must be signed with your private key in order to be valid. An invalid packet will be discarded. So an attacker could block the device (denial of service).

Related