This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

SC field in AuthReq pairing response

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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related