Overview - Bluetooth Security Features

Bluetooth Security: From Legacy Foundations to Modern Implementations

Introduction

Bluetooth is one of the most widely deployed wireless protocols in the world, found in consumer wearables, medical devices, industrial sensors, and infrastructure equipment. Security in Bluetooth operates at two distinct levels: the protocol security architecture defined by the Bluetooth Special Interest Group (SIG) — covering encryption, pairing, and key management — and the silicon-level security that semiconductor vendors implement in hardware, extending protocol compliance with hardware Root of Trust, protected key storage, tamper detection, and verified firmware update.

This white paper covers both layers, with a focus on Bluetooth 4.2 through 6.0 and the silicon families — Nordic Semiconductor, Silicon Labs, and Infineon — that power Ezurio’s Bluetooth module portfolio. A feature matrix provides a direct comparison across all current modules.

Learn more about Bluetooth Security Features on Ezurio products.

1. A Brief History of Bluetooth Security

Bluetooth security has evolved significantly since early BR/EDR and initial Bluetooth Low Energy (BLE) releases. Early mechanisms established encrypted communication and basic authentication but were designed for constrained devices and threat models that differ substantially from those found in modern industrial, medical, and IoT applications.

Legacy security constructs such as:

• Fixed or short PIN‑based pairing
• Pre‑LE Secure Connections key exchange
• Non‑ECC (Elliptic Curve Cryptography) authentication methods

remain part of the Bluetooth specification only to support backward compatibility with legacy devices.

These mechanisms are not recommended for new designs and are outside the primary focus of this document.

This document focuses on currently supported, non‑deprecated security mechanisms defined in modern Bluetooth specifications, up to and including Bluetooth v6.0.

Part 1 — Bluetooth SIG Security: Bluetooth v4.2 -6.0

The Bluetooth SIG defines security within the core specification for each of its major protocol variants. Security mechanisms have evolved significantly across versions, and understanding which variant you are using — and which version of the spec it targets — is essential for evaluating the actual security posture of a design.

Modern Bluetooth security is defined primarily in Bluetooth Core Specification v4.2 and later, with incremental improvements through Bluetooth 5.x and Bluetooth 6.0. These capabilities form the baseline security layer common to modern Bluetooth products.

Bluetooth Core Specification v4.2

Classic Bluetooth, formally Basic Rate / Enhanced Data Rate (BR/EDR), was the original Bluetooth specification and is used in applications requiring sustained throughput: audio streaming, serial cable replacement, and hands-free profiles.

• Secure Connections: Secure Connections was introduced in Bluetooth 4.1 for BR/EDR and is the mandatory security mode for current BR/EDR designs requiring the highest security assurance. It extends Secure Simple Pairing with AES‑CCM encryption (replacing the earlier proprietary cipher) and FIPS‑compliant key derivation.

  
  In Bluetooth 4.2, LE Secure Connections was introduced and mandated for Bluetooth Low Energy (LE) for devices targeting high‑assurance applications.

Security modes defined by BR/EDR

The BR/EDR specification defines four security modes. Each mode governs when a device initiates security procedures, not whether it is capable of supporting them.

• Security Mode 1: No security enforced. The device will not initiate any security procedures. Acceptable only for non-sensitive applications or controlled environments.
• Security Mode 2(Service-Level Enforced): Security is applied per-service rather than at the link level. A device may allow unauthenticated access to some services while requiring authentication for others.
• Security Mode 3 (Link-Level Enforced – deprecated): Security is enforced at the link layer before any service access is permitted. Authentication and encryption are required for all services.

• Security Mode 4 (Service-Level Enforced — Secure Simple Pairing): Introduced with Bluetooth 2.1, this mode leverages SSP and is mandatory for Bluetooth 2.1+ certified devices. It defines further security tiers — minimum unauthenticated, authenticated, and highest security — for individual services.

BR/EDR authentication of a connection

Authentication in BR/EDR uses a challenge-response mechanism based on a shared link key. The verifier generates a 128-bit random challenge, and the claimant must compute the correct response using the SAFER+ algorithm (or, for Secure Connections, a FIPS-compliant HMAC-SHA256 derivation). Possession of the correct link key is proof of identity.

The encryption key is derived from the link key and is rotated each time a device enters encryption mode, limiting the exposure window if a session key is ever compromised.

Design note: Secure Connections mode is required to achieve the highest security assurance under BR/EDR. If your application uses Classic Bluetooth profiles (A2DP, HFP, SPP), confirm that both sides of the connection negotiate Secure Connections rather than falling back to legacy pairing.

Bluetooth Low Energy (BLE) Security

Bluetooth Low Energy was introduced in Bluetooth 4.0 (2010) and shares the same 2.4 GHz ISM band as Classic Bluetooth but uses an entirely separate protocol stack. Its security model is defined by the Security Manager (SM) specification and has been progressively strengthened through versions 4.0 to 6.0.

Encryption used by BLE

BLE uses AES-128 in CCM mode (AES-CCM) for both encryption and message authentication. AES-CCM is a NIST-approved authenticated encryption scheme that provides both data confidentiality and integrity verification in a single pass — if the message authentication check fails, the packet is discarded.

The 128-bit key length meets NIST recommendations for symmetric encryption through at least 2030. There is no provision in the standard for weaker key lengths in BLE.

BLE Legacy Pairing vs LE Secure Connections

These are the two pairing models defined in the BLE specification:

• Legacy Pairing (BLE 4.0 / 4.1): Uses a Temporary Key (TK) to derive a Short Term Key (STK), which is then used to encrypt the connection while Long Term Key (LTK) material is distributed. The TK is either zero (Just Works), a 6-digit PIN (Passkey Entry), or an OOB value. Because the TK can be short, Legacy Pairing is vulnerable to passive eavesdropping during the pairing exchange if the TK is observed.
• LE Secure Connections (introduced in BLE 4.2): Replaces the Legacy model's key distribution with Elliptic Curve Diffie-Hellman (ECDH) using the P-256 curve. The ECDH exchange means only one key is generated (the LTK) and it is never transmitted over the air — both devices derive it independently. This eliminates the passive eavesdropping vulnerability and provides forward secrecy properties.

Pairing association models supported by BLE support and how they affect security

The BLE Security Manager defines four association models. Each model offers different protection against MITM attacks, and the appropriate choice depends on the I/O capabilities of the devices involved.

• Just Works: No user interaction required. Provides encryption but no MITM protection. Appropriate only for scenarios where the physical environment provides sufficient assurance (e.g., a device is physically accessible only to authorized personnel during commissioning).
• Passkey Entry: One device displays a 6-digit code; the other enters it. Provides MITM protection proportional to the passkey length (~20 bits of security). Suitable for simple input peripherals such as sensors with a button interface.
• Numeric Comparison (LE Secure Connections only): Both devices display a 6-digit code and the user confirms they match. Provides strong MITM protection with a human-in-the-loop check. Well-suited for devices with a display.
• Out of Band (OOB): Key material is exchanged through a channel other than Bluetooth, such as NFC or a QR code. Provides strong MITM protection and is the most secure option when OOB infrastructure is available.

Bonding and how it is secured

Bonding is the process of persistently storing the security keys generated during pairing so that subsequent connections do not require a full re-pairing. The specification allows distribution of up to three key types during bonding:

• Long Term Key (LTK): Used to re-encrypt the connection on reconnection without a new pairing exchange.
• Identity Resolving Key (IRK): Used to resolve Resolvable Private Addresses (RPAs), enabling the host to recognize a bonded device even when it is advertising with a rotating, privacy-preserving address.
• Connection Signature Resolving Key (CSRK): Used to authenticate signed data at the ATT layer without requiring a full encrypted connection.

BLE protection of user privacy

The BLE specification includes a privacy mechanism based on Resolvable Private Addresses (RPAs). When privacy is enabled, a device generates a new random address at regular intervals (typically every 15 minutes by default, though this is configurable). The address is generated using the device's IRK and can only be resolved by bonded peers that hold the same IRK.

This prevents passive tracking of a device by its Bluetooth address — a concern particularly relevant for wearables and personal health devices. The LE Privacy 1.2 enhancement (BLE 4.2) moved address resolution into the link layer, reducing the latency and host overhead of the privacy mechanism.

BLE Security Modes and Levels

BLE defines two security modes, each with multiple levels. These are used by the Generic Attribute Profile (GATT) server to specify the minimum security required to access a characteristic or descriptor.

• Security Mode 1, Level 1: No security. Access is open to any device.
• Security Mode 1, Level 2: Encrypted link required; MITM protection not required (unauthenticated pairing acceptable).
• Security Mode 1, Level 3: Encrypted and authenticated link required (passkey, numeric comparison, or OOB pairing).
• Security Mode 1, Level 4: LE Secure Connections with authenticated pairing required. The highest level of Mode 1 security, available from BLE 4.2 onward.
• Security Mode 2, Level 1: Data signing using CSRK required; MITM protection not required.
• Security Mode 2, Level 2: Data signing with authenticated CSRK required.

Best practice: For any characteristic that exposes sensitive data or controls a physical actuator, require at minimum Security Mode 1 Level 3. Use Level 4 for designs targeting medical, industrial, or regulated markets.

Bluetooth 5.x Security Enhancements

Bluetooth 5.0 through 5.4 introduced incremental improvements to security alongside performance and range enhancements. The core AES-CCM encryption and LE Secure Connections model established in 4.2 carried forward, with the following additions.

Bluetooth 5.0

Bluetooth 5.0 (2016) focused primarily on range, speed, and advertising capacity improvements. From a security perspective, it retained and mandated the LE Secure Connections model introduced in 4.2. The extended advertising capabilities (larger payloads, secondary advertising channels) were designed to operate within the existing security framework without weakening it.

Encrypted Advertising Data (EAD)

Encrypted Advertising Data (EAD) is a security feature introduced in the Bluetooth 5.4 specification (released February 2023). Prior to EAD, advertising packets were transmitted in the clear — any device within range could read the advertising payload, which could contain sensitive information such as device identifiers, sensor readings, or configuration parameters.

EAD allows the advertising payload to be encrypted using a session key shared between the advertiser and authorized scanners during a prior BLE connection. The encrypted data can be received by any device, but only those holding the correct session key can decrypt and authenticate it.

EAD is particularly relevant for broadcast use cases — for example, a medical sensor broadcasting readings to authorized monitors, or an access control badge broadcasting to authorized readers — where a full connection and pairing exchange is not practical.

Note: Encrypted Advertising Data (EAD) is defined in the Bluetooth Core Specification v5.4. Interoperability requires that both the advertising device and the scanning device implement support for the EAD feature.

While EAD is introduced as part of Bluetooth 5.4, availability on a given module depends on the Bluetooth stack and SDK implementation rather than the Bluetooth version label alone. For example, Nordic Semiconductor documents EAD as a Bluetooth Host feature in Zephyr and indicates that EAD can be supported on earlier nRF52 SoCs (such as nRF52832) when using appropriate host‑stack support (Bluetooth Core Specification v5.4 Technical Overview; Nordic DevZone Q&A on Encrypted Advertising; Zephyr Encrypted Advertising sample).

Bluetooth 6.0 — Channel Sounding & Enhanced Security

Bluetooth 6.0 was adopted by the Bluetooth SIG in September 2024. Its headline feature is Channel Sounding (previously known as High Accuracy Distance Measurement, or HADM), which introduces phase-based ranging and round-trip timing to achieve centimeter-level distance measurement between devices. Alongside performance improvements, Bluetooth 6.0 includes explicit security provisions for the ranging feature.

Why does distance measurement need additional security in Bluetooth 6.0?

Distance measurement (ranging) is used in access control, asset tracking, and anti-theft applications where the physical proximity of a device is used as an implicit credential — for example, unlocking a car when a key fob is within one meter. This creates a specific attack vector: relay attacks and man-in-the-middle attacks designed to make a device appear closer than it actually is.

Channel Sounding in Bluetooth 6.0 is designed with these attacks in mind. It uses a combination of Phase-Based Ranging (PBR) and Round-Trip Timing (RTT) across multiple frequency channels to make it significantly harder for an attacker to manipulate the measured distance. The multi-channel approach requires an attacker to relay across all measured channels simultaneously, which is very difficult.

Does Bluetooth 6.0 change the underlying encryption model?

No. The AES-CCM encryption and LE Secure Connections model established in Bluetooth 4.2 remain the foundation. Bluetooth 6.0 adds Channel Sounding as a new physical layer capability and includes security-specific protections within the Channel Sounding protocol itself, but it does not replace or deprecate the existing security architecture.

Bluetooth 6.0 also introduces Decision-Based Advertising Filtering, which is primarily a power and performance feature, and Frame Space Updates which improve throughput — neither of which directly affects the security model.

Bluetooth Mesh Security

Bluetooth Mesh (first released 2017, substantially extended through subsequent revisions) enables many-to-many communication across large networks of BLE devices. It is widely used in smart building applications — lighting control, occupancy sensing, HVAC — and has a security model that is notably more prescriptive than basic BLE, as all security is mandatory and cannot be disabled. The specification does not permit unauthenticated or unencrypted mesh traffic. This is a deliberate design choice that distinguishes Mesh from point-to-point BLE, where security is configurable by the application.

Keys used by Bluetooth Mesh

The Mesh security architecture uses a layered key hierarchy with three distinct key types, each scoped to a different layer of the protocol:

• Network Key (NetKey): Shared by all nodes that belong to a given subnet. Used to encrypt and authenticate the network layer header, confirming that a message was sent by a member of the same network. A device may hold keys for multiple subnets simultaneously.
• Application Key (AppKey): Bound to a specific application domain (e.g., lighting control vs. HVAC) within a network. Used to encrypt the application-layer payload. Separating keys by application means a lighting controller cannot read HVAC sensor data even on the same physical network.
• Device Key (DevKey): Unique to each individual node. Used exclusively for provisioning and configuration messages (e.g., sending a new NetKey to a node). This ensures that configuration commands for one node cannot be replayed against another.

Bluetooth Mesh secure provisioning

Provisioning is the process of onboarding a new device to a mesh network. It is secured using Elliptic Curve Diffie-Hellman (ECDH) key agreement: the provisioner and the unprovisioned device each generate an ECDH keypair, exchange public keys, and derive a shared session key without the session key ever being transmitted over the air.

After the ECDH exchange, the provisioner sends the network credentials (NetKey, IV Index, unicast address) to the device encrypted under the session key. The device can then participate in the mesh network using its assigned credentials.

To protect against MITM attacks during provisioning, the specification supports several authentication methods including OOB public key exchange (where the device's public key is read via NFC or QR code rather than over the air) and an output OOB numeric authentication step.

Bluetooth Mesh Protection Against Replay Attacks

Bluetooth Mesh protects against replay attacks through two complementary mechanisms. Each message includes a Sequence Number (SEQ) that is incremented with each transmission. Receiving nodes maintain a cache of recently seen sequence numbers from each source and reject messages with sequence numbers that have already been processed.

Additionally, the IV Index — a 32-bit value maintained network-wide — provides a longer-term replay protection boundary. The Key Refresh procedure allows all NetKeys and AppKeys to be rotated across the network, providing forward secrecy after a key compromise event.

Part 2 — Vendor Silicon Security: How Ezurio's Partners Go Beyond the Specification

The Bluetooth SIG defines what security is required at the protocol level — encryption, authentication, key management. What the specification does not address is how those keys are generated, stored, and protected inside the device itself. This is where silicon vendors play a critical role, and where the difference between a module with basic protocol compliance and one with genuine end-to-end security assurance becomes clear.

Ezurio designs and manufactures Bluetooth modules based on silicon from Nordic Semiconductor, Infineon, and Silicon Labs. Each vendor takes a different approach to hardware-level security, and those differences have real implications for the security properties of the end product.

Nordic Semiconductor — nRF Series Security Architecture

Nordic Semiconductor’s nRF product family underpins many of Ezurio’s most widely deployed Bluetooth modules, including the BL5340, the BL65x series, and the latest BL54xxx platforms. Because Nordic security capabilities have evolved significantly across nRF generations, the specific SoC used in a module has a direct impact on the available silicon‑level security architecture.

Nordic’s nRF52 (BL654 module) Series Security Capabilities:

The nRF52 series (nRF52832, nRF52840, nRF52833) is based on the ARM Cortex-M4F core, which predates ARM TrustZone-M. As a result, nRF52 devices do not have hardware-enforced separation between secure and non-secure code execution environments.

Security capabilities on nRF52 include:

• AES-128 hardware accelerator: Provides fast, constant-time AES operations used by the BLE stack for link encryption and BLE Mesh.
• ARM CryptoCell-310 (nRF52840): A dedicated cryptographic engine supporting AES, SHA-256, HMAC, ECC, RSA, and True Random Number Generation (TRNG). CryptoCell offloads cryptographic operations from the main CPU and provides some protection against software-based side-channel attacks.
• APPROTECT (Access Port Protection): A hardware mechanism that can permanently or semi-permanently disable the SWD debug port, preventing readback of flash contents. Enables locking of production firmware against extraction.

• Software-based Secure Boot: The nRF52 series supports secure bootloader implementations (e.g., MCUboot in the nRF Connect SDK) that perform firmware signature verification before handing off to the application. Because there is no hardware TrustZone, the bootloader itself must be protected against tampering through APPROTECT.

Nordic nRF5340 (BL5340 module) security Capabilities:

The nRF5340 (used in Ezurio's BL5340 module) moves to the ARM Cortex-M33 architecture, which includes ARM TrustZone-M. This is a significant step up in hardware security architecture, enabling a hardware-enforced boundary between the Secure Processing Environment (SPE) and the Non-Secure Processing Environment (NSPE).

• ARM TrustZone-M: Provides hardware-enforced isolation between secure and non-secure code. The BLE stack, cryptographic operations, and key material can be run in the secure domain, inaccessible to application code running in the non-secure domain.

• CryptoCell-312: An upgraded cryptographic subsystem supporting a full suite of symmetric and asymmetric algorithms. Supports key ladder operations for more sophisticated key derivation.

  • Trusted Firmware‑M (TF‑M): Nordic’s nRF Connect SDK supports TF‑M on the nRF5340, providing a standardized Trusted Execution Environment (TEE) with secure services for key storage, cryptography, and execution isolation.
• Dual-core architecture: The nRF5340's dedicated network core runs the BLE radio stack, isolated from the application processor. This reduces the risk that an application-level vulnerability can directly compromise the BLE stack.

Nordic nRF54 Series (BL54Lxxx series modules) Security Capabilities

The nRF54L series represents Nordic's most advanced security architecture to date and is the silicon behind Ezurio's BL54L module series.

• CRACEN Security Subsystem: The Cryptographic Accelerator Engine (CRACEN) is Nordic's purpose-built cryptographic processor on the nRF54L15. It supports a comprehensive algorithm suite including AES, ChaCha20, SHA-2, SHA-3, HMAC, ECDH, ECDSA, and Ed25519, and is designed with side-channel leakage protection to resist power analysis and timing attacks.
• Key Management Unit (KMU): Provides dedicated key storage and a controlled interface to CRACEN. For symmetric keys, the raw key value is never exposed to the CPU — CRACEN operates directly on the key material inside the KMU. Public keys are transferred to secure-mode memory. Once stored in the KMU, keys can be used by the CPU for cryptographic operations without the CPU ever seeing the key value.
• ARM TrustZone-M with Hardware Root of Trust: The boot process begins in immutable ROM. A chain of trust is established at every stage: ROM validates the first-stage bootloader, which validates the second-stage bootloader, which validates the application firmware. Each stage is cryptographically signed and verified before the next stage is permitted to execute.
• Secure Boot with Attestation: The nRF54L series supports secure boot with remote attestation, allowing a server to verify the integrity and authenticity of the firmware running on a device. Attestation keys are provisioned into immutable OTP memory at manufacture.
• Tamper Detection: Hardware sensors monitor voltage, temperature, and electromagnetic parameters. On detecting a tamper event, the device can be configured to erase sensitive key material or halt execution.

BL54LM20 Series (Nordic nRF54LM20A SoCs) Security Capabilities

The BL54LM20 series modules are based on Nordic Semiconductor’s nRF54LM20A wireless System‑on‑Chips, respectively. Both SoCs are members of Nordic’s nRF54 family and are designed to support security‑sensitive applications requiring hardware‑enforced isolation between secure and non‑secure execution environments.

At the silicon level, these devices integrate Arm TrustZone®‑based isolation, secure boot and authenticated firmware mechanisms, cryptographic acceleration with side‑channel protections, dedicated key management hardware, and silicon‑level protections against physical attacks, including tamper and fault‑injection detection. These shared security primitives are exposed to the system through hardware and firmware mechanisms intended to support high‑assurance embedded designs.

Nordic‑based module selection guidance

For applications that store keys, certificates, or other sensitive assets and need silicon‑level protections against physical attacks (for example, tamper/fault‑injection countermeasures), choose an nRF54‑based Ezurio module such as BL54L15 (nRF54L15) or BL54LM20 (nRF54LM20).

Learn more about Bluetooth Security Features on Ezurio products.

Silicon Labs — Secure Vault Architecture

Silicon Labs’ Series 2 wireless SoCs form the foundation of Ezurio’s Lyra series Bluetooth module family, including the Lyra and Lyra 24 variants. These platforms implement different Secure Vault tiers, and the underlying device selection determines which hardware‑level security mechanisms are available to a given design.

Hardware Root of Trust

• Establishes a trust anchor anchored in immutable on‑chip memory.
• Forms the starting point of a verified boot chain before any customer firmware executes.
• Prevents execution of unauthorized or modified firmware at power‑on or reset.
• Serves as the foundation for higher‑level protections such as secure boot, secure update, and attestation‑style mechanisms.

Secure Boot

• Cryptographically verifies firmware authenticity before execution.
• Ensures only authorized firmware images are allowed to run on the device.
• Protects against persistent compromise through malicious or corrupted firmware.
• May be combined with software and hardware enforcement depending on configuration.

Cryptographic Engine (Secure Vault)

• Dedicated hardware accelerator supporting symmetric and asymmetric cryptography.
• Offloads cryptographic operations from the main CPU for both performance and security.
• Reduces exposure of sensitive key material to application code.
• Supports Bluetooth‑required cryptography as well as broader system‑level security functions.

Hardware‑Protected Key Storage

• Enables cryptographic keys to be generated and stored in protected hardware regions.
• Prevents direct software readout of private keys.
• Reduces the risk of key extraction through firmware vulnerabilities or memory inspection.
• Supports long‑term device identity and secure communication use cases.

True Random Number Generator (TRNG)

• Provides hardware‑generated entropy suitable for cryptographic operations.
• Supports secure key generation, nonces, and protocol randomness.
• Improves resistance to predictability and replay‑style attacks.
• Underpins secure Bluetooth pairing and higher‑level security services.

Debug Lock and Secure Debug Access

• Controls access to JTAG/SWD and other debug interfaces.
• Prevents unauthorized inspection or modification of device memory in production.
• Supports secure manufacturing and lifecycle management.
• Allows controlled re‑enablement of debug access when authorized.

Anti‑Rollback Protection

• Prevents downgrade to older, potentially vulnerable firmware versions.
• Enforces monotonic firmware update progression.
• Protects devices from rollback‑based attack techniques.
• Typically implemented using protected counters or secure state storage.

Secure Firmware Update (OTA Support)

• Supports cryptographic verification of firmware updates before installation.
• Ensures update authenticity and integrity.
• Prevents unauthorized firmware replacement during field updates.
• May be implemented fully in hardware or as a secure software‑assisted chain.

Secure Identity and Attestation Capabilities

• Supports establishment of device‑unique cryptographic identity.
• Enables cryptographic proof of device authenticity and firmware state.
• Can be used to support supply‑chain integrity verification and secure onboarding.
• Implementation depends on provisioning, configuration, and system‑level infrastructure.

Tamper Detection (Where Supported)

• Provides hardware monitoring for certain physical attack conditions.
• May detect abnormal voltage, temperature, or fault‑injection behavior.
• Intended to raise security events or trigger protective responses.
• Availability and response behavior depend on silicon capability and configuration.

Relationship to Bluetooth Specification Security

• These silicon‑level capabilities complement Bluetooth‑defined security mechanisms.
• Bluetooth specification security protects data in transit.
• Silicon‑level security protects the device itself, its firmware, and cryptographic material.
• Together they form a complete end‑to‑end security model for modern Bluetooth products.

Learn more about Bluetooth Security Features on Ezurio products.

Infineon CYW55310 Security Architecture

Infineon Technologies’ AIROC Bluetooth portfolio is represented in Ezurio’s lineup through the Vela module family as well as host‑controlled HCI modules used in operating‑system‑backed designs. These platforms span multiple silicon families and security architectures, making the underlying SoC and execution model key factors in the resulting security behavior.

The sections below describe the security capabilities of the Infineon CYW55310 silicon used by Ezurio’s Vela IF310, focusing on the hardware security capabilities provided by the device. The realized security behavior of a deployed system depends on the supported execution model and available software stack. At the time of writing, the Vela IF310 supports host‑controlled (HCI‑based) development, and the availability and enforcement of device‑centric security capabilities are contingent on ongoing BSP and SDK integration work with Infineon.

Infineon CYW55310 Security Capabilities Overview

The Infineon CYW55310 is an AIROC™ Bluetooth® System‑on‑Chip integrating an Arm® Cortex®‑M33 processor with hardware‑assisted security capabilities intended to support secure Bluetooth operation and protected firmware execution. The device employs Arm TrustZone‑M to establish a hardware‑enforced separation between secure and non‑secure execution environments, forming the foundation of its security architecture.

Memory sizes, clock speeds (up to 192 MHz), and available on‑chip resources are defined in the current Infineon CYW55310 datasheet and may vary between silicon revisions. Customers should verify these characteristics against the latest Infineon CYW55310 documentation prior to final design decisions.

• Hardware Root of Trust
  The CYW55310 includes immutable on‑chip ROM that anchors early boot behavior and is commonly used to establish a hardware root of trust. Specific boot‑flow enforcement is defined by Infineon firmware and platform architecture.

• Secure Boot and Firmware Integrity
  The silicon supports cryptographic authentication of firmware during boot, enabling rejection of unauthorized images. Secure update and anti‑rollback mechanisms are supported at the platform level and depend on software implementation.
• Hardware‑Enforced Isolation (TrustZone‑M)
  Arm TrustZone®‑M enables separation between secure and non‑secure execution environments, intended to allow protection of security‑critical services and assets from application code.
• Cryptographic Acceleration and Key Protection
  A dedicated hardware cryptographic subsystem (CryptoCell‑312) provides accelerated crypto operations and supports protection of key material from application‑accessible memory.
• Random Number Generation
  Hardware random number generation is available to support cryptographic operations. Infineon describes this functionality as aligned with the design principles of NIST SP 800‑90A and SP 800‑90B. Formal certification or validation is distinct from design intent and should not be inferred.
• Debug Access Control
  The platform supports restriction of debug access through secure mechanisms to prevent unauthorized inspection or modification of device state, subject to supported software architecture.
• Secure Firmware Updates (OTA)
  Cryptographic verification of firmware updates is supported to help protect against tampered or malicious updates, subject to platform software support.

Note: At the time of writing, Vela IF310 supports host‑controlled (HCI‑based) development. Availability and enforcement of device‑centric security capabilities depend on ongoing BSP and SDK integration with Infineon.

CYW20820 Context (Vela IF820)

The Vela IF820 series is based on the CYW20820, a dual‑mode Classic Bluetooth + BLE 5.2 SoC built on an ARM Cortex‑M4.

The items below describe security capabilities supported by the Infineon CYW20820 silicon when used in device‑centric (standalone) designs developed with Infineon’s ModusToolbox™ Bluetooth SDK. These capabilities are provided by the silicon and Infineon ROM firmware; overall security behavior depends on application design and configuration.

• Device‑Centric Bluetooth Execution
  The CYW20820 integrates an Arm® Cortex‑M4 MCU and a Bluetooth stack resident in on‑chip ROM, enabling standalone Bluetooth application development without an external host processor.
• Bluetooth Protocol Security
  The device supports Bluetooth LE Secure Connections, including ECDH‑based key agreement (P‑256), and AES‑CCM link‑layer encryption as defined by the Bluetooth Core Specification.
• Cryptographic Primitives
  The CYW20820 provides hardware support for AES‑128 and includes security functions in ROM for ECDSA signature verification, which are used by the Bluetooth stack and secure firmware mechanisms.
• Random Number Generation
  A hardware true random number generator (TRNG) is included for cryptographic operations such as pairing, nonce generation, and key material. This reflects silicon capability; no formal NIST or FIPS certification is implied.
• Secure Firmware Update (OTA)
  Secure Firmware Upgrade (SFU) is supported in ModusToolbox for CYW20820 devices, enabling cryptographically signed firmware images to be verified prior to installation.
• Key Handling Model
  Cryptographic keys and security state are managed by the Infineon Bluetooth stack and ROM‑resident security services. Key protection relies on the device architecture and firmware design rather than a separate hardware secure domain.
• Debug and Access Control
  Debug access and low‑level device control are constrained by device configuration and Infineon ROM firmware behavior. Overall exposure depends on deployment configuration and lifecycle management.
• Access Lockout Functionality
  The CYW20820 provides a hardware lockout mechanism that can be configured to restrict or disable certain debug and access paths in production devices. This feature is intended to prevent unauthorized modification or reprovisioning after deployment. Lockout functionality is irreversible once enabled and does not provide credential‑based secure debug re‑enablement.

The IF820 remains well‑suited for existing dual‑mode Classic + BLE designs. For new designs requiring TrustZone‑enforced isolation, CryptoCell‑312 cryptographic services, and Bluetooth 6.0 LE Audio capabilities, the Vela IF310 (CYW55310) represents Infineon’s current‑generation platform.

Infineon BT850 and BT860 — Host‑Controlled HCI Security Model

• Architecture
  BT850 (USB HCI) and BT860 (UART HCI) modules are based on Infineon’s CYW20704 family and operate within a host‑controlled Bluetooth architecture. The Bluetooth controller and radio reside on the module, while the Bluetooth stack executes on the host operating system or host MCU via a standard HCI interface.
• Security Model
  Security enforcement, key management, and access control are implemented by the host platform, not by the module. The module provides Bluetooth controller functionality but does not independently enforce system trust boundaries.

Learn more about Bluetooth Security Features on Ezurio products.

Additional Resources

The following Bluetooth SIG, standards, and vendor resources provide additional technical detail related to the topics covered in this document.

Note: Some vendor resources require free account registration to access full documentation.

• Bluetooth SIG Core Specification (current version): http://bluetooth.com/specifications
• Bluetooth SIG Security Overview: http://bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security
• Bluetooth SIG — Security & Vulnerability Reporting:
  https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/
• NIST Special Publication 800‑121 Rev. 2, Guide to Bluetooth Security, National Institute of Standards and Technology (NIST).
  https://doi.org/10.6028/NIST.SP.800-121r2
• Nordic Semiconductor Security Documentation: http://docs.nordicsemi.com Nordic Technical Documentation portal — security topics span many documents across devices and SDKs; use search (e.g., “Security”) to locate relevant material.
• Nordic nRF54L Series Security Capabilities: Nordic Developer Academy — nRF54L Series Express Course, (Lesson 4)
• Silicon Labs Secure Vault: http://silabs.com/security/secure-vault
• Silicon Labs AN1218 — Secure Boot with RTSL: silabs.com/documents/public/application-notes/an1218-secure-boot-with-rtsl.pdf
• Infineon CYW55310 AIROC Bluetooth 6.0 Audio MCU: infineon.com/part/CYW55310
• Ezurio Bluetooth Module Portfolio: http://ezurio.com/wireless-modules/bluetooth-modules

For technical questions, visit our support center at http://ezurio.com/support .