This article covers primarily two scenarios that can occur after a bond has been established between a smartphone and a Bluetooth Capable EFR32.
Case 1: Bonding keys are deleted from the smartphone.
Potential causes include manually deleting the keys, software/factory reset, app malfunction.
Case 2: Bonding keys are deleted from the EFR32.
Potential causes include a full chip erase, running out of space for storing bonding keys (in which case one can delete the older keys)
Disclaimer: This KBA and the sample application attached with it is to be used for information, reference about the topic and testing. It is no way production ready code and the use of the code will be at your own risk.
Setup
Master: A smartphone with the Blue Gecko app
An Android smartphone (A Sony Xperia Z1 running Android 5.1.1, doesn’t support LE secure connections)
Another Android smartphone (A Samsung Galaxy S6 Edge running Android 7.0, supports LE secure connections)
An Apple smartphone (iPhone 6, running iOS 11.2.6 supports LE secure connections)
Slave: An EFR32 Radio board (I used a BGM module, it supports LE secure connections) (Programmed with Bluetooth SDK 2.9.2.0)
According to our observation, Android OS treats pairing and connecting as 2 events. Pairing is optional if your GATT database does not contain any characteristic that require encryption or bonding. You can connect, not pair and still be able to read and write other characteristics. When a connection is made between the EFR and Smartphone, the security level is 1. When paired, security level increases to 3 or 4 depending on Legacy or Secure connections respectively.
Figure 1: The Bluetooth browser showing the Empty Example device
Figure 2: Connected but not bonded to the EFR
Figure 3: Optional Pairing/Bonding request received
Apple:
iOS actively asks for a pairing request if your GATT database contains any characteristic that require encryption or bonding because it reads all the characteristics as soon as you connect a device. As a result, you receive an active pairing request while setting up a connection. The request is initiated with security level 1 but is increased up to level 4 once a bond is created successfully.
Figure 4: Bluetooth browser in iOS
Figure 5: Active pairing/bonding request received while connecting
Observations
These observations are for the flags set to values as mentioned above. These will vary based on the values and device capabilities as mentioned in the article linked above.
Case 1: Bonding keys are lost on the smartphone.
iPhone: A new pairing request is initiated with a request to enter the passkey. Upon successful pairing, security Level_4 is achieved. The EFR overwrites the existing bonding keys.
Android (both test devices): Android phones receive 2 new pairing requests. First one with a yes(pair)/no option to pair. The second one asks for a passkey entry. Upon successful pairing security Level_3 is achieved for phones which don’t support secure connections. Security Level_4 is achieved for phones which support secure pairing.
Case 2: Bonding keys are lost on the EFR.
Android Blue Gecko App connecting to EFR
On LE secure supported phones: Pairing fails with reason
0x0206: pin_or_key_missing; Pairing failed because of missing PIN, or authentication failed because of missing key. The connection remains open with security Level_1. This error can be caught, and an increase security function (sm_increase_security; refer section ) can be triggered. As a result, a passkey entry request is received on the phone. Upon successful pairing, security Level_4 is achieved.
b. On phones which don’t support LE secure: Again, pairing fails with reason
0x0206: pin_or_key_missing; Pairing failed because of missing PIN, or authentication failed because of missing key. The connection is terminated from the phone’s side upon detecting a failed attempt and the bonding keys are deleted on the phone *. We receive error code 0x0213: remote user terminated. A repeated pairing attempt sets up new bonding keys on both sides as if they are connecting for the first time.
* This behavior can change based on your phone/Android version and hardware configurations of your phone.
2. iOS App connecting to EFR
Pairing fails with error code 0x0206 (Pin or key missing). The connection remains open with security Level_1. This error can be caught in the gecko_evt_sm_bonding_failed_id, and an increase security function can be triggered. This command fails due to timeout with error code 0x0185 after about 15-30 seconds. This error is caught and an increase security function (gecko_cmd_sm_increase_security(connectionhandle)) triggers a new passkey request. Upon successful pairing, security Level_4 is achieved.
The sample application attached with this KBA demonstrates these mechanisms for handling missing bonding keys on both sides.
1. Connect to the EFR32 named "Empty Example" from the Blue Gecko App Bluetooth Browser. Enter the passkey displayed on the console when asked.
2. Disconnect. Delete bonding data from your phone settings> Bluetooth. Reconnect from the app. Note the observations on the serial monitor.
3. Press reset on EFR32. The sample application attached with this KBA is designed to delete the bonding keys when you reset. IT IS NOT RECOMMENDED IN REAL APPLICATIONS. Follow step 1.
4. Disconnect, press reset on EFR32, and reconnect (do not delete bonding data on the phone this time). Note the observations on the serial monitor.
Contribution credit: The example code attached with this KBA is based on the work of Théo Meyer from www.strataggem.com
How could we reduce the 15-30second delay seen when the iOS device try to connect to an EFR with lost keys ? Is it possible to abort the command that we already know will timeout?
With respect to the delay, it turns out that the request to increase security is met by a "device in wrong state" error. It is still unclear what is causing this. Upon further investigation it turns out that the command timeout is defined in Bluetooth spec section 3.4 SMP TIMEOUT and is 30 seconds. The only way to abort the command before 30 sec is to disconnect however with this KBA we are trying to re-establish bonding in the same session without disconnecting.
KBA_BT_1105: How to handle missing bonding keys
This article covers primarily two scenarios that can occur after a bond has been established between a smartphone and a Bluetooth Capable EFR32.
Case 1: Bonding keys are deleted from the smartphone.
Potential causes include manually deleting the keys, software/factory reset, app malfunction.
Case 2: Bonding keys are deleted from the EFR32.
Potential causes include a full chip erase, running out of space for storing bonding keys (in which case one can delete the older keys)
Disclaimer: This KBA and the sample application attached with it is to be used for information, reference about the topic and testing. It is no way production ready code and the use of the code will be at your own risk.
Setup
Master: A smartphone with the Blue Gecko app
Slave: An EFR32 Radio board (I used a BGM module, it supports LE secure connections) (Programmed with Bluetooth SDK 2.9.2.0)
Click here to read about Bluetooth Security features in Silicon Labs Bluetooth SDK
Commands
Some important commands used in the sample code attached with this KBA.
gecko_cmd_sm_set_passkey(-1);
Used to generate a random passkey required to support Level 4 security.
gecko_cmd_sm_configure(0x0B,sm_io_capability_displayonly);
0x0B: Enables everything except the “secure connections only flag” bit.
displayonly: Used to represent the EFR as a display only device.
gecko_cmd_sm_set_bondable_mode(1);
Set the device in bondable mode.
gecko_cmd_sm_increase_security(connectionhandle);
Used to increase security level after connection is established.
More details of all these commands can be found in Bluetooth API Reference guide.
Connecting
Android:
According to our observation, Android OS treats pairing and connecting as 2 events. Pairing is optional if your GATT database does not contain any characteristic that require encryption or bonding. You can connect, not pair and still be able to read and write other characteristics. When a connection is made between the EFR and Smartphone, the security level is 1. When paired, security level increases to 3 or 4 depending on Legacy or Secure connections respectively.
Apple:
iOS actively asks for a pairing request if your GATT database contains any characteristic that require encryption or bonding because it reads all the characteristics as soon as you connect a device. As a result, you receive an active pairing request while setting up a connection. The request is initiated with security level 1 but is increased up to level 4 once a bond is created successfully.
Observations
These observations are for the flags set to values as mentioned above. These will vary based on the values and device capabilities as mentioned in the article linked above.
Case 1: Bonding keys are lost on the smartphone.
iPhone: A new pairing request is initiated with a request to enter the passkey. Upon successful pairing, security Level_4 is achieved. The EFR overwrites the existing bonding keys.
Android (both test devices): Android phones receive 2 new pairing requests. First one with a yes(pair)/no option to pair. The second one asks for a passkey entry. Upon successful pairing security Level_3 is achieved for phones which don’t support secure connections. Security Level_4 is achieved for phones which support secure pairing.
Case 2: Bonding keys are lost on the EFR.
0x0206: pin_or_key_missing; Pairing failed because of missing PIN, or authentication failed because of missing key. The connection remains open with security Level_1. This error can be caught, and an increase security function (sm_increase_security; refer section ) can be triggered. As a result, a passkey entry request is received on the phone. Upon successful pairing, security Level_4 is achieved.
b. On phones which don’t support LE secure: Again, pairing fails with reason
0x0206: pin_or_key_missing; Pairing failed because of missing PIN, or authentication failed because of missing key. The connection is terminated from the phone’s side upon detecting a failed attempt and the bonding keys are deleted on the phone *. We receive error code 0x0213: remote user terminated. A repeated pairing attempt sets up new bonding keys on both sides as if they are connecting for the first time.
* This behavior can change based on your phone/Android version and hardware configurations of your phone.
2. iOS App connecting to EFR
Pairing fails with error code 0x0206 (Pin or key missing). The connection remains open with security Level_1. This error can be caught in the gecko_evt_sm_bonding_failed_id, and an increase security function can be triggered. This command fails due to timeout with error code 0x0185 after about 15-30 seconds. This error is caught and an increase security function (gecko_cmd_sm_increase_security(connectionhandle)) triggers a new passkey request. Upon successful pairing, security Level_4 is achieved.
The sample application attached with this KBA demonstrates these mechanisms for handling missing bonding keys on both sides.
References
Testing
1. Connect to the EFR32 named "Empty Example" from the Blue Gecko App Bluetooth Browser. Enter the passkey displayed on the console when asked.
2. Disconnect. Delete bonding data from your phone settings> Bluetooth. Reconnect from the app. Note the observations on the serial monitor.
3. Press reset on EFR32. The sample application attached with this KBA is designed to delete the bonding keys when you reset. IT IS NOT RECOMMENDED IN REAL APPLICATIONS. Follow step 1.
4. Disconnect, press reset on EFR32, and reconnect (do not delete bonding data on the phone this time). Note the observations on the serial monitor.
Contribution credit: The example code attached with this KBA is based on the work of Théo Meyer from www.strataggem.com
Hello Théo Meyer,
With respect to the delay, it turns out that the request to increase security is met by a "device in wrong state" error. It is still unclear what is causing this. Upon further investigation it turns out that the command timeout is defined in Bluetooth spec section 3.4 SMP TIMEOUT and is 30 seconds. The only way to abort the command before 30 sec is to disconnect however with this KBA we are trying to re-establish bonding in the same session without disconnecting.