Android Bluetooth Low Energy Pairign

Question

I'm a little bit confused with BLE. I read that the BLE pairing process has three options and the one I'm interested in is the Passkey Entry.

My goal is to have a sensor on the field and the Android App will scan and find this sensor then it will request to pair with the sensor before they can exchange data. The user app is either running on a cell phone or tablet.

Is the BLE pairing the same as Bluetooth Classic? I mean is the Android API BluetoothDevice.setPin used for both BLE and Classic and the driver will do the rest under the hood?

I'm confused because I read somewhere that for BLE I can set a PIN or a Passphrase but BT Classic only accepts a 4 digit PIN.

Answer 1

Pairing in BLE is just a way of setting up an encrypted link. The devices need to agree on an encryption key and they do this either by just works (which set the key to all zeroes), passkey entry (up to six digits) or out of band (keys distributed over NFC or some other channel).

If you use passkey that means a "snooper" cannot pair with your sensor unless he can see the pass key on the device. (Either printed or on a display)

You can also combine a pairing with bonding where the devices distribute keys after encrypting the link making it possible to reconnect with the same device without having to renter a key.

You then want to set up your database on the sensor to only allow reading the sensor data over an encrypted link. (You don't want your snooper to simple connect to the device and read out the data himself).

The one problem with this approach is that the pass key entry only uses 6 digits. That is not enough entropy to really protect you against someone eavesdropping. The key generated after a passkey entry can be brute forced in milliseconds and all the commercial Bluetooth sniffers does this as part of their normal operation. They do however have to sniff the pairing procedure to do this, so if nobody was eavesdropping when the devices was bonded your usually good.

Also using out of band data is safe, since you cannot easily brute force a random 128 bit AES key.

Answer 2

A PIN type of passkey is not used in BTLE as far as I understand the specification. Legacy Bluetooth devices used a fixed PIN passkey that was hardcoded into the device or entered by the application. This method of pairing was replaced by SSP (Secure Simple Pairing) in the next round of Bluetooth. BTLE came later and uses only SSP. The passkeys in SSP (when man-in-the-middle protection is enabled) are generated randomly by the Bluetooth software usually at pretty low levels. One SSP option is 'just works' and the entire passkey generation is internal. Great for the user but it is possible for Man-In-The-Middle (MITM) attacks. So in the end, for your Bluetooth LE application you will never use the 4-digit PIN.

So pairing with BTLE devices on the Android can be done in exactly the same way as one pairs standard Bluetooth devices. If the BTLE device is using an SSP option beyond 'just works', you will get a popup menu asking for you to either

1. verify a number displayed on the device and/or provide a number that you must verify on the device (yes-no and display-only combos)

2. require that you enter a number that it displayed on the device and/or display a number that you must enter on the device (keyboard)

The built-in pairing feature works for both BTLE and BT devices in spite of the fact under the hood the mechanisms are very different. BTLE devices transmit advertisements that client devices scan for (BTLE 'discovery') whereas BT devices scan for transmissions from the client (BT discovery) when it is looking for devices.

Alternatively one can use the BluetoothAdapter.startLeScan(LeScanCallback callback) method to scan for BTLE-only devices. This method will give you a list of BTLE devices that one can then select and attempt to connect to. In this scenario, your application will need to take care of pairing when it is required. Usually pairing is not required on BTLE devices until one attempts to enable notifications or indications. Service discovery, reading the Device Information Service and other tidbits often do not require pairing and if memory serves me right one can never require pairing for service discovery.

So to make life easier for my application I link to the standard Android provided tool for the discovery/pairing of any device that requires pairing and for those BTLE devices that do not require pairing (and there are a number of such devices) I use the startLeScan() APIs and do a BluetoothDevice.connectGatt() to one of the 'discovered' devices. If I use this approach and the device actually requires pairing I will get a security error. In theory I should be able to use the pairing APIs provided by Android to then pair with the device. Unfortunately my inept programming skills have led to the fact that I have yet to succeed in implementing it correctly.