Message-ID:
 <AS4PR04MB9692855E531E082BC431FD02E78FA@AS4PR04MB9692.eurprd04.prod.outlook.com>
Date: Wed, 14 Jan 2026 09:10:06 +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,

Thank you for taking a look at this patch series.

> 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%2Fnets
> >
> ec.ethz.ch%2Fpublications%2Fpapers%2Fdsn22_blap.pdf&data=05%7C02%7
> Cnee
> >
> raj.sanjaykale%40nxp.com%7C7e6471862d5d4d6b86bc08de52b47c29%7C686
> ea1d3
> >
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639039132284844210%7CUnknow
> n%7CTWFp
> >
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIk
> >
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=HV0OjNPoq%2B
> P%2B07YW
> > WCtrrGUlmxWBamNWMwfrbkan7yc%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.
The DSN’22 BLAP paper shows link‑key extraction from HCI dump logs (e.g., btmon)—a logging issue, not a Linux privilege bypass. Our threat model is different: physical sniffing of the H4 UART lines (common on M.2 Key‑E and bring‑up boards) where the link‑key exchange transits in plaintext. This series addresses that risk by encrypting the link‑key request/response (and related vendor events) over UART, so keys aren’t recoverable even with full wire access.

This is intended to help meet EU RED 2022/30 privacy/network‑protection essentials (Art. 3(3)(e),(d)) via “communicate securely” controls (ETSI EN 303 645) and aligns with the CRA Annex I requirement to protect confidentiality of transmitted data.

With the changes in this patch series (auth handshake + AEAD protection for sensitive HCI commands/events on UART), the AW693x/AW692x/IW693x/IW623x chips are SESIP3‑certified with Physical Attacker Resistance, TrustCB ID SESIP‑2500101‑01 (DEKRA; issued 2025‑12‑17, valid until 2027‑12‑16).

The certificate is available at: https://trustcb.com/iot/sesip/sesip-certificates/ with Cert. ID: SESIP-2500101-01

Please let me know if you have any further concerns.

Thanks,
Neeraj

Powered by blists - more mailing lists