Re: [PATCH] Bluetooth: Fix for L2CAP/LE/CFC/BV-15-C

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

 



Hi Magdalena,

> This is required for the qualification test L2CAP/LE/CFC/BV-15-C
> 
> Implementation does not allow to set different key size for SMP and
> L2CAP, which is needed for a current specification of the test. This fix
> workarounds it with the debugfs variable le_l2cap_min_key_size.
> 
> Logs from the test when the IUT uses a min and max l2cap encryption key size 16.
> $ echo 16 > /sys/kernel/debug/bluetooth/hci0/le_l2cap_min_key_size
> The lower tester uses a key size 7.
> 
>> ACL Data RX: Handle 99 flags 0x02 dlen 11                #34 [hci0] 25.007392
>      SMP: Pairing Request (0x01) len 6
>        IO capability: DisplayYesNo (0x01)
>        OOB data: Authentication data not present (0x00)
>        Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
>        Max encryption key size: 7
>        Initiator key distribution: <none> (0x00)
>        Responder key distribution: <none> (0x00)
> < ACL Data TX: Handle 99 flags 0x00 dlen 11                #35 [hci0] 25.007591
>      SMP: Pairing Response (0x02) len 6
>        IO capability: KeyboardDisplay (0x04)
>        OOB data: Authentication data not present (0x00)
>        Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
>        Max encryption key size: 16
>        Initiator key distribution: <none> (0x00)
>        Responder key distribution: <none> (0x00)
> @ MGMT Event: New Long Term Key (0x000a) plen 37      {0x0001} [hci0] 28.788872
>        Store hint: Yes (0x01)
>        LE Address: C0:DE:C0:FF:FF:01 (OUI C0-DE-C0)
>        Key type: Unauthenticated key from P-256 (0x02)
>        Master: 0x00
>        Encryption size: 7
>        Diversifier: 0000
>        Randomizer: 0000000000000000
>        Key: 529e11e8c7b9f5000000000000000000
> 
> <snip>
> 
> After pairing with key size 7, L2CAP connection is requested which
> requires key size 16.
> 
>> ACL Data RX: Handle 99 flags 0x02 dlen 18                #56 [hci0] 34.998084
>      LE L2CAP: LE Connection Request (0x14) ident 3 len 10
>        PSM: 244 (0x00f4)
>        Source CID: 64
>        MTU: 256
>        MPS: 284
>        Credits: 1
> < ACL Data TX: Handle 99 flags 0x00 dlen 18                #57 [hci0] 34.998325
>      LE L2CAP: LE Connection Response (0x15) ident 3 len 10
>        Destination CID: 0
>        MTU: 0
>        MPS: 0
>        Credits: 0
>        Result: Connection refused - insufficient encryption key size (0x0007)
> 
> Signed-off-by: Magdalena Kasenberg <magdalena.kasenberg@xxxxxxxxxxx>
> Reviewed-by: Szymon Janc <szymon.janc@xxxxxxxxxxx>
> Cc: Szymon Janc <szymon.janc@xxxxxxxxxxx>
> ---
> include/net/bluetooth/hci_core.h |  1 +
> net/bluetooth/hci_core.c         |  1 +
> net/bluetooth/hci_debugfs.c      | 30 ++++++++++++++++++++++++++++++
> net/bluetooth/l2cap_core.c       | 25 +++++++++++++++++++++++++
> 4 files changed, 57 insertions(+)
> 
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index ebdd4afe30d2..0bf0543efec5 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -379,6 +379,7 @@ struct hci_dev {
> 	__u16		auth_payload_timeout;
> 	__u8		min_enc_key_size;
> 	__u8		max_enc_key_size;
> +	__u8		le_l2cap_min_key_size;
> 	__u8		pairing_opts;
> 	__u8		ssp_debug_mode;
> 	__u8		hw_error_code;
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index b0d9c36acc03..9ef4b39b380c 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -3788,6 +3788,7 @@ struct hci_dev *hci_alloc_dev(void)
> 	hdev->conn_info_max_age = DEFAULT_CONN_INFO_MAX_AGE;
> 	hdev->auth_payload_timeout = DEFAULT_AUTH_PAYLOAD_TIMEOUT;
> 	hdev->min_enc_key_size = HCI_MIN_ENC_KEY_SIZE;
> +	hdev->le_l2cap_min_key_size = HCI_MIN_ENC_KEY_SIZE;

so I am not a fan of doing this with another variable and managing through debugfs. Can we pass the qualification test case by using BT_SECURITY_FIPS (which will enforce 128-bit key size)?

If not then we might want to add a socket option to set min/max encryption key size requirement on a per socket basis.

Regards

Marcel




[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