Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Emil Lenngren <emil.lenngren@gmail.com>
Date:   Wed, 19 May 2021 19:41:43 +0200
Message-ID: <CAO1O6seA_k_Fsm=VJvx30kui2tNeJd8tN-a=uXNQnPk9xy6jZQ@mail.gmail.com>
Subject: SC bit in SMP Security Request (BLE)
To:     Bluez mailing list <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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