Message-ID:
 <AS4PR04MB9692C3DAFE45C6C3A73A09DBE78DA@AS4PR04MB9692.eurprd04.prod.outlook.com>
Date: Fri, 16 Jan 2026 09:49:23 +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: [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%2F&data=05%7C02%7Cneeraj.sanjaykale%40nxp.com%7C390bb750d15
> > > > >
> a4644c34308de537b8b5c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0
> > > > > %7C639039987267659582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0
> eU1hcGkiOn
> > > > >
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> > > > >
> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=rO%2FfOGzdeKteEkh796TfRlQ%2FdU
> oDgS
> > > > > INTP2K6qIBNY0%3D&reserved=0
> > > > >
> > >
> 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.
> 
> Alright, but you shouldn't have mentioned BLAP, what you describing is
> physical sniffing/wire tapping, BLAP is about accessing the HCI logs which
> doesn't really apply to the former, so instead of using BLAP as example would
> simply just mentioned the EU/ETSI requirements and SESIP certification.


I will surely change the content of the cover letter in v3 patch series.

Thanks,
Neeraj

Powered by blists - more mailing lists