Message-ID: <CABBYNZ+crY9eDfy6=cz8FwbUqFbjWjqjiVTHanw2J-7QB-Wh_g@mail.gmail.com>
Date: Tue, 13 Jan 2026 10:00:11 -0500
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Neeraj Sanjay Kale <neeraj.sanjaykale@....com>
Cc: marcel@...tmann.org, amitkumar.karwar@....com, sherry.sun@....com, 
	dmitrii.lebed@....com, linux-bluetooth@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v2 00/11] Bluetooth: btnxpuart: Add secure
 interface support for NXP chipsets

Hi,

On Tue, Jan 13, 2026 at 2:46 AM Neeraj Sanjay Kale
<neeraj.sanjaykale@....com> wrote:
>
> This patch series adds secure interface support for NXP Bluetooth chipsets
> to protect against UART-based attacks on Bluetooth security keys.
>
> Problem Statement:
> ==================
> Bluetooth UART drivers are vulnerable to physical attacks where adversaries
> can monitor UART TX/RX lines to extract sensitive cryptographic material.
> As demonstrated in research [1], attackers can capture H4 packets
> containing Link Keys, LTKs, and other pairing data transmitted in plaintext
> over UART.
>
> Once an attacker obtains these keys from UART traffic, they can:
> - Decrypt all Bluetooth communication for paired devices
> - Impersonate trusted devices
> - Perform man-in-the-middle attacks
>
> This vulnerability affects any Bluetooth implementation using UART
> transport, making physical access to UART lines equivalent to compromising
> all paired device security.
>
> Solution:
> =========
> Implement a TLS 1.3-inspired secure interface that:
> - Authenticates the chipset using ECDSA signature verification
> - Establishes shared encryption keys via ECDH key exchange
> - Encrypts sensitive HCI commands (Link Key Reply, LTK Reply, etc.) using
>   AES-GCM
> - Decrypts encrypted vendor events from the chipset
>
> This ensures that even with full UART access, attackers cannot extract
> usable cryptographic keys from the communication channel.
>
> Implementation Overview:
> ========================
> The solution is implemented in 11 incremental patches:
>
> 1-2:   Add firmware metadata parsing and version detection
> 3-4:   Establish secure interface framework and crypto setup
> 5-7:   Implement TLS handshake (Host Hello, Device Hello, authentication)
> 8:     Derive application traffic keys for encryption/decryption
> 9-10:  Add command encryption and event decryption support
> 11:    Add required crypto algorithm dependencies
>
> The implementation automatically detects secure interface capability via
> firmware version strings and enables encryption only when needed. Legacy
> chipsets continue to work without modification.
>
> Security Properties:
> ===================
> - Chipset authentication prevents rogue device substitution
> - Forward secrecy through ephemeral ECDH key exchange
> - Authenticated encryption (AES-GCM) prevents tampering
> - Per-session keys limit exposure from key compromise
>
> Testing:
> ========
> Tested on AW693 chipsets with secure firmware. Verified that:
> - Authentication handshake completes successfully
> - Sensitive commands are encrypted before transmission
> - Encrypted events are properly decrypted
> - UART monitoring shows only encrypted payloads for sensitive operations
> - Legacy chipsets remain unaffected
>
> [1] "BLAP: Bluetooth Low Energy Attacks on Pairing" - DSN 2022
>     https://netsec.ethz.ch/publications/papers/dsn22_blap.pdf

Ok, I start reading the document above but it says the problem is with
HCI itself though:

'We first present a link key extraction attack that exploits
the security flaw in the HCI dump, which records all data
passed through the HCI interface in a log file, including
link keys.'

It does say that it is passed to a log file though, maybe the
permission of the file is the problem then, either way this would be
UART expecific. We do require NET_ADMIN (aka. root) for accessing HCI
though, both for monitoring or generating HCI traffic (e.g.
HCI_USER_CHANNEL), so I don't believe these claims are valid with
respect to Linux since for collecting the logs with the likes of btmon
that will require root access, that said perhaps the -w option shall
limit the permission of the file to root only as well, in any case it
is not like btmon can be run by an attacker without root access, so it
beats me how Linux could be considered vulnerable here.

>
>
>
> Neeraj Sanjay Kale (11):
>   Bluetooth: btnxpuart: Add firmware metadata parsing for secure
>     interface
>   Bluetooth: btnxpuart: Print FW version and enable chip specific
>     features
>   Bluetooth: btnxpuart: Add secure interface TLS authentication support
>   Bluetooth: btnxpuart: Implement TLS authentication crypto framework
>   Bluetooth: btnxpuart: Add TLS host hello handshake implementation
>   Bluetooth: btnxpuart: Add TLS device hello processing
>   Bluetooth: btnxpuart: Add device authentication
>   Bluetooth: btnxpuart: Derive traffic keys from TLS 1.3 handshake
>   Bluetooth: btnxpuart: Add command encryption for sensitive HCI
>     commands
>   Bluetooth: btnxpuart: Add encrypted event handling
>   Bluetooth: btnxpuart: Select crypto algorithms for secure interface
>
>  drivers/bluetooth/Kconfig     |    7 +
>  drivers/bluetooth/btnxpuart.c | 1442 ++++++++++++++++++++++++++++++++-
>  2 files changed, 1440 insertions(+), 9 deletions(-)
>
> --
> 2.43.0
>


-- 
Luiz Augusto von Dentz

Powered by blists - more mailing lists