Message-ID:
 <AS4PR04MB9692112F8A4D81D905716131E78FA@AS4PR04MB9692.eurprd04.prod.outlook.com>
Date: Wed, 14 Jan 2026 09:19:31 +0000
From: Neeraj Sanjay Kale <neeraj.sanjaykale@....com>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
CC: "marcel@...tmann.org" <marcel@...tmann.org>, Amitkumar Karwar
	<amitkumar.karwar@....com>, Sherry Sun <sherry.sun@....com>, Dmitrii Lebed
	<dmitrii.lebed@....com>, "linux-bluetooth@...r.kernel.org"
	<linux-bluetooth@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Ethan Lo <ethan.lo@....com>
Subject: RE: [EXT] Re: [RESEND PATCH v2 00/11] Bluetooth: btnxpuart: Add
 secure interface support for NXP chipsets

Hi Luiz,

> > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fne
> > >
> tsec.ethz.ch%2Fpublications%2Fpapers%2Fdsn22_blap.pdf&data=05%7C02%
> 7
> > >
> Cneeraj.sanjaykale%40nxp.com%7C0e6161848dee43987e5a08de52cfc89c%7
> C68
> > >
> 6ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639039249553069390%7C
> Unknow
> > >
> n%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
> AiOiJX
> > >
> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=j%2
> FQoD6
> > > BOhlNZQxaq4%2FEgfZaZMKNqNTwc5wgjWV7lQNc%3D&reserved=0
> >
> > 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.

Agree — the BLAP attack’s Linux path requires superuser for USB/HCI logging, so we’re not claiming an unprivileged Linux issue. Our series targets a different, OS‑independent risk: "physical sniffing of plaintext link‑key exchanges" on H4 UART (common on M.2 Key‑E bring‑up paths), which an attacker can tap without host permissions — hence we encrypt those HCI messages. The use of stolen keys to decrypt on‑air traffic is described in the BLAP; we’re removing the key‑extraction vector from the UART bus.

Thanks,
Neeraj

Powered by blists - more mailing lists