Is Bluetooth Low Energy encrypted?

Bluetooth Low Energy has encryption built into the link layer. The Core Specification says LE encryption uses AES-CCM and is performed in the controller, the part of the stack that runs the radio. NIST’s guide to Bluetooth security notes that AES-CCM provides confidentiality, integrity and authentication for the packets it covers.

The key comes from pairing. NIST describes pairing and bonding as creating shared secret keys and storing them for later connections, so a bonded pair can encrypt again without repeating the process. Until encryption starts, a connection is in the clear.

Encryption is a choice, not a default. NIST describes LE Security Mode 1 as having four levels:

• Level 1: no security, meaning no authentication and no encryption.
• Level 2: unauthenticated pairing with encryption.
• Level 3: authenticated pairing with encryption.
• Level 4: authenticated LE Secure Connections pairing with encryption, added in Bluetooth 4.2.

A separate Security Mode 2 uses data signing, which protects integrity but not confidentiality. NIST considers Mode 1 Level 4 the most secure of these and strongly recommends it, and says Level 1 should never be used.

How pairing works decides whether the encryption key can be stolen. Bluetooth 4.0 and 4.1 used what is now called LE legacy pairing. The Core Specification notes that it does not use Elliptic Curve Diffie-Hellman, so its Just Works and Passkey Entry models provide no protection against passive eavesdropping. NIST goes further: except for out-of-band pairing with a 128-bit temporary key, legacy pairing should be considered broken, because an attacker who captures the pairing frames can work out the resulting long-term key.

LE Secure Connections, added in Bluetooth 4.2, fixes that with a key agreement based on the P-256 elliptic curve and AES-CMAC. Each device derives the long-term key itself, so it is never sent over the air. The association model then decides protection against an active attacker. NIST notes that all the models except Just Works produce authenticated keys. Just Works asks the user to accept without comparing values, so it gives no protection against a person in the middle during pairing.

Devices that must refuse anything weaker can use Secure Connections Only mode, which NIST notes is not backwards compatible with Bluetooth 4.0 or 4.1 devices.

Even on a well-encrypted connection, some things are readable by design.

• Advertising. Advertising packets are broadcast so any scanner can find a device. The Core Specification’s optional Encrypted Advertising Data feature exists because ordinary advertising data can be read and used to fingerprint devices; it only works between devices that share a key in advance.
• Device addresses. A fixed address lets a device be tracked. The LE privacy feature replaces it with a private address that changes regularly and that only trusted devices holding the identity resolving key can link back. Apple’s accessory guidelines say Apple devices use random addresses for privacy reasons.
• Metadata. Encryption hides content, not the fact that two devices are talking, when, or how much. Does encryption hide metadata? goes into this.

BLE encryption protects one hop: the link between two radios. NIST is explicit that Bluetooth security covers individual links, that data is decrypted at intermediate points, and that end-to-end security needs higher-layer protection on top.

That matters whenever data travels further than one link. A message relayed across several phones in a mesh is decrypted and re-encrypted at each hop if only link encryption is used, so every relay can read it. A gateway that forwards BLE data to a server sees it in the clear. And on a single link, an app that never pairs gets no BLE encryption at all.

Apps that need privacy therefore encrypt the content themselves, with keys that only the intended recipients hold. That is end-to-end encryption, and protocols such as MLS do it for groups. Is Bluetooth’s own encryption enough for private messages? compares the two in detail.

Platform APIs let a GATT server set encryption permissions on specific data. In Core Bluetooth, CBAttributePermissions.readEncryptionRequired means only trusted devices can read a characteristic’s value. On Android, BluetoothGattCharacteristic offers PERMISSION_READ_ENCRYPTED for encrypted reads and PERMISSION_READ_ENCRYPTED_MITM for reads with person-in-the-middle protection, with matching write permissions.

Apple’s accessory guidelines describe how this triggers pairing: an accessory should not ask to pair up front, but reject an ATT request with an Insufficient Authentication error, after which the Apple device may start the security procedure. Pairing may need the user’s approval, and it creates keys for one pair of devices at a time. Apps that connect many phones to each other often cannot build on that step, which is another reason to encrypt content at the application layer.