top of page

BLUETOOTH
SECURITY ARCHITECTURE

Bluetooth used exclusively for secure firmware updates

 

Cuvex includes a Bluetooth module, but its use is strictly limited by design.

​

Bluetooth is only enabled inside the bootloader, and exclusively for the firmware update process.
It is never available during normal device operation, encryption, decryption, or transaction signing.

Once the device boots into its operational firmware (AppCode), Bluetooth is completely disabled at both software and functional level.

 

Secure hardware selection

​

The Bluetooth subsystem is based on the STM32WB5MMG from STMicroelectronics, selected specifically for its integrated security capabilities.

This secure component includes, among others:

​

  • Hardware-based key management and secure key storage

  • Public Key Accelerator (PKA)

  • AES-256 hardware encryption

  • True Random Number Generator (TRNG)

  • PCROP memory protection

  • Unique 96-bit device identifier

​

These features ensure that even the firmware update channel itself is built on a hardened cryptographic foundation.

 

Enforced operational isolation

​

Operational safeguards are implemented at the device level:

​

  • Before any cryptographic or signing operation starts, the device verifies that the Bluetooth module is powered off

  • If Bluetooth is detected as active, the operation is automatically aborted

  • This guarantees that Bluetooth can never coexist with sensitive processes

​

In addition, Bluetooth activity is physically observable by the user:

​

  • A dedicated blue LED, integrated directly into the Bluetooth module, lights up whenever the module is powered

  • This LED cannot be controlled by software outside the Bluetooth subsystem, making false indications impossible

  • Users always have direct visual confirmation of Bluetooth status

 

Secure pairing and communication protocol

​

When Bluetooth is enabled for firmware updates, Cuvex enforces a hardened pairing model:

​

  • Only Bluetooth Low Energy Secure Connections are allowed

  • Legacy pairing modes are explicitly rejected

  • The insecure “Just Works” pairing method is disabled

​

Instead, pairing requires:

​

  • MITM protection

  • An entropic PIN

  • Automatic deletion of all exchanged keys once the update process is completed

​

 

This prevents long-term trust relationships or residual credentials.

 

Physical proximity enforcement

​

Bluetooth transmission power is deliberately limited:

​

  • Effective range is less than one meter

  • This mitigates any attempt at remote interaction or unintended discovery

​

Firmware updates therefore require intentional physical proximity to the device.

 

Firmware integrity and update security

​

All firmware updates are subject to cryptographic signature verification:

​

  • The bootloader verifies the RSA signature of the firmware before installation

  • Unsigned or altered firmware is rejected

  • Downgrade or tampered firmware cannot be installed

​

Although the Bluetooth module supports additional secure firmware installation features at hardware level, these are disabled by default, further reducing the attack surface.

 

Security model summary

​

Bluetooth on Cuvex:

​

  • Is not part of the operational attack surface

  • Is never available during cryptographic operations

  • Exists solely as a temporary, tightly controlled update channel

  • Is protected by hardware security, cryptographic verification, and physical user visibility

​

This design allows secure firmware updates without compromising the offline and sovereign security model of Cuvex.

bottom of page