Require BLE 4.2 key exchange but not MITM

RE: Require BLE 4.2 key exchange but not MITM

Daniel — Thu, 04 May 2017 13:43:51 GMT

Excellent. Thanks.

RE: Require BLE 4.2 key exchange but not MITM

Petter Myhre — Thu, 04 May 2017 07:20:28 GMT

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.

RE: Require BLE 4.2 key exchange but not MITM

Daniel — Wed, 03 May 2017 20:39:24 GMT

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.

RE: Require BLE 4.2 key exchange but not MITM

Daniel — Wed, 03 May 2017 20:37:08 GMT

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.

RE: Require BLE 4.2 key exchange but not MITM

Petter Myhre — Wed, 03 May 2017 13:07:23 GMT

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.

RE: Require BLE 4.2 key exchange but not MITM

Daniel — Tue, 02 May 2017 14:04:48 GMT

I tried the ble_app_multirole_example on a pca10040. I get the same behavior if I define LESC_MITM_NC to 0.

RE: Require BLE 4.2 key exchange but not MITM

Daniel — Tue, 02 May 2017 13:27:12 GMT

The SDK macro to require level 4 is named BLE_GAP_CONN_SEC_MODE_SET_LESC_ENC_WITH_MITM, and there is no corresponding macro for LESC_ENC_NO_MITM.

RE: Require BLE 4.2 key exchange but not MITM

Daniel — Tue, 02 May 2017 13:19:31 GMT

Ok, then I guess my question becomes: why am I not getting mode 1 level 4? I'm using nRF Connect as the central node. I perform a pair with the "Enable LE Secure Connection pairing" option checked. The resulting security level is 2.

I've integrated LESC support from the ble_app_multirole_lesc example. I can see from the nRF logs that the LESC key is generated. I get a PM_EVT_CONN_SEC_SUCCEEDED with a procedure of 2. Then I get a BLE_GAP_EVT_AUTH_STATUS with mode 1 level 2. Would the nRF Connect log be helpful?

RE: Require BLE 4.2 key exchange but not MITM

Petter Myhre — Tue, 02 May 2017 12:58:49 GMT

You will not get security level 2 with ECDH key exchange, you will get security level 4. If you end up in security level 2 you are doing legacy pairing (with just works). If you don't have any I/O capabilites you can use LESC Just Works, it protects against passive eavesdropping.

RE: Require BLE 4.2 key exchange but not MITM

Daniel — Tue, 02 May 2017 12:39:33 GMT

My application sets I/O capabilities to None. Even with ECDH key exchange, I only get security mode 1 level 2. This level is acceptable for my application, but I need to distinguish it from a legacy key exchange mode 1 level 2.

RE: Require BLE 4.2 key exchange but not MITM

Petter Myhre — Tue, 02 May 2017 10:11:54 GMT

If ECDH key agreement is used the connection will be in security level 4. Security mode 2 is legacy pairing using just works, which doesn't provide protection against passive eavesdroppers if there is an attack during the pairing process.

Why are you checking the LESC field? I don't get what you want to achieve.

BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST is related to authorization, is that what you want to do? It does not protect against passive eavesdroppers.