BLE (Bluetooth Low Energy) Pairing and Bonding

Question

We are designing a small hardware device (call it the "puck") that communicates over BLE, and an app for Android & iOS to talk to it. We have an app (written in C#/Xamarin) that is connecting to the puck and they are connecting and sending data back and forth.

According to this web site, when the Bluetooth connection is first made, the two devices "pair" which just means they exchange security information.

Question 1: Am I correct in my understanding that the exchange of security information takes place automatically, there's nothing I have to do in my code to cause it to happen?

Question 2: Am I guaranteed that the communication (after the initial exchange of security information, including keys) will be encrypted?

Question 3a: On an Android device, how can I query the connection to find out what security features were agreed upon by the two BLE devices?

Question 3b: Same as 3a but on an iOS device

The puck has no display to speak of (a couple of LEDs and a button) so can't display a PIN for bonding. The plan is to have the user initiate bonding in the mobile app, sending some command over the BLE connection; in response the puck will flash its lights in some pattern and wait for the user to press the button. If the button is pressed within some timeout, bonding should take place.

Question 4: What are the "best practices" for bonding, in order to keep the BLE connection as secure as possible?

Answer 1

1) BLE Security is a complicated thing, and if you are no expert at this, it is best to ensure that the stack on which you build the application is doing this for you. On Android (and also on iOS, I suppose) the built-in stack will do the pairing for you as soon as you have started it, but on your custom built "puck" you will have to ensure this for yourself - or implement a Bluetooth stack that does this correctly (recommended).

2) If implementation is correct, encryption is ensured, yes.

3) I can't tell you this in detail, but when you initiate pairing, there should be a response from the Bluetooth stack; maybe in the return parameters, you can find this information (but I don't know that, and it strongly depends on the API you are using).

4) If the puck has no display and no input possibility except from a button (that can be seen as a Yes/No option, where "Yes" is pressing the button and "No" is not pressing it), your possibilities for pairing are very limited. Expressed as I/O capabilities, this is defined as "NoInputNoOutput" (see CoreSpec v4.2, Vol.3, Part H, chap. 2.3.2), and thus it will always result in an unauthenticated connection (see table 7 in CoreSpec v4.2, Vol.3, Part C, chap. 5.2.2.6). This does not mean that the connection is not encrypted (in fact it is), but you have no protection against Man-in-the-Middle attacks.

Checking if a button is pressed on the puck may be an additional safety measure, but note that an attacker can fake the "Button pressed" message if s/he wants to pair with your app.