linux.git/net/bluetooth/smp.h, branch v4.2

Bluetooth: Add function for generating LE SC out-of-band data

2015-03-16T08:31:27+00:00

This patch adds a smp_generate_oob function that allows to create
local out-of-band data that can be used for pairing and also provides
the confirmation and random value.

Signed-off-by: Marcel Holtmann 
Signed-off-by: Johan Hedberg

Bluetooth: Add skeleton for SMP self-tests

2014-12-30T07:54:33+00:00

This patch adds the initial skeleton and kernel config option for SMP
self-tests.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix missing const declarations in SMP functions

2014-12-03T15:51:21+00:00

Several SMP functions take read-only data. This patch fixes the
declaration of these parameters to use the const specifier as
appropriate.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Set the correct security level for SC LTKs

2014-12-03T15:51:15+00:00

When the looked-up LTK is one generated by Secure Connections pairing
the security level it gives is BT_SECURITY_FIPS. This patch updates the
LTK request event handler to correctly set this level.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Add mgmt support for LE Secure Connections LTK types

2014-12-03T15:51:15+00:00

We need a dedicated LTK type for LTK resulting from a Secure Connections
based SMP pairing. This patch adds a new define for it and ensures that
both the New LTK event as well as the Load LTKs command supports it.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Add basic SMP defines for LE Secure Connections

2014-12-03T15:51:14+00:00

This patch adds basic SMP defines for commands, error codes and PDU
definitions for the LE Secure Connections feature.

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Add key preference parameter to smp_sufficient_security

2014-11-15T00:46:49+00:00

So far smp_sufficient_security() has returned false if we're encrypted
with an STK but do have an LTK available. However, for the sake of LE
CoC servers we do want to let the incoming connection through even
though we're only encrypted with the STK.

This patch adds a key preference parameter to smp_sufficient_security()
with two possible values (enum used instead of bool for readability).

Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann

Bluetooth: Add smp_ltk_sec_level() helper function

2014-09-11T00:45:24+00:00

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 
Signed-off-by: Marcel Holtmann

Bluetooth: Add strict checks for allowed SMP PDUs

2014-09-08T17:07:56+00:00

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 
Signed-off-by: Marcel Holtmann

Bluetooth: Make smp_chan_destroy() private to smp.c

2014-08-14T06:49:24+00:00

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 
Signed-off-by: Marcel Holtmann