We can only determine the final security level when both pairing request
and response have been exchanged. When initiating pairing the starting
target security level is set to MEDIUM unless explicitly specified to be
HIGH, so that we can still perform pairing even if the remote doesn't
have MITM capabilities. However, once we've received the pairing
response we should re-consult the remote and local IO capabilities and
upgrade the target security level if necessary.
Without this patch the resulting Long Term Key will occasionally be
reported to be unauthenticated when it in reality is an authenticated
one.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
This is a trivial change to use a proper define for the NoInputNoOutput
IO capability instead of hard-coded values.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There are several places that need to determine the security level that
an LTK can provide. This patch adds a convenience function for this to
help make the code more readable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When the local IO capability is NoInputNoOutput any attempt to convert
the remote authentication requirement to a target security level is
futile. This patch makes sure that we set the target security level at
most to MEDIUM if the local IO capability is NoInputNoOutput.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
All the cases where we mark SMP commands as dissalowed are their
respective command handlers. We can therefore simplify the code by
always clearing the bit immediately after testing it. This patch
converts the corresponding test_bit() call to a test_and_clear_bit()
call and also removes the now unused SMP_DISALLOW_CMD macro.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The SMP specification states that we should ignore any unknown bits from
the authentication requirement. We already have a define for masking out
unknown bits but we haven't used it in all places so far. This patch
adds usage of the AUTH_REQ_MASK to all places that need it and ensures
that we don't pass unknown bits onward to other functions.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We do nothing else with the auth variable in smp_cmd_pairing_rsp()
besides passing it to tk_request() which in turn only cares about
whether one of the sides had the MITM bit set. It is therefore
unnecessary to assign a value to it until just before calling
tk_request(), and this value can simply be the bit-wise or of the local
and remote requirements.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the remote side is not distributing its IRK but is distributing the
CSRK the next PDU after master identification is the Signing
Information. This patch fixes a missing SMP_ALLOW_CMD() for this in the
smp_cmd_master_ident() function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Whether through HCI with BR/EDR or SMP with LE when authentication fails
we should also notify any pending Pair Device mgmt command. This patch
updates the mgmt_auth_failed function to take the actual hci_conn object
and makes sure that any pending pairing command is notified and cleaned
up appropriately.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch fixes the following type of static analyzer warning (and
probably a real bug as well as the NULL check should be there for a
reason):
net/bluetooth/smp.c:1182 smp_conn_security() warn: variable dereferenced before check 'conn' (see line 1174)
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
SMP defines quite clearly when certain PDUs are to be expected/allowed
and when not, but doesn't have any explicit request/response definition.
So far the code has relied on each PDU handler to behave correctly if
receiving PDUs at an unexpected moment, however this requires many
different checks and is prone to errors.
This patch introduces a generic way to keep track of allowed PDUs and
thereby reduces the responsibility & load on individual command
handlers. The tracking is implemented using a simple bit-mask where each
opcode maps to its own bit. If the bit is set the corresponding PDU is
allow and if the bit is not set the PDU is not allowed.
As a simple example, when we send the Pairing Request we'd set the bit
for Pairing Response, and when we receive the Pairing Response we'd
clear the bit for Pairing Response.
Since the disallowed PDU rejection is now done in a single central place
we need to be a bit careful of which action makes most sense to all
cases. Previously some, such as Security Request, have been simply
ignored whereas others have caused an explicit disconnect.
The only PDU rejection action that keeps good interoperability and can
be used for all the applicable use cases is to drop the data. This may
raise some concerns of us now being more lenient for misbehaving (and
potentially malicious) devices, but the policy of simply dropping data
has been a successful one for many years e.g. in L2CAP (where this is
the *only* policy for such cases - we never request disconnection in
l2cap_core.c because of bad data). Furthermore, we cannot prevent
connected devices from creating the SMP context (through a Security or
Pairing Request), and once the context exists looking up the
corresponding bit for the received opcode and deciding to reject it is
essentially an equally lightweight operation as the kind of rejection
that l2cap_core.c already successfully does.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When we're in the process of receiving keys in phase 3 of SMP we keep
track of which keys are still expected in the smp->remote_key_dist
variable. If we still have some key bits set we need to continue waiting
for more PDUs and not needlessly call smp_distribute_keys(). This patch
fixes two such cases in the smp_cmd_master_ident() and
smp_cmd_ident_addr_info() handler functions.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds a define for the allowed bits of the key distribution
mask so we don't have to have magic 0x07 constants throughout the code.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Before the move the l2cap_chan the SMP context (smp_chan) didn't have
any kind of proper locking. The best there existed was the
HCI_CONN_LE_SMP_PEND flag which was used to enable mutual exclusion for
potential multiple creators of the SMP context.
Now that SMP has been converted to use the l2cap_chan infrastructure and
since the SMP context is directly mapped to a corresponding l2cap_chan
we get the SMP context locking essentially for free through the
l2cap_chan lock. For all callbacks that l2cap_core.c makes for each
channel implementation (smp.c in the case of SMP) the l2cap_chan lock is
held through l2cap_chan_lock(chan).
Since the calls from l2cap_core.c to smp.c are covered the only missing
piece to have the locking implemented properly is to ensure that the
lock is held for any other call path that may access the SMP context.
This means user responses through mgmt.c, requests to elevate the
security of a connection through hci_conn.c, as well as any deferred
work through workqueues.
This patch adds the necessary locking to all these other code paths that
try to access the SMP context. Since mutual exclusion for the l2cap_chan
access is now covered from all directions the patch also removes
unnecessary HCI_CONN_LE_SMP_PEND flag (once we've acquired the chan lock
we can simply check whether chan->smp is set to know if there's an SMP
context).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Now that the identity address update happens through its own deferred
work there's no need to have smp_distribute_keys anymore behind a second
deferred work. This patch removes this extra construction and makes the
code do direct calls to smp_distribute_keys() again.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The identity address update of all channels for an l2cap_conn needs to
take the lock for each channel, i.e. it's safest to do this by a
separate workqueue callback.
Previously this was partially solved by moving the entire SMP key
distribution behind a workqueue. However, if we want SMP context locking
to be correct and safe we should always use the l2cap_chan lock when
accessing it, meaning even smp_distribute_keys needs to take that lock
which would once again create a dead lock when updating the identity
address.
The simplest way to solve this is to have l2cap_conn manage the deferred
work which is what this patch does. A subsequent patch will remove the
now unnecessary SMP key distribution work struct.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When smp_resume_cb is called if we're not encrypted (i.e. the callback
wasn't called because the connection became encrypted) we shouldn't take
any action at all. This patch moves also the security_timer cancellation
behind this condition.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The SMP security timer used to be able to modify the SMP context state
but now days it simply calls hci_disconnect(). It is therefore
unnecessary to have extra sanity checks for the SMP context after
canceling the timer.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Returning failure from the SMP data parsing function will cause an
immediate disconnect, making any attempts to send a response PDU futile.
This patch updates the function to always either send a response or
return an error, but never both at the same time:
* In the case that HCI_LE_ENABLED is not set we want to send a Pairing Not
Supported response but it is not required to force a disconnection, so
do not set the error return in this case.
* If we get garbage SMP data we can just fail with the handler function
instead of also trying to send an SMP Failure PDU.
* There's no reason to force a disconnection if we receive an unknown SMP
command. Instead simply send a proper Command Not Supported SMP
response.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Relying on the l2cap_conn_del procedure (triggered through the
l2cap_conn_shutdown API) to get the connection disconnected is not
reliable as it depends on all users releasing (through hci_conn_drop)
and that there's at least one user (so hci_conn_drop is called at least
one time).
A much simpler and more reliable solution is to call hci_disconnect()
directly from the SMP code when we want to disconnect. One side-effect
this has is that it prevents any SMP Failure PDU from being sent before
the disconnection, however neither one of the scenarios where
l2cap_conn_shutdown was used really requires this.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There are no external users of smp_chan_destroy() so make it private to
smp.c. The patch also moves the function higher up in the c-file in
order to avoid forward declarations.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The smp_distribute_keys() function calls smp_notify_keys() which in turn
calls l2cap_conn_update_id_addr(). The l2cap_conn_update_id_addr()
function will iterate through all L2CAP channels for the respective
connection: lock the channel, update the address information and unlock
the channel.
Since SMP is now using l2cap_chan callbacks each callback is called with
the channel lock held. Therefore, calling l2cap_conn_update_id_addr()
would cause a deadlock calling l2cap_chan_lock() on the SMP channel.
This patch moves calling smp_distribute_keys() through a workqueue so
that it is never called from an L2CAP channel callback.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
All places needing to cancel the security timer also call
smp_chan_destroy() in the same go. To eliminate the need to do these two
calls in multiple places simply move the timer cancellation into
smp_chan_destroy().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch adds an SMP-internal timeout callback to remove the depenency
on (the soon to be removed) l2cap_conn->security_timer. The behavior is
the same as with l2cap_conn->security_timer except that the new
l2cap_conn_shutdown() public function is used instead of the L2CAP core
internal l2cap_conn_del().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In the case that the SMP recv callback returns error the calling code in
l2cap_core.c expects that it still owns the skb and will try to free it.
The SMP code should therefore not try to free the skb if it return an
error. This patch fixes such behavior in the SMP command handler
function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
To restore pre-l2cap_chan functionality we should be trying to
disconnect the connection when receviving garbage SMP data (i.e. when
the SMP command handler fails). This patch renames the command handler
back to smp_sig_channel() and adds a smp_recv_cb() wrapper function for
calling it. If smp_sig_channel() fails the code calls
l2cap_conn_shutdown().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There's no need to export the smp_distribute_keys() function since the
resume callback is called in the same scenario. This patch makes the
smp_notify_keys function private (at the same time moving it higher up
in smp.c to avoid forward declarations) and adds a resume callback for
SMP to call it from there instead.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Now that we have all the necessary pieces in place we can fully convert
SMP to use the L2CAP channel infrastructure. This patch adds the
necessary callbacks and removes the now unneeded conn->smp_chan pointer.
One notable behavioral change in this patch comes from the following
code snippet:
- case L2CAP_CID_SMP:
- if (smp_sig_channel(conn, skb))
- l2cap_conn_del(conn->hcon, EACCES);
This piece of code was essentially forcing a disconnection if garbage
SMP data was received. The l2cap_conn_del() function is private to
l2cap_conn.c so we don't have access to it anymore when using the L2CAP
channel callbacks. Therefore, the behavior of the new code is simply to
return errors in the recv() callback (which is simply the old
smp_sig_channel()), but no disconnection will occur.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Now that we have per-adapter SMP data thanks to the root SMP L2CAP
channel we can take advantage of it and attach the AES crypto context
(only used for SMP) to it. This means that the smp_irk_matches() and
smp_generate_rpa() function can be converted to internally handle the
AES context.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch creates the initial SMP L2CAP channels and a skeleton for
their callbacks. There is one per-adapter channel created upon adapter
registration, and then one channel per-connection created through the
new_connection callback. The channels are registered with the reserved
CID 0x1f for now in order to not conflict with existing SMP
functionality. Once everything is in place the value can be changed to
what it should be, i.e. L2CAP_CID_SMP.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
As preparation for moving SMP to use l2cap_chan infrastructure we need
to move the (de)initialization functions to smp.c (where they'll
eventually need access to the local L2CAP channel callbacks).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The code is consistently using the HCI_CONN_LE_SMP_PEND flag check for
the existence of the SMP context, with the exception of this one place
in smp_sig_channel(). This patch converts the place to use the flag just
like all other instances.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In the smp_cmd_sign_info() function the SMP_DIST_SIGN bit is explicitly
cleared early on in the function. This means that there's no need to
check for it again before calling smp_distribute_keys().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The HCI_PAIRABLE flag isn't actually controlling whether we're pairable
but whether we're bondable. Therefore, rename it accordingly.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Devices using resolvable private addresses are required to provide
an identity resolving key. These devices can not be found using
the current controller white list support. This means if the kernel
knows about any devices with an identity resolving key, the white
list filtering must be disabled.
However so far the kernel kept identity resolving keys around even
for devices that are not using resolvable private addresses. The
notification to userspace clearly hints to not store the key and
so it is best to just remove the key from the kernel as well at
that point.
With this it easy now to detect when using the white list is
possible or when kernel side resolving of addresses is required.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The EOPNOTSUPP and ENOTSUPP errors are very similar in meaning, but
ENOTSUPP is a fairly new addition to POSIX. Not all libc versions know
about the value the kernel uses for ENOTSUPP so it's better to use
EOPNOTSUPP to ensure understandable error messages.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If user space has a NoInputNoOutput IO capability it makes no sense to
bother it with confirmation requests. This patch updates both SSP and
SMP to check for the local IO capability before sending a user
confirmation request to user space.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
To make the code more understandable it makes sense to use the new HCI
defines for connection role instead of a "bool master" parameter. This
makes it immediately clear when looking at the function calls what the
last parameter is describing.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Having a dedicated u8 role variable in the hci_conn struct greatly
simplifies tracking of the role, since this is the native way that it's
represented on the HCI level.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
In the case that the key distribution bits cause us not to generate a
local LTK we should not try to re-encrypt if we're currently encrypted
with an STK. This patch fixes the check for this in the
smp_sufficient_security function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If the remote device tries to initiate bonding with us and we don't have
HCI_PAIRABLE set we should just flat out reject the request. This brings
SMP in line with how the flag is used for BR/EDR SSP.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When the SMP context is created all flags default to zero. To determine
that we are the initiators it's therefore best to simply change the flag
value when we know we're sending the first SMP PDU. Clearing the flag
when receiving a Pairing Request is not correct since the request may be
a response to a previous Security Request from us (for which we would
already have correctly set the flag). Same goes for receiving a Security
Request which may be coming after us already starting pairing by sending
a Pairing Request.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Whether we bond or not should not have any impact on the user
interaction model. This patch removes an incorrect fall-back from
JUST_CFM to JUST_WORKS in case we're not bonding.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
For incoming requests we want to let the user know that pairing is
happening since otherwise there could be access to MEDIUM security
services without any user interaction at all. Therefore, set the
selected method to JUST_CFM instead of JUST_WORKS and let it be
converted back to JUST_WORKS later if we are the initators.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If we're encrypted with the STK we should allow re-encryption with an
LTK even though the achieved security level is the same. This patch adds
the necessary logic to the smp_sufficient_security function which is
used to determine whether to proceed with encryption or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There are certain subtle differences in behavior when we're encrypted
with the STK, such as allowing re-encryption even though the security
level stays the same. Because of this, add a flag to track whether we're
encrypted with an STK or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If we're already encrypted with a good enough LTK we should just ignore
an incoming SMP Security Request. The code was already taking care of
this in the smp_conn_security function before calling smp_ltk_encrypt
but failed to do the same in smp_cmd_security_req. This patch fixes the
issue by moving up the smp_sufficient_security function and using it in
the Security Request handler before trying to request encryption.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The return value of smp_ltk_encrypt is simple boolean, so just use
bool and make the code a bit more readable.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The smp_conn member of struct hci_conn was simply a pointer to the
l2cap_conn object. Since we already have hcon->l2cap_data that points to
the same thing there's no need to have this second variable. This patch
removes it and changes the single place that was using it to use
hcon->l2cap_data instead.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Johan Hedberg
Marcel Holtmann