Hi all! I'm looking into how to a BLE slave should ask the master to initiate encryption, if an LTK exists, but the master has not yet started encryption on its own. Per the spec, the SMP "Security Request" packet should be sent. What I'm wondering about is how the "sc" bit in that packet should be set. I think the spec isn't clear here. Assume the local device supports SC but the LTK stored was not created using SC, should we set the "sc" bit to 1 or 0? In SMP specification, section 2.4.6 "Security Request": "After receiving a Security Request, the master shall first check whether it has the required security information to enable encryption; see Section 2.4.4.2. If this information is missing or does not meet the security properties requested by the slave, then the master shall initiate the pairing procedure." What I'm wondering is if this "sc" bit is considered part of the "security properties requested" or not. It is part of the "authentication requirements" field which is a bit field that "indicates the requested security properties", but according to the SMP specification, section 3.6.7 "Security Request": "The SC field is a 1 bit flag. If LE Secure Connections pairing is supported by the device, then the SC field shall be set to 1, otherwise it shall be set to 0. If both devices support LE Secure Connections pairing, then LE Secure Connections pairing shall be used, otherwise LE Legacy pairing shall be used." In my opinion, that indicates that the "sc" bit should not be treated as part of the "security properties requested" but rather simply indicates if SC are supported or not, since the spec does not allow us to set it to 0 if we support SC as I see it, for example in the case we have a LTK generated using the legacy way and want to use that key. Another possible interpretation would be that it's part of "security properties requested" but it's impossible to ask for a non-SC level if we support SC, i.e. basically the slave cannot request the master to start encryption with the legacy-generated LTK we already have. Consider the case when the remote device doesn't support SC (but is at least Core 4.2-compliant and hence understands the protocol) and interprets the spec in the way that the "sc" bit is part of the "security properties requested", but we (slave) set the "sc" bit to 1 since we support SC. Then this would trigger a re-pairing all the time the slave wants to start encryption using the LTK we already have. Note that a firmware update (at either device) could enable support for SC, if it wasn't supported before. We don't want a re-pairing being forced just because of a firmware update, right? When I read the BlueZ implementation at https://github.com/bluez/bluetooth-next/blob/9d31d2338950293ec19d9b095fbaa9030899dcb4/net/bluetooth/smp.c#L2308, it seems the BlueZ developers' interpretation is that the "sc" bit is part of the "security properties requested". At the same time, at https://github.com/bluez/bluetooth-next/blob/9d31d2338950293ec19d9b095fbaa9030899dcb4/net/bluetooth/smp.c#L2398 we have that the "sc" bit is set according to if SC is supported or not (not depending on the requested security level), when sending a Security Request. So it seems the BlueZ developers use the interpretation where it it both indicates if SC is supported, but at the same time also is part of the "security properties requested". I'm also a bit skeptical to build_pairing_cmd. Should the authReq more or less just be copied from the Security Request to the Pairing Request? Why not just always request for the highest security possible in the Pairing Request? If the slave wants lower security it can say so in the pairing response. Otherwise we could get in a situation where we previously have an LTK without mitm security, and we send a security request with mitm=0 in order to use this, but the master device has removed the bond, and hence sends a pairing request with mitm=0 instead of mitm=1, even though mitm would be preferred, if possible. So my question is simply, if I want to enable encryption to provide integrity and confidentiality (GAP 10.6 Encryption Procedure) at a peripheral, using the key I already have, or if the master deleted the key create a new bond with the best possible security properties, what should I set the "sc" and "mitm" bits to in the Security Request that I send, in case the local device supports both SC and MITM, but the LTK that is stored wasn't generated using SC and/or MITM? Let me know if my concerns make sense or if I have totally missed something in the specification or so. /Emil
