Hi Ying,
On Tue, Sep 5, 2023 at 8:48 PM Ying Hsu <yinghsu@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> ---
> 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
