Message-ID: <CABBYNZ+P6SUq4QAD9MS3MYw3yUDv6q8O5tDjR+wk8Zi9gmhAAQ@mail.gmail.com>
Date: Tue, 13 Jan 2026 13:15:37 -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 10:00 AM Luiz Augusto von Dentz
<luiz.dentz@...il.com> wrote:
>
> 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.

Just reading thru it says:

'Moreover, it is also straightforward to implement the
link key extraction attack in Linux OS by leveraging both USB
sniff and HCI dump log, because there are USB sniffing solu-
tions as well as the bluez-hcidump package. However, running
USB sniffing and bluez-hcidump, and accessing the bonding
information file in Linux require the superuser privilege. Thus,
the practicality of link key extraction in Linux depends on the
attacker’s affordable privilege.'

Anything is trivial if you have superuser privilege, so I don't think
we should consider Linux vulnerable just because someone thinks having
root access is something trivial to get, that in itself is the real
vulnerability if you ask me.

>
> >
> >
> >
> > 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



-- 
Luiz Augusto von Dentz

Powered by blists - more mailing lists