BLE Pairing FAILURE if fast enough. CRITICAL SECURITY FLOW.

Hallo everybody,

I successfully implemented on the NUS example the Pairing with the Passkey with the following Peer Manager configuration without LESC.


#define SEC_PARAM_BOND                  1                                           // ** Perform bonding.
#define SEC_PARAM_MITM                  1                                           // ** Man In The Middle protection required (applicable when display module is detected).
#define SEC_PARAM_LESC                  0                                        // ** LE Secure Connections enabled.
#define SEC_PARAM_KEYPRESS              0                                           // ** Keypress notifications not enabled.
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_DISPLAY_ONLY                // ** Display I/O capabilities.
#define SEC_PARAM_OOB                   0                                           // ** Out Of Band data not available.
#define SEC_PARAM_MIN_KEY_SIZE          7                                           // ** Minimum encryption key size.
#define SEC_PARAM_MAX_KEY_SIZE          16                                          // ** Maximum encryption key size.

#define PASSKEY_TXT                     "Passkey:"                                  // ** Message to be displayed together with the pass-key.
#define PASSKEY_TXT_LENGTH              8                                           // ** Length of message to be displayed together with the pass-key.
#define PASSKEY_LENGTH                  6                                           // ** Length of pass-key received by the stack for display.

static pm_peer_id_t m_peer_to_be_deleted = PM_PEER_ID_INVALID;

and the BLE EVENT:

case BLE_GAP_EVT_PASSKEY_DISPLAY:
        {
                           uint_8 passkey [] = "123456"
                            // Set Passkey into SoftDevice
                            ble_opt_t ble_opt;
                            ble_opt.gap_opt.passkey.p_passkey = &passkey[0];
                            err_code = sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &ble_opt);
                            APP_ERROR_CHECK(err_code);
                            // Print out Passkey
                            printf ("Static Passkey: %s\r\n", passkey);
                     
                        
        } break;

Apparently everything works fine as long as in the Mobile APP (BluePunch) the user is NOT fast enough to press on READ characteristic.

What I mean is that if you are fast enough to press "Cancel" while the PIN popup request shows you are still able to get into the Read and Write Characteristic and you can successfully read and change whatever you need.

If you let the APP going without pressing the button and such it will raise the timeout and everything seems to be working as expected.

Does anybody faced this issue before?

I am using a Samsung S10 but I think this critical issue is widely spread on other devices too.

I hope that somebody will come up with some asnwers...