SC field in AuthReq pairing response

[Lorens]

Hi, I noticed that I can't bond successfully with my device using iOs 9.1 with Nrf Master control panel iOs app. When I insert the PINCODE, the device immediatly disconnects, and debugging it seems that iOs sends a diconnection command (BLE_GAP_EVT_DISCONNECTED). I read that this problem is due to the fact that iOS 9 is now using the new LE Secure Connections pairing model, and the SC bit is set to 1 in the pairing request. (stackoverflow.com/.../ios-9-1-ble-connects-and-immediately-disconnects)

I checked in the bluetooth core V 4.2 specs that in bonding procedure there is that bitfield in the octect 3 of pairing response called AuthReq, but I couldn't find any way to set it with softdevice 8.0.0.0. I guess the problem could be that one, but I couldn't find a way to test it. So is it possible to change that bit or do you have any information about that problem? I know S110 8.0.0.0 is compliant to V4.1 bluetooth specs, but I have this problem and I don't know how to fix it.

Thank you

[Ulrich Myhre]

You cannot set the SC field in S110 8.x, because it does not support LE Secure Connections. It will always be set to 0 in the AuthReq field in the Pairing Response PDU. Both devices need to set this bit to end up doing LESC pairing, so I do not think is the reason. The reason can be that you set the OOB flag though.

Do you get an BLE_GAP_EVT_AUTH_STATUS event? What's its status? What is the 'reason' field of the disconnected event?

[Lorens]

Thank you Ulrich. What I see when the BLE_GAP_EVT_AUTH_STATUS event happens is BLE_GAP_SEC_STATUS_SUCCESS in p_ble_evt->evt.gap_evt.params.auth_status.auth_status. this should mean that the PIN was right. The reason field on the disconnect event is 0x13 BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION. About thee OOB answering in evt BLE_GAP_EVT_SEC_PARAMS_REQUEST I use:

sd_ble_gap_sec_params_reply(m_conn_handle , BLE_GAP_SEC_STATUS_SUCCESS , &own_params, NULL);

where:

own_params.bond = 1; own_params.mitm = 1; own_params.io_caps = BLE_GAP_IO_CAPS_DISPLAY_ONLY; own_params.oob = 0; own_params.min_key_size = 7; own_params.max_key_size = 16; Any Ideas? It seems that iOs doesn't like some answer I provide??

[Lorens]

I also found this topic that maybe could help to find out the solution. The problem seems similar: forums.developer.apple.com/.../20585

[RK]

Despite the 'SC' answer being marked as correct on that thread, it wasn't actually clear to me whether it was or not. So I followed up to ask what it was they did on their firmware side to fix it, because they claimed they did.

Note the suggestion in that thread is not that you need to be able to set the SC bit yourself and use LESC pairing, but that the peer (the nrf51 in this case) assumes that bit is zero and uses zero when it generates the key instead of all the bits actually set in the request. Those bits appear to have two uses, one to express features (which the peer doesn't have to support) and two, as raw bits used in key generation. The suggestion in the thread is that that reserved bit is masked to zero during key generation (because the peer doesn't anticipate it being anything apart from zero) and thus generates a bad key.

[RK]

finally found the right piece of the spec, it's Vol 3, Part H, 2.2.3 in the 4.0 spec and Vol 3, H, 2.3.5.5 in the 4.2 spec. You use the Pairing Request (preq) in the confirm generating function one of the inputs.

The Apple Engineer in that thread is suggesting that instead of using the paring request which was received, the softdevice is masking out the reserved bits in the AuthReq field of that request, assuming them to be zero (they were reserved previously and only now are used) and using that instead.

That seems a bit of a stretch, I wonder what evidence he has to support suggesting that. It's certainly possible but I can't think he'd put it forward as a hypothesis so strongly unless he'd already come across that exact behavious.