linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Magdalena Kasenberg <magdalena.kasenberg@codecoup.pl>,
	Bluetooth Kernel Mailing List  <linux-bluetooth@vger.kernel.org>,
	Szymon Janc <szymon.janc@codecoup.pl>
Subject: Re: [PATCH] Bluetooth: Fix for L2CAP/LE/CFC/BV-15-C
Date: Sat, 27 Feb 2021 21:14:57 +0100	[thread overview]
Message-ID: <ECCE8B1E-C097-4FED-B11F-6294E22E6009@holtmann.org> (raw)
In-Reply-To: <CABBYNZ+3njOxCGKE0cvxkw574=U5Uv7+HHn885MrVFaoO3NpNQ@mail.gmail.com>

Hi Luiz,

>>> 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@codecoup.pl>
>>> Reviewed-by: Szymon Janc <szymon.janc@codecoup.pl>
>>> Cc: Szymon Janc <szymon.janc@codecoup.pl>
>>> ---
>>> 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)?
> 
> I guess that will depend if PTS supports MITM which afaik it is
> required with BT_SECURITY_FIPS, from the logs it looks like it doesn't
> support it so we end up with an unauthenticated key so the error would
> probably be different.

we should give this a try ..

> 
>> If not then we might want to add a socket option to set min/max encryption key size requirement on a per socket basis.
> 
> Yep, it seems to be a common trend to have such tests on upper layers
> (ATT/GATT also have such encryption key size), even though it is more
> of a GAP test and perhaps could have been done at SMP level.

.. however maybe we just deprecate BT_SECURITY or migrate it into something that allows specifying the details of a security level with extra parameters. I made the BT_SECURITY implementation in the kernel extendable. So we could also just add extra possible settings.

Regards

Marcel


  reply	other threads:[~2021-02-27 20:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 10:30 [PATCH] Bluetooth: Fix for L2CAP/LE/CFC/BV-15-C Magdalena Kasenberg
2021-02-22 11:06 ` bluez.test.bot
2021-02-22 17:46 ` [PATCH] " Luiz Augusto von Dentz
2021-02-26 20:17 ` Marcel Holtmann
2021-02-26 21:42   ` Luiz Augusto von Dentz
2021-02-27 20:14     ` Marcel Holtmann [this message]
2021-03-09 10:27       ` Szymon Janc
2021-03-09 18:35         ` Luiz Augusto von Dentz
2021-03-10  6:55           ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ECCE8B1E-C097-4FED-B11F-6294E22E6009@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=magdalena.kasenberg@codecoup.pl \
    --cc=szymon.janc@codecoup.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).