Best practices to secure a BLE NRF51 to NRF51 link ?

[Fabien Comte]

Hello,

I want to secure a link between 2 NRF51 (man in the middle and privacy with AES).

How to do that ? (I can use a static key in this application)

Most of the codes i found are partials and not up to date (timeout does not exist in structure, ...). Documentation is good but difficult to apply without an exemple to start and I not found any exemple in SDK.

Thank you.

edit 29.09.2015: traces.txt

edit 03.10.2015: traces.txt

[Petter Myhre]

Are you asking for an example that does pairing with static passkey? There is one here. It is for SoftDevice 7.1.0/SDK 6.1.0 though. It should still be helpful. This question may also be of help.

Edit 25.09.2015: I was a bit quick with my previous answer. Normally static passkey is used when one side of the link has no IO capabilites and the other has keyboard. For example a nRF51 connected to a smart phone.

You want to connect two nRF51's. None of them have keyboard or display.

One thing you could do is to use static passkey on both sides. On both sides, you tell the SoftDevice that you have only keyboard as IO capability. Then during the pairing process you just simulate that a passkey is entered, instead you just provide the same static passkey on both sides.

The operation will be similar to this and this, only that the BLE_GAP_EVT_SEC_PARAMS_REQUEST event will have keyboard instead of display. When you get the BLE_GAP_EVT_AUTH_KEY_REQUEST event you must reply with sd_ble_gap_auth_key_reply() on both sides.

I just tested this with ble_app_hrs and ble_app_hrs_c in SDK 9.0.0 and SoftDevice S110 8.0.0 and SoftDevice S120 2.1.0.

Here are my projects.

ble_app_hrs - should be unzipped into \examples\ble_peripheral

ble_app_hrs_c - should be unzipped into \examples\ble_central

You can find my changes to the orignal examples by searching for pemy.

Edit 25.09.2015:

In regards to privacy and MITM.

From Vol. 3, Part H, Section 2.3.1 Bluetooth Core spec: "In LE legacy pairing, Authenticated man-in-the-middle (MITM) protection is obtained by using the passkey entry pairing method or may be obtained using the out of band pairing method."

From Vol. 3, Part H, Section 2.3.1 Bluetooth Core spec: "For LE Legacy Pairing, none of the pairing methods provide protection against a passive eavesdropper during the pairing process as predictable or easily established values for TK are used. If the pairing information is distributed without an eavesdropper being present then all the pairing methods provide confidentiality."

The passkey(s) are supposed to be random. But this is not possible since you don't have any IO capabilites. From Vol. 3, Part H, Section 2.3.5.3 Bluetooth Core spec: "The passkey Entry method provides protection against active “man-in-the middle” (MITM) attacks as an active man-in-the-middle will succeed with a probability of 0.000001 on each invocation of the method." This probablity will increase on consecutive attacks, since the passkey is static.

From Vol. 3, Part H, Section 2.3.5.3 Bluetooth Core spec: "The Passkey Entry STK generation method provides very limited protection against eavesdroppers during the pairing process because of the limited range of possible TK values which STK is dependent upon. If the attacker is not present during the pairing process then confidentiality and authentication can be established by using encryption on a future connection."

[Petter Myhre]

Have you found BLE_GAP_EVT_SEC_PARAMS_REQUEST in the code now? If the peripheral application doesn't receive BLE_GAP_EVT_SEC_PARAMS_REQUEST most likely the central hasn't sent a pairing request. The central application triggers a pairing request by calling sd_ble_gap_authenticate(), in the attached ble_app_hrs_c this is done when the BLE_HRS_C_EVT_DISCOVERY_COMPLETE event is received, through dm_security_setup_req()->initiate_security_request()->sd_ble_gap_authenticate().

If the BLE_GAP_EVT_AUTH_KEY_REQUEST event is not received it is most likely because there is something wrong with the IO capabilites.

You can test with the nRF Sniffer.Or you can use the debugger.To test you can put a breakpoint on the BLE_GAP_EVT_SEC_PARAMS_REQUEST in device_manager_peripehral.c If BLE_GAP_EVT_SEC_PARAMS_REQUEST is not received I would check if sd_ble_gap_authenticate() is called on the central side.