2019-05-22 07:06:15

by Marcel Holtmann

[permalink] [raw]
Subject: [RFC] Bluetooth: Check key sizes only when Secure Simple Pairing is enabled

The encryption is only mandatory to be enforced when both sides are using
Secure Simple Pairing and this means the key size check makes only sense
in that case.

On legacy Bluetooth 2.0 and earlier devices like mice the encryption was
optional and thus causing an issue if the key size check is not bound to
using Secure Simple Pairing.

Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections")
Signed-off-by: Marcel Holtmann <[email protected]>
Cc: [email protected]
---
net/bluetooth/hci_conn.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 3cf0764d5793..7516cdde3373 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1272,8 +1272,13 @@ int hci_conn_check_link_mode(struct hci_conn *conn)
return 0;
}

- if (hci_conn_ssp_enabled(conn) &&
- !test_bit(HCI_CONN_ENCRYPT, &conn->flags))
+ /* If Secure Simple Pairing is not enabled, then legacy connection
+ * setup is used and no encryption or key sizes can be enforced.
+ */
+ if (!hci_conn_ssp_enabled(conn))
+ return 1;
+
+ if (!test_bit(HCI_CONN_ENCRYPT, &conn->flags))
return 0;

/* The minimum encryption key size needs to be enforced by the
--
2.20.1


2019-05-23 14:54:35

by Vasily Khoruzhick

[permalink] [raw]
Subject: Re: [RFC] Bluetooth: Check key sizes only when Secure Simple Pairing is enabled

On Wed, May 22, 2019 at 12:05 AM Marcel Holtmann <[email protected]> wrote:
>
> The encryption is only mandatory to be enforced when both sides are using
> Secure Simple Pairing and this means the key size check makes only sense
> in that case.
>
> On legacy Bluetooth 2.0 and earlier devices like mice the encryption was
> optional and thus causing an issue if the key size check is not bound to
> using Secure Simple Pairing.
>
> Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections")
> Signed-off-by: Marcel Holtmann <[email protected]>
> Cc: [email protected]

Tested-by: Vasily Khoruzhick <[email protected]>

> ---
> net/bluetooth/hci_conn.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 3cf0764d5793..7516cdde3373 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -1272,8 +1272,13 @@ int hci_conn_check_link_mode(struct hci_conn *conn)
> return 0;
> }
>
> - if (hci_conn_ssp_enabled(conn) &&
> - !test_bit(HCI_CONN_ENCRYPT, &conn->flags))
> + /* If Secure Simple Pairing is not enabled, then legacy connection
> + * setup is used and no encryption or key sizes can be enforced.
> + */
> + if (!hci_conn_ssp_enabled(conn))
> + return 1;
> +
> + if (!test_bit(HCI_CONN_ENCRYPT, &conn->flags))
> return 0;
>
> /* The minimum encryption key size needs to be enforced by the
> --
> 2.20.1
>

2019-06-04 12:27:33

by Bastien Nocera

[permalink] [raw]
Subject: Re: [RFC] Bluetooth: Check key sizes only when Secure Simple Pairing is enabled

On Thu, 2019-05-23 at 07:53 -0700, Vasily Khoruzhick wrote:
> On Wed, May 22, 2019 at 12:05 AM Marcel Holtmann <[email protected]
> > wrote:
> > The encryption is only mandatory to be enforced when both sides are
> > using
> > Secure Simple Pairing and this means the key size check makes only
> > sense
> > in that case.
> >
> > On legacy Bluetooth 2.0 and earlier devices like mice the
> > encryption was
> > optional and thus causing an issue if the key size check is not
> > bound to
> > using Secure Simple Pairing.
> >
> > Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size
> > for LE and BR/EDR connections")
> > Signed-off-by: Marcel Holtmann <[email protected]>
> > Cc: [email protected]
>
> Tested-by: Vasily Khoruzhick <[email protected]>

I've asked for this patch to be included in the current Fedora release:
https://lists.fedoraproject.org/archives/list/[email protected]/thread/YE5OGFZRDJL2TFJK3RWU7AAWV3PFRMNB/

Hopefully, that means that it gets a bit more testing and gets merged upstream.

Cheers