LE security on nRF DFU - nRF52840 S140

RE: LE security on nRF DFU - nRF52840 S140

AliMahmood123 — Tue, 08 Feb 2022 19:27:43 GMT

This was solved here:

devzone.nordicsemi.com/.../351345

RE: LE security on nRF DFU - nRF52840 S140

AliMahmood123 — Mon, 31 Jan 2022 20:29:53 GMT

Hi
I've made some progress and now I can ask some to the point questions. I would be very grateful if you can read all and provide me with detailed answer.
I have referred to https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v7.2.0%2Fgroup___b_l_e___g_a_p___p_e_r_i_p_h___s_e_c___m_s_c.html&cp=4_7_3_1_2_1_5_10 for the logs that I see.

So I have two situations
1) Bond forwarding - I have managed to encrypt the link and do bond forwarding as well. I did that by adding LESC crypto libraries separately. I got BLE_GAP_EVT_LESC_DHKEY_REQUEST and the whole flowchart as expected. I am still a bit confused as to how the default example (bond forwarding) could be encrypted without adding LESC and crypto support. That's just my curiosity.

Anyways for the above situation, the LTK is generated and it's being used in DFU. My question here is that when the device goes into DFU Mode, is the session still encrypted?

Another question here is regarding bond deletion, I get really weird behaviour when I delete bonds, it wasnt working with simply deleting from app in this case 1). I had to delete bonds from peer as well. I have still more testing to do but since we have a few days gap in replies that's why I prefer to ask everything up front

2) Without bond forwarding - Only LESC - I disabled bond forwarding and bonding and just did pairing (No BLE pairing phase 3 of key exchange which is bonding). I also added CONN_JUST_WORKS on DFU characteristics.
DFU works fine.
My question here also is that when the device goes into DFU Mode, is the session still encrypted?

Another question here is that when I do DFU with LESC and no bond forwarding, the device says "Bonded". That doesn't make any sense. I think this is a bug as I have not bonded in the first place. So on the upgraded firmware I simply forget the bonds and use the updated application. I dont have much problem with this but I just dont get the concept. I realize its due to adding just works on DFU characteristic. But I clearly "Pairing" logs as the role from peer manager. Then why does it say bonded?

Please answer me clear cut on this so I can compare the above two situations to what I want
And please answer all questions for easiness for you and me both. Thanks a lot in advance for hearing me out

RE: LE security on nRF DFU - nRF52840 S140

AliMahmood123 — Mon, 31 Jan 2022 14:58:33 GMT

Hi Sigurd
I have managed to do it over the weekend

I have encrypted the link of the buttonless app, without bonding. I am thinking not to use Bonding per se. protected the DFU write characteristic with Just Works.

I have a question now, the link will stay encrypted when going into DFU Mode too, right? Or is bonding the only way, please guide

RE: LE security on nRF DFU - nRF52840 S140

Sigurd — Mon, 31 Jan 2022 14:55:46 GMT

Hi,

[quote user=""]I also compared the two projects. NRF_CRYPTO_ENABLED is 1 in gls project, alongside PM_LESC_ENABLED is also 1. These are 0 or not present in the DFU example.[/quote][quote user=""]Also trying out bond forwarding with SEC_PARAM_LESC set to 1 in main did not encrypt the channel.[/quote][quote user=""]Does a guide exist on shifting any gatt service / BLE connection to LE connections and encryption? Any help would be appreciated and we are in a bit of a hurry as well.[/quote]

Unfortunately there is no guide for this. You would need to compare an example that uses LESC(e.g. ble_app_hrs) and see what's missing in ble_app_buttonless_dfu. I believe you would need to e.g. add the crypto libraries, and you need to call nrf_ble_lesc_request_handler() in the main loop to respond to LESC-related BLE events.

Set NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS to 1 in the sdk_config.h in the app, and in the bootloader set NRF_DFU_BLE_REQUIRES_BONDS