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




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

Hi,

On Tue, Jan 13, 2026 at 2:46 AM Neeraj Sanjay Kale
<neeraj.sanjaykale@nxp.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

Hi,

On Tue, Jan 13, 2026 at 10:00 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi,
>
> On Tue, Jan 13, 2026 at 2:46 AM Neeraj Sanjay Kale
> <neeraj.sanjaykale@nxp.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