SC field in AuthReq pairing response

RE: SC field in AuthReq pairing response

Vidar Berg — Tue, 01 Mar 2016 07:59:04 GMT

I'd recommend using the device manager module to handle bonding if you're not already. This will handle all the necessary pairing events, which means that you can remove all handling in your application if any.

RE: SC field in AuthReq pairing response

Lorens — Mon, 29 Feb 2016 17:02:59 GMT

Yes, I've always checked the error, since that version of iOs I've never had any problem. The connection is not broken from my device, the reason is always remote user.

RE: SC field in AuthReq pairing response

RK — Mon, 29 Feb 2016 16:54:38 GMT

do you error-check the result of sd_ble_gap_sec_params_reply()? If you do then it's probably returning an error telling you that NULL isn't a valid parameter and you're going to the error handler and resetting, hence breaking the connection.

RE: SC field in AuthReq pairing response

Lorens — Mon, 29 Feb 2016 16:42:46 GMT

@Ulrich: the disconnection reason is 0x13 REMOTE_USER_TERMINATED_CONNECTION. @Vidar: I made several tries using LightBlue app or even Master Control Panel. The problem seems to be solved, I mean now iOs is not disconnecting. I changed the parameter in the function: sd_ble_gap_sec_params_reply; the last one parameter I used to use NULL, now I gave a pointer to the structure ble_gap_sec_keyset_t. Probably before there was not the need to store the key. With this pointer I suppose the softdevice is storing the key, that wasn't storing in case of NULL. But Maybe someone could PROVIDE a more precise answer.

RE: SC field in AuthReq pairing response

Vidar Berg — Mon, 29 Feb 2016 14:41:41 GMT

@Lorens, have you been able to resolve this? I've tried passkey pairing on multiple occasions with ios 9.2.1 and have not experienced that iOS has terminated the link unless the bonding flag was set to false (pairing not supported apparently).

RE: SC field in AuthReq pairing response

RK — Fri, 26 Feb 2016 09:47:24 GMT

Thanks Ulrich - I thought it was a bit premature for the engineer to leap to that conclusion, and more so for the guy to mark it as the 'right answer'. It seemed somewhat unlikely that you'd change the request before using it, more likely you would just ignore the bits you didn't care about, as you do.

RE: SC field in AuthReq pairing response

Ulrich Myhre — Fri, 26 Feb 2016 09:36:45 GMT

@RK: I don't have the HW to test this at the moment, but looking at the 8.0.0 code, the whole preq is copied verbatim from the radio. And in the pairing confirm generation, it is again used without modification. There are also conformance tests to verify that we correctly ignore these fields, so I believe this is not the problem. But the tests and the current stack have changed a lot since 8.0.0, so my memory can be fuzzy.

@Lorens: The disconnection reason was not provided still, and this could quickly solve this. If it's "MIC Failure", then something is up with the key generation. But if it's just "Remote peer disconnected", then it's likely that iOS just killed the connection because nothing interesting was happening. I think they operate with a few seconds of timeout before they tear it down. Are you also able to pair without mitm?

RE: SC field in AuthReq pairing response

RK — Fri, 26 Feb 2016 01:41:01 GMT

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.

RE: SC field in AuthReq pairing response

RK — Fri, 26 Feb 2016 01:00:57 GMT

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.

RE: SC field in AuthReq pairing response

Lorens — Thu, 25 Feb 2016 22:08:27 GMT

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

RE: SC field in AuthReq pairing response

Lorens — Thu, 25 Feb 2016 16:21:11 GMT

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??

RE: SC field in AuthReq pairing response

Ulrich Myhre — Thu, 25 Feb 2016 09:35:41 GMT

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?