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
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."
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."
That was the 2 exemples that i found but it doesn't work. If I don't use the same keys on both sides... it works so it's not very secured !!! So I wan't to understand the necessary steps to correctly secure a nrf51 to nrf51 link on both sides. ps: for the first exemple next line don't works with S130 (timeout is not in the structure) register_param.sec_param.timeout = SEC_PARAM_TIMEOUT;
managing BLE_GAP_EVT_SEC_PARAMS_REQUEST event is not very clear. SDK exemples that manage it are all responding BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP so it's not easy to create the right response.
Thank you Mr Myhre, i will try as soon as possible
With this approach, can we say that the link is well secured ? (MITM and privacy)
