Re: [RFC 2/2] Bluetooth: Add support for returning the encryption key size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Vinicius,

> This will be useful when userspace wants to restrict some kinds of
> operations based on the length of the key size used to encrypt the
> link.
> 
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@xxxxxxxxxxxxx>
> ---
>  include/net/bluetooth/bluetooth.h |    1 +
>  net/bluetooth/l2cap_sock.c        |    4 ++++
>  2 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index acf186d..28ae91a 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -56,6 +56,7 @@
>  #define BT_SECURITY	4
>  struct bt_security {
>  	__u8 level;
> +	__u8 key_size;
>  };

there is one thing we need to keep in mind. Who is enforcing the
encryption key size and triggers are re-pairing if needed? Do we wanna
do that inside kernel space or have userspace involved?

Essentially besides maybe exporting the current encryption key size, you
also wanna enforce a minium encryption key size.

We can do this with this socket option in one go. I am fine with that,
but we need to have a way to ensure minium encryption key size or 0 if
we do not care.

And of course the same now applies for PIN code length. Even if with
Simple Pairing this does not matter anymore. For Legacy Pairing this is
still relevant.

Regards

Marcel


--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux