BLE pairing fails in SecurityManager example with Android 12 and iOS using nrf Connect app

[2EV-ymarrakchi]

Description of defect

Running the SecurityandPrivacy BLE example demonstrating Security Manager implementation only works with 2 microcontrollers doing the demo.
Pairing process fails with error code 'SEC_STATUS_UNSPECIFIED' (0x88) in pairingResult when attempting to pair from Android 12 or iOS as masters. The SecurityandPrivacy was slightly modified to run only as a peripheral in an Arduino Nano 33 BLE (nrf52840). Traces were enabled but does not give additional information about the problem (error code: DM_SEC_PAIR_FAIL_IND ). The same error occurs when securityManager is initialized with static passkey and SecurityManager::IO_CAPS_DISPLAY_ONLY
On the master side an incorrect pin error pops up a few seconds after accepting pairing 2 times.

Target(s) affected by this defect ?

Arduino Nano 33 BLE (nrf58240)

Toolchain(s) (name and version) displaying this defect ?

arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi

What version of Mbed-os are you using (tag or sha) ?

mbed-os-6.14

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Uploading firmware to target with Arduino IDE, mbed source code is compiled with script https://github.com/arduino/ArduinoCore-mbed

How is this defect reproduced ?

After uploading the code, the example works correctly with a second board running SecurityandPrivacy example as a master, but trying to connect with Android phone or iPhone does not work. Traces for both cases are attached.
traces pairing 2 boards AN33BLE.txt
traces pairing Android.txt

https://github.com/ARMmbed/mbed-os-example-ble/tree/development/BLE_SecurityAndPrivacy

[ufocia]

I hope the HTML tables below are visible to everyone.

I'm experiencing a similar problem, as are others, e.g. here. Admittedly, I have not performed as much debugging as the OP.

At first glance of OP's debug it appears that there is a fatal mismatch between the pairing requests and responses in the Android case. The two AN33BLE are a perfect match for each other, as far as I can tell. Please observe:

2 x AN33BLE:
Connection 1 - pairing request received: use_oob = false, authentication = 11, initiator_dist = 03, responder_dist = 03
...
Connection 1 - Send pairing response: oob = false, auth = 11, initiator dist = 03, responder dist = 03
...
stack_handler received DM_SEC_ENCRYPT_IND
... (encryption negotiated)

---

Android + AN33BLE
Connection 1 - pairing request received: use_oob = false, authentication = 2D, initiator_dist = 0F, responder_dist = 0F
...
Connection 1 - Send pairing response: oob = false, auth = 11, initiator dist = 03, responder dist = 03
...
stack_handler received DM_SEC_PAIR_FAIL_IND
... (more or less the end of the road)

---

The flow for the Andrid case looks very similar to BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part H, C.5.2 Central rejects pairing because of key size.

I decoded the Android + AN33BLE Authentication requirements flags (auth) according to the table in BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part H Figure 3.3: Authentication requirements flags (pg. 1601):

	LSB							MSB	Hex
Device	Bond[1]	Bond[2]	MITM	SC	Keypress	CT2	RFU[1]	RFU[2]
Android	1	0	1	1	0	1	0	0	2D
AN33BLE	1	0	0	0	1	0	0	0	11

I also decoded the the Android + AN33BLE Initiator Key Distribution/Generation field and Responder
Key Distribution/Generation field (initiator dist and responder dist respectively) according to the table in BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part H Figure 3.11: LE Key Distribution format (pg. 1610):

	LSB							MSB	Hex
Device	EncKey	IdKey	SignKey	LinkKey	RFU[1]	RFU[2]	RFU[3]	RFU[4]
Android	1	1	1	1	0	0	0	0	F
AN33BLE	1	1	0	0	0	0	0	0	3

I just started digging into this, so I'm not sure how much of this is implementation versus merely configuration. Could someone with a bit more experience/expertise please chime in?