Hi Emil, > 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. I have read this email a few times now and I am still confused on what you are asking. Can you show us a btmon trace of what is going on and how this works right now. Regards Marcel
