Bluetooth & BLE · Study deck

BLE Encryption: Key Management

Bluetooth encryption protects data by scrambling it so that only devices with the right key can read it.

Radio Remi is your guide for this deck.

securityencryptionkeys

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain BLE Encryption Architecture: Describe how AES-CCM-128 encryption and key generation methods work together in BLE
Analyze Key Hierarchy: Distinguish the roles of LTK, IRK, and CSRK in BLE security and justify when each is applied
Apply Security Decision Framework: Select appropriate security levels for different IoT application contexts
Implement Best Practices: Configure secure pairing and key storage for IoT deployments

Major section

In 60 Seconds

A home health device pairs with a nurse's tablet and sends private readings.

Strong encryption cannot rescue a key that was given to the wrong party or never removed.
The deeper sections explain the key hierarchy, privacy and signing roles, stored relationships, rotation, removal, and how the chosen pairing method changes the protection achieved.
BLE encryption uses AES-CCM with 128-bit keys, but security depends on how keys are generated during pairing.

Major section

BLE Key Management Pattern

Encryption protects traffic only after the link has agreed on keys.

Bonding stores long-term keys so devices can reconnect without repeating pairing.
IRK supports privacy by resolving rotating private addresses for bonded devices.
CSRK supports signed data on unencrypted links, but it does not replace encryption for sensitive traffic.

Major section

BLE Encryption Architecture

BLE supports multiple encryption architectures depending on pairing method and Bluetooth version.

The comparison connects protocol choice to threat evidence: modern derivation protects against passive capture, while MITM resistance still depends on the authenticated association method.
This provides basic protection but can be vulnerable if the temporary key has low entropy or the pairing exchange is captured.

Source: University of Edinburgh IoT Security Course

Major section

BLE Key Hierarchy

In an implementation record, map each role to its actual storage owner, creation event, allowed use, reset behavior, and deletion proof.

That prose-to-inventory connection is what prevents a technically correct key name from becoming an unmanaged credential.
TK (Temporary Key): Generated during pairing, depends on pairing method.

BLE Key Distribution Architecture: LE Legacy Pairing, LE Secure Connections, and BR/EDR Secure Pairing key derivation

Major section

Security Decision Framework

Device has no display, keyboard, or NFC.

Data is already encrypted at application layer.
Risk acceptance:: Anyone can read data (that's the intent).
Device has display OR keyboard (not both).
Both devices have displays.

Out-of-band pairing options for displayless BLE devices: NFC tap, QR scan, and button-press commissioning move setup proof outside the BLE radio channel before encrypted bonding.

Major section

Security Decision Framework (continued)

User can verify 6-digit code.

Device has NFC or can display QR code.
Security: Attacker must compromise both channels (Bluetooth + NFC/QR).
Method selection begins with the consequence of impersonation and the I/O that both endpoints can actually support.
Displayless products still need an authenticated commissioning choice.

Major section

Security Decision Framework (continued)

Security depends on that channel being hard for the attacker to observe or modify.

Public, read-only broadcasts may accept an unauthenticated path; owner control, safety-relevant commands, or sensitive records need user-authenticated proof.
A printed static value also has a different observation and reuse risk from a fresh displayed passkey, a two-display comparison, or a protected out-of-band channel.
OOB:: Security depends on the out-of-band channel and the secret you exchange.

Deck summary

Key takeaways

A home health device pairs with a nurse's tablet and sends private readings.

Encryption protects traffic only after the link has agreed on keys.
BLE supports multiple encryption architectures depending on pairing method and Bluetooth version.
In an implementation record, map each role to its actual storage owner, creation event, allowed use, reset behavior, and deletion proof.
Device has no display, keyboard, or NFC.

Retrieval practice

Recall check 1 of 2

Radio Remi says: answer from memory, then check your reasoning.

Q1A reviewer is checking the Bluetooth security decision for this topic. Which evidence keeps the claim bounded?

APairing method, I/O assumptions, key storage, encryption level, authorization boundary, recovery plan.

BA statement that Bluetooth is common in consumer devices, without checking this deployment

CA successful connection screenshot with no power, security, or failure-behavior evidence

DA decision to defer retest triggers until after deployment problems appear

Show answer

Answer: A Bluetooth security review should separate pairing, encryption, key management, authorization, and recovery evidence.

Retrieval practice

Recall check 2 of 2

Radio Remi says: answer from memory, then check your reasoning.

Q2In BLE legacy pairing, which two values are used by the Central to identify and retrieve the correct LTK during reconnection?

AIRK and CSRK

BEDIV and Rand

CDHKey and STK

DTK and Mrand

Show answer

Answer: B In legacy pairing, the Peripheral distributes the LTK together with its EDIV and Rand.

Print reference

Answers

Answer key.

A · Bluetooth security review should separate pairing, encryption, key management, authorization, and recovery evidence.
B · In legacy pairing, the Peripheral distributes the LTK together with its EDIV and Rand.