Bluetooth & BLE · Study deck

BLE Encryption: Key Management

Bluetooth encryption scrambles data so only a device 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.
iotclass.org

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
iotclass.org

Major section

In 60 Seconds

BLE encryption uses AES-CCM with 128-bit keys, but security depends on how keys are generated during pairing.

  • 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.
  • IRK supports address privacy and CSRK supports data signing.
iotclass.org

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.
iotclass.org

Major section

BLE Encryption Architecture

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.
  • P-256 ECDH protects the pairing exchange against passive eavesdropping.
Source: University of Edinburgh IoT Security Course
Source: University of Edinburgh IoT Security Course
iotclass.org

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.

Why it matters

The hierarchy prevents the misleading assumption that every key performs the same security job.

BLE key distribution comparing LE Legacy Pairing and LE Secure Connections routes to a long-term key
BLE key distribution comparing LE Legacy Pairing and LE Secure Connections routes to a long-term key
iotclass.org

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.
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.
iotclass.org

Major section

Security Decision Framework (continued)

User can verify 6-digit code.

  • Security: 1 million codes + user comparison (provides MITM protection when the numeric-comparison procedure is used correctly; pairing-method confusion can still expose it).
  • Device has NFC or can display QR code.
  • Security: Attacker must compromise both channels (Bluetooth + NFC/QR).
  • Displayless products still need an authenticated commissioning choice.
iotclass.org

Major section

Security Decision Framework (continued)

Passkey Entry: A 6-digit passkey gives about 20 bits of user-authenticated entropy when the passkey is random and protected from observation.

  • Method selection begins with the consequence of impersonation and the I/O that both endpoints can actually support.
  • Public, read-only broadcasts may accept an unauthenticated path; owner control, safety-relevant commands, or sensitive records need user-authenticated proof.
  • Security depends on that channel being hard for the attacker to observe or modify.
iotclass.org

Deck summary

Key takeaways

BLE encryption uses AES-CCM with 128-bit keys, but security depends on how keys are generated during pairing.

  • Encryption protects traffic only after the link has agreed on keys.
  • The comparison connects protocol choice to threat evidence: modern derivation protects against passive capture, while MITM resistance still depends on the authenticated association method.
  • 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.
iotclass.org

Retrieval practice

Recall check 1 of 3

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

Q1A BLE link is encrypted, yet pairing used an unauthenticated method. What remains at risk?

AAn active attacker can interfere during unauthenticated pairing.
BThe encrypted link's ciphertext becomes readable plain text.
CBonding cannot store any key when unauthenticated pairing is used.
DThe radio cannot reconnect after pairing without authentication.
Show answer

Answer: A Link encryption alone does not prove authenticated key exchange.

iotclass.org

Retrieval practice

Recall check 2 of 3

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

Q2A 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.

iotclass.org

Retrieval practice

Recall check 3 of 3

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

Q3In 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.

Q4A sensor keeps bond keys in readable app storage. What should change before release?

AUse protected storage for the keys retained after bonding.
BPublish bonded keys so maintenance staff can reconnect easily.
CKeep only device name and discard keys needed for a bond.
DDisable later pairing checks once first setup appears complete.
Show answer

Answer: A The bond keys should be held in a protected keystore or secure element.

iotclass.org

Print reference

Answers

Answer key.

  1. A · Link encryption alone does not prove authenticated key exchange.
  2. A · Bluetooth security review should separate pairing, encryption, key management, authorization, and recovery evidence.
  3. B · In legacy pairing, the Peripheral distributes the LTK together with its EDIV and Rand.
  4. A · The bond keys should be held in a protected keystore or secure element.
iotclass.org