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

How to provide authorization of app before connection?

Hello, I am using secure_dfu_secure_dfu_ble_s132_pca10040 project. Now I want that the user who has specific key can only access the nrf my device and then can send the zip package for dfu. How should I implement this? I am using nrf52 amd sdk12. I am able to transfer zip package using nrf toolbox.

The file is nrf_ble_dfu.txt

Modified code is code.txt

Ble_gap.h ble_gap.txt

Parents
  • Hi Shailav,

    1. You want to limit the phone to be the only phone that can authenticate the DFU action or also the only phone can connect and access the device ? If it's is the only phone that can access the device then you can think of using whitelist and bonding. Whitelist will limit the number of central that can connect to your device, in this case, the only user phone. Bonding and pairing require the central to have the key to encrypt the link. This key is exchanged using bonding process and stored on the phone.

    So when the device has no bonded central it can advertise in open mode and when it's bonded it will use whitelist mode and only accept any operation when the link is encrypted, meaning the central has the key for bonding.

    1. You can switch back to open mode when needed (by pressing a physical PAIR button on the device for example).

    The private key that you randomly generate should not be exchange outside of your coperation, and should be kept secret. How could attacker get that key ? It's much easier to get the IMEI of the phone of the end user than the secret key that you keep in your company.

    I'm no expert in security neither but a more complex mechanism better than a simple "password" could be:

    A fixed universal key shared between the app and the firmware, the firmware can generate a random number to challenge and the app need to response with a number generated from that random number and the shared key. The device will validate the response number to check if the key is correct. You can use the serial number or a secret number unique to the device as part of the key. This has to be entered when the user first bond the device to the app. This is to avoid the attacker to get the app and run the app on his phone, he still won't be able to have the correct key. (It could be on the otherway around also, the app has its own unique key that it send to the device at the beginning)

    There should be more complex and safer solutions, such as One Time Authorization, Public-Private Key scheme, but I would suggest you to do the research on your own as it's a little bit outside of what we can cover.

  • Hi Shailav,

    I would suggest you to get familiar with how whitelist work, how you can get the address, the IRK (when the peer device using random resolvable address, like the iPhone) and try to test using normal application first, before you implement on the bootloader. You also need to deal with how to store bonding information how to restore it. All this is already implemented in our peer manager. But it's not used in the bootloader.

    I can see in your code you didn't check for the return err_code back. Always check the err_code is NRF_SUCCESS, if not, it won't work. Removing code check won't help.

    I mentioned it in my blog:

    To make the code short and simple, the check of the return code (err_code) of the API call is not added here. When you implement your code, make sure the return code of each API is checked and it should return NRF_SUCCESS (0x00).

Reply
  • Hi Shailav,

    I would suggest you to get familiar with how whitelist work, how you can get the address, the IRK (when the peer device using random resolvable address, like the iPhone) and try to test using normal application first, before you implement on the bootloader. You also need to deal with how to store bonding information how to restore it. All this is already implemented in our peer manager. But it's not used in the bootloader.

    I can see in your code you didn't check for the return err_code back. Always check the err_code is NRF_SUCCESS, if not, it won't work. Removing code check won't help.

    I mentioned it in my blog:

    To make the code short and simple, the check of the return code (err_code) of the API call is not added here. When you implement your code, make sure the return code of each API is checked and it should return NRF_SUCCESS (0x00).

Children
No Data
Related