Require BLE 4.2 key exchange but not MITM

[Daniel]

I have an application which requires protection from passive eavesdropping, but not man in the middle attacks. I want to enforce the use of diffie hellman key exchange.

Security Mode 1 Level 4 does enforce diffie hellman key exchange, but it also enforces man in the middle protection. I really only need Security Mode 1 Level 2, but with Secure Connection support.

I thought about checking the lesc field in the data for the BLE_GAP_EVT_SEC_PARAMS_REQUEST event. However, sd_ble_gap_sec_params_reply returns NRF_ERROR_INVALID_STATE. I'm using Peer Manager, which is presumably already calling this function.

BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST looks capable of doing what I want, but I wanted to check if there was a way which involved configuration only. Any suggestions?

I'm using SDK 13.0.0 and softdevice s140 5.0.0-2.alpha on the nRF52840.

[Petter Myhre]

I'm very very sorry, I was totally mistaken. If you do LESC just works you actually end up in security level 2, which actually makes sense, since it is unauthenticated.

It is a bit cumbersome to know if legacy pairing just works or LESC pairing just works have been performed, but you can check that the LESC flag when you get the BLE_GAP_EVT_SEC_PARAMS_REQUEST event, and then sd_ble_gap_sec_params_reply() will also need to have the LESC flag set (which Peer Manager will do for you if you tell it to in peer_manager_init()).

Also, when doing LESC you will get the BLE_GAP_EVT_LESC_DHKEY_REQUEST event, but not in legacy.

I think this information should be available when you get the BLE_GAP_EVT_AUTH_STATUS event, and I have reported this internally.

Again, sorry for misinforming you. Let me know if anything is unclear.

[Daniel]

Thanks, Peter.

I now check the lesc bit of the event data in my handler for BLE_GAP_EVT_SEC_PARAMS_REQUEST. I call pm_sec_params_set() to enable or disable pairing based on the lesc bit.

In order to affect peer manager's handling of the same BLE_GAP_EVT_SEC_PARAMS_REQUEST, I called my handler first in ble_evt_dispatch(). Actually, I was concerned that some of the other events depend on the existing order, so I made a second application event handler just for BLE_GAP_EVT_SEC_PARAMS_REQUEST and called that handler before pm_on_ble_evt().

Then I used BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM for all of my secured characteristics.

My only remaining concern: is it possible for both nodes to support LESC but still fall back to legacy mode in any case? I'm technically not checking that LESC was actually used -- only that it was supported.

[Daniel]

One of the services I wanted to secure was the Nordic UART service. ble_nus.c hard codes the security to OPEN. I'll make another question to request that ble_nus be updated to take the security modes as initialization options.

[Petter Myhre]

As long as you react to the BLE_GAP_EVT_SEC_PARAMS_REQUEST before Peer Manager you should be fine. If both devpaices support LESC iring, then LESC pairing shall be used, and it should not fall back to legacy pairing.

[Daniel]

Excellent. Thanks.