[PATCH] Bluetooth: Avoid redundant authentication

[PATCH] Bluetooth: Avoid redundant authentication

[Ying Hsu]

While executing the Android 13 CTS Verifier Secure Server test on a
ChromeOS device, it was observed that the Bluetooth host initiates
authentication for an RFCOMM connection after SSP completes.
When this happens, some Intel Bluetooth controllers, like AC9560, would
disconnect with "Connection Rejected due to Security Reasons (0x0e)".

Historically, BlueZ did not mandate this authentication while an
authenticated combination key was already in use for the connection.
This behavior was changed since commit 7b5a9241b780
("Bluetooth: Introduce requirements for security level 4").
So, this patch addresses the aforementioned disconnection issue by
restoring the previous behavior.

Signed-off-by: Ying Hsu <yinghsu@chromium.org>
---
Tested CTS Verifier 13 Secure Server test on a chromebook with AC9560.

 net/bluetooth/hci_conn.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 9d5057cef30a..27c0a3080631 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -2420,10 +2420,11 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
 		goto encrypt;
 
 	/* An authenticated combination key has sufficient security for
-	   security level 3. */
+	 * security level 3 or lower.
+	 */
 	if ((conn->key_type == HCI_LK_AUTH_COMBINATION_P192 ||
 	     conn->key_type == HCI_LK_AUTH_COMBINATION_P256) &&
-	    sec_level == BT_SECURITY_HIGH)
+	    sec_level <= BT_SECURITY_HIGH)
 		goto encrypt;
 
 	/* An unauthenticated combination key has sufficient security for
-- 
2.42.0.283.g2d96d420d3-goog

RE: Bluetooth: Avoid redundant authentication

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=781869

---Test result---

Test Summary:
CheckPatch                    PASS      0.63 seconds
GitLint                       PASS      0.25 seconds
SubjectPrefix                 PASS      0.07 seconds
BuildKernel                   PASS      39.68 seconds
CheckAllWarning               PASS      43.41 seconds
CheckSparse                   PASS      48.95 seconds
CheckSmatch                   PASS      133.42 seconds
BuildKernel32                 PASS      38.55 seconds
TestRunnerSetup               PASS      581.13 seconds
TestRunner_l2cap-tester       PASS      32.76 seconds
TestRunner_iso-tester         PASS      70.55 seconds
TestRunner_bnep-tester        PASS      13.60 seconds
TestRunner_mgmt-tester        PASS      246.02 seconds
TestRunner_rfcomm-tester      PASS      19.89 seconds
TestRunner_sco-tester         PASS      23.17 seconds
TestRunner_ioctl-tester       PASS      22.51 seconds
TestRunner_mesh-tester        PASS      16.90 seconds
TestRunner_smp-tester         PASS      17.71 seconds
TestRunner_userchan-tester    PASS      14.09 seconds
IncrementalBuild              PASS      35.72 seconds



---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: Avoid redundant authentication

[Luiz Augusto von Dentz]

Hi Ying,

On Tue, Sep 5, 2023 at 8:48 PM Ying Hsu <yinghsu@chromium.org> wrote:
>
> While executing the Android 13 CTS Verifier Secure Server test on a
> ChromeOS device, it was observed that the Bluetooth host initiates
> authentication for an RFCOMM connection after SSP completes.
> When this happens, some Intel Bluetooth controllers, like AC9560, would
> disconnect with "Connection Rejected due to Security Reasons (0x0e)".
>
> Historically, BlueZ did not mandate this authentication while an
> authenticated combination key was already in use for the connection.
> This behavior was changed since commit 7b5a9241b780
> ("Bluetooth: Introduce requirements for security level 4").
> So, this patch addresses the aforementioned disconnection issue by
> restoring the previous behavior.
>
> Signed-off-by: Ying Hsu <yinghsu@chromium.org>
> ---
> Tested CTS Verifier 13 Secure Server test on a chromebook with AC9560.
>
>  net/bluetooth/hci_conn.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 9d5057cef30a..27c0a3080631 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -2420,10 +2420,11 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type,
>                 goto encrypt;
>
>         /* An authenticated combination key has sufficient security for
> -          security level 3. */
> +        * security level 3 or lower.
> +        */
>         if ((conn->key_type == HCI_LK_AUTH_COMBINATION_P192 ||
>              conn->key_type == HCI_LK_AUTH_COMBINATION_P256) &&
> -           sec_level == BT_SECURITY_HIGH)
> +           sec_level <= BT_SECURITY_HIGH)
>                 goto encrypt;
>
>         /* An unauthenticated combination key has sufficient security for
> --
> 2.42.0.283.g2d96d420d3-goog

How about we do something like:

https://gist.github.com/Vudentz/be49a40789ec713f9441face9bd642cc

That way we cover similar situations for other security levels.

-- 
Luiz Augusto von Dentz