Security feature in Bluetooth Protocol of nrf 8001

RE: Security feature in Bluetooth Protocol of nrf 8001

Saurabh Gulia — Mon, 31 Mar 2014 11:24:41 GMT

Thanks Star Destroyer

RE: Security feature in Bluetooth Protocol of nrf 8001

Ole Morten — Mon, 31 Mar 2014 09:57:43 GMT

For your application, I'd recommend you to use bonding. Once your device is initially bonded with a Central, you'll receive the Bond Status Event. After this, on each reconnection to this Central, encryption will automatically started, and once it's finished you'll get the Pipe Status Event. I'd therefore recommend you to use a timeout on receiving this event after connecting, and disconnect manually, from the nRF8001 side, if you don't get this event within a couple of seconds after connection. You can do a disconnect with the Disconnect command, as is explained below.

RE: Security feature in Bluetooth Protocol of nrf 8001

David Edwin — Sat, 29 Mar 2014 07:52:45 GMT

This is correct , If your unique ID is the address of the peripheral, the CBPeripheral suggestion is ok. CBperipheral can be a standin for the the address itself that is is not exposed to the app when it receives advertising packets. You would still need to check that (random static) addresses are all unique if your app absolutely requires them to be unique across all produced devices. However this is not a problem unless you are using the device address for traceability.

However if you choose to have any other method of unique numbers you would need to store the uniqueness in the app in the first time connection.

If you choose to use encryption using the ble_proximity_template it would detect the correct iPhone as soon as the link is encrypted, the ACI Pipe Status Event is used to detect this. This encryption is the first step the iPhone does after a connection when the phone has a bond with the device i.e. ACI Connected Event.

So if you do not want other no other phones to connect, your data is secured as the ACI pipes will never become available until the link is encrypted, so you cannot send/recieve any data on a non-encrypted connection.

You run a timer for a few seconds (less then 5s) that starts on receipt of ACI Connected Event so if the ACI Pipe in ACI Pipe Status Event does not become available before the timer exipres, you treat the phone as not the correct phone and send an ACI Disconnect (lib_aci_disconnect). Do this only on the connections after the device and phone have been bonded. I.e. connections after ACI Bond Status (Success) has been received.

RE: Security feature in Bluetooth Protocol of nrf 8001

Saurabh Gulia — Fri, 28 Mar 2014 19:56:47 GMT

Hi Ole

Actually the problem is bigger that this.. i can save the peripheral and will always connect with that particular peripheral only.. but suppose if some third party app comes(hacker) then it can also scan my module through its own particular iPhone application and then connect with my module if mine iPhone is not connected at that time.And this can be easily done by any third party iPhone app.

I am thinking about this particular case,thats why i was asking how to check in nRF 8001 Arduino sdk side that which iPhone is authentic and which is not?

Can you tell me how to disconnect the connection from nRF 8001 side like in iPhone i call -cancelPeripheralConnection function and the connection b/w the iPhone and nRF 8001 is disconnected. If i can disconnect the connection b/w the above two from nRF 8001 SDK side then i can solve this problem through some logics. Can you tell how to do this or which function should i call from nRF 8001 side that can disconnects the connection?

RE: Security feature in Bluetooth Protocol of nrf 8001

Ole Morten — Fri, 28 Mar 2014 16:53:22 GMT

This is not actually needed. See my comment above.

RE: Security feature in Bluetooth Protocol of nrf 8001

Ole Morten — Fri, 28 Mar 2014 16:53:09 GMT

What you want is easiest to achieve by using a whitelist, but this is unfortunately not possible on the nRF8001. However, if another device than the one you're bonded with connects, you will pretty quickly see a disconnect event with a specific error code.

Also, you don't have to use a unique id in the advertisement or name to achieve this. On the iOS side you can store the CBPeripheral, and then just issue a connect to this instead of doing a scan and connecting to any other device.

RE: Security feature in Bluetooth Protocol of nrf 8001

David Edwin — Fri, 28 Mar 2014 16:35:29 GMT

I guess this question and its answer is related.

In short do not connect to the device until you are sure that this is the specific device you want to connect to. Identify the specific device by placing the unique number as stated in this discussion in the advertising/scan response. Use a one time setup in the app to identify the unique device it wants to connect to using RSSI. Use the unique number of the device to identify the device for all subsequent connections by storing the unique number in the app.

RE: Security feature in Bluetooth Protocol of nrf 8001

Saurabh Gulia — Fri, 28 Mar 2014 12:08:40 GMT

ble_proximity_template is not solving my problem. How can i check in nRF 8001 sdk for Arduino that this is the valid iPhone to which i have to connect? Can i send any string to peripheral before connecting it to central device(iPhone).

What actually happening is that my module is advertising well and successfully interacting data with iPhone but my module gets connected to every iPhone which has my app. Now this is creating a big problem, i want my module to connect with only one iPhone in all possible cases? How can i achieve this? what i can program in nRF 8001 sdk for Arduino that it will check whether to connect with iPhone or not? Any help is appreciated?

RE: Security feature in Bluetooth Protocol of nrf 8001

David Edwin — Mon, 24 Mar 2014 16:21:52 GMT

In the nRFgo studio XML file for the nRF8001, you can specify that you want to use a passkey. nRFgo studio -> nRF8001 configuration -> Security -> Device Security -> Security Required nRFgo studio -> nRF8001 configuration -> Security -> Required level of Security -> Authenticated (passkey)

Passkey means that you need either a display or a keyboard on the nRF8001 side. If you do not have a keyboard or display on the nRF8001 side, you should choose unauthenticated (Just Works) security. nRFgo studio -> nRF8001 configuration -> Security -> Required level of Security -> unauthenticated (Just Works)

This will allow the iPhone to pair with the nRF8001. Use the ble_proximity_template in the BLE SDK for Arduino to start with as an example.

RE: Security feature in Bluetooth Protocol of nrf 8001

Saurabh Gulia — Mon, 24 Mar 2014 07:58:15 GMT

Actually what i want is that my module should only connect with one iPhone in every case. Suppose if any other iphone wants to connect with my peripheral(module) then it should not connect that iPhone or any other central device. How can i achieve this? How can check within nRF 8001 SDK that this is the authorised iPhone to which i can connect?

I have read in pdf that you gave to me, but i can't understand it fully. Can you just tell how can i address the above problem?

RE: Security feature in Bluetooth Protocol of nrf 8001

Ole Morten — Fri, 21 Mar 2014 13:15:22 GMT

Sorry, I meant in the Bluetooth Core Specification. You can find that here: https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737

RE: Security feature in Bluetooth Protocol of nrf 8001

Saurabh Gulia — Fri, 21 Mar 2014 12:58:49 GMT

What volume 3, Part H, section 2.3.5.1 to see?

RE: Security feature in Bluetooth Protocol of nrf 8001

Ole Morten — Thu, 20 Mar 2014 15:57:46 GMT

You can use a passkey with the nRF8001, as defined by the Core Specification. To do this, you must make sure to set the I/O capabilities to either have a Display or a Keyboard in nRFgo Studio, and then make sure that your application responds to the DisplayKeyEvent or the KeyRequestEvent.

You can take a look at the Core Specification, Volume 3, Part H, section 2.3.5.1 to see what kind of authentication method is used, based on the I/O capabilities of the devices bonding.

Beware that even when using a passkey, it's trivial for an eavesdropper listening in on the bonding to pick up the data of the packets. However, any eavesdropper that does not listen in on the bonding process will not be able to read data later, no matter if a passkey is used or not. A passkey only protects against active man-in-the-middle attacks.

Edit: Clarify in which specification.