SM Part 2 — Security Properties & Crypto Functions
Chapter 11 Part 2 of 5 — Four Security Levels · Security Function e · AES-CMAC · f4 f5 f6 g2 h6 Explained
11.6 — Security Properties
Four Levels — From Maximum to None
The Security Manager produces one of four security levels for a connection. Higher levels require more capable hardware on both devices (display, keyboard, or an OOB channel). The level is determined during Phase 1 of pairing based on what both devices negotiate.
11.6.1 — LE Secure Connections Pairing BLE 4.2
The strongest security level. Uses P-256 elliptic curve Diffie-Hellman (ECDH) key exchange. The long-term key (LTK) is derived from the DH shared secret — a 128-bit key that neither side ever transmits over the air. Even if an attacker captured every single byte of the pairing exchange, they cannot compute the LTK without solving the discrete logarithm problem on P-256, which is computationally infeasible.
Crucially, this method provides forward secrecy — if an attacker somehow obtained the LTK used for one connection, they still cannot decrypt any past or future sessions because each session uses fresh ECDH values.
11.6.2 — Authenticated MITM Protection
Defends against Man-in-the-Middle attacks. Available in both LE legacy pairing (via Passkey Entry or OOB) and LE secure connections (via Numeric Comparison, Passkey Entry, or OOB).
11.6.3 — Unauthenticated No MITM Protection
Achieved via Just Works. No passkey or confirmation value is shown to the user — pairing happens silently. The link is still encrypted after pairing, so passive observers cannot read the data. However, a MITM attacker present during pairing could intercept and relay the exchange, since there is nothing for the user to verify. Better than no security, but not the top tier.
11.6.4 — No Security
No authentication and no encryption. Data travels in plaintext. Suitable only for devices broadcasting non-sensitive information where privacy is not a concern.
LE legacy pairing weakness: In LE legacy pairing (BLE 4.0 / 4.1), none of the pairing methods protect against a passive eavesdropper that is already listening when pairing starts. The temporary key values used at the start of legacy pairing are either 0 (Just Works), known (Passkey Entry — the user-visible number), or obtained via OOB. If the eavesdropper is present during pairing, they can derive the STK. If they were not present during pairing, the link is secure from them.
11.7 — Cryptographic Functions
Two Groups — One for Legacy, One for Secure Connections
The SM uses ten cryptographic functions in total. The first four support LE legacy pairing. The remaining six were introduced in BLE 4.2 for LE secure connections. Every function in both groups is ultimately built on two fundamental primitives: AES-128 (for legacy) and AES-CMAC (for secure connections).
11.7.1 — Security Function e — The AES-128 Core
The foundation of all LE legacy pairing crypto. Takes a 128-bit key and 128-bit plaintext, returns 128-bit ciphertext using AES-128.
Can be implemented in the host or the controller. If implemented in the controller, the host calls it via HCI_LE_Encrypt (OGF=0x08, OCF=0x0017). All three legacy functions below (ah, c1, s1) use e as their underlying primitive.
Generates the hash portion of a Resolvable Private Address. Input: IRK + a random 24-bit prand. Output: 24-bit hash. The full RPA is prand || hash. A peer device with the IRK can verify the address by recomputing the hash and comparing.
Generates the 128-bit Mconfirm and Sconfirm values exchanged during LE legacy pairing Phase 2. These values prove to each side that the other holds the correct Temporary Key without revealing it directly.
Derives the Short Term Key (STK) from the Temporary Key and the two random nonces (Mrand, Srand) that were exchanged in Phase 2. The STK is then used to encrypt the link at the end of Phase 2.
/* Using HCI_LE_Encrypt to call function e via BlueZ */
/* OGF=0x08, OCF=0x0017 */
/* Parameters: key (16 bytes) + plaintext (16 bytes) */
/* Returns: encrypted_data (16 bytes) in Command_Complete */
hcitool cmd 0x08 0x0017 \
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 \
AA BB CC DD EE FF 11 22 33 44 55 66 77 88 99 0011.7.5 — Security Function AES-CMAC
AES-CMAC (Cipher-based Message Authentication Code) is a much stronger algorithm than a simple checksum or CRC. A checksum or error-detecting code only catches accidental bit errors. AES-CMAC is designed to catch intentional, adversarial modifications — it is computationally infeasible for an attacker to modify a message and produce a valid MAC without knowing the key.
Defined by RFC-4493
FIPS (Federal Information Processing Standards)
128-bit symmetric key
128-bit Message Authentication Code
Like the security function e, AES-CMAC can run in either the host or the controller. If in the controller, the host uses HCI_LE_Encrypt to invoke it indirectly. This is the building block for all five BLE 4.2 secure connections functions: f4, f5, f6, g2, and h6.
11.7.6–11.7.10 — BLE 4.2 Secure Connections Functions
Five new functions built on AES-CMAC, each serving a specific role in the LE Secure Connections pairing procedure.
Generates the 128-bit confirm values that both devices exchange in Authentication Stage 1. Unlike legacy pairing’s c1 function, f4 uses the P-256 public keys and random nonces — making the confirm values unpredictable to an attacker who does not know the private keys.
The most important 4.2 function. Takes the Diffie-Hellman shared secret as input along with the random nonces and Bluetooth addresses of both devices. Runs AES-CMAC twice: first to derive an intermediate key T, then to derive both the LTK (128-bit) and MacKey (128-bit) from T. The LTK encrypts future connections. MacKey is used by f6 to verify the exchange.
Used in Authentication Stage 2 to verify that both devices completed Stage 1 correctly. Each device computes a check value using MacKey (from f5) plus parameters that depend on the pairing method used (Just Works, Numeric Comparison, OOB, or Passkey Entry). If the check value received does not match, the pairing is aborted immediately.
Used only when the Numeric Comparison pairing method is selected. Takes the two public keys and the two random nonces as input. The output is truncated to 6 decimal digits — this is the number that appears on both device screens. The user compares these digits visually. Since the computation uses the full P-256 keys and nonces, a MITM device cannot produce the same 6-digit output as the legitimate devices.
Converts keys between BR/EDR and LE formats. A dual-mode device that has bonded over BR/EDR can use h6 to convert the BR/EDR link key into an LE LTK — and vice versa. This allows a device bonded over classic Bluetooth to also use the same trust relationship for BLE connections without requiring a separate LE pairing session.
/* AES-CMAC is used internally by BlueZ SM layer */
/* External view: BlueZ calls HCI_LE_Encrypt for each block */
/* The SM layer in BlueZ (bluez/src/shared/crypto.c) provides: */
/* bt_crypto_aes_cmac() — AES-CMAC wrapper */
/* bt_crypto_f4() — SC confirm value generation */
/* bt_crypto_f5() — LTK + MacKey generation */
/* bt_crypto_f6() — check value generation */
/* bt_crypto_g2() — numeric comparison value */
/* bt_crypto_h6() — link key conversion */
/* These functions are called during the SMP pairing flow */
/* You generally don't call them directly — the SM handles it */
/* To verify AES-CMAC is available on the controller: */
/* hcitool cmd 0x08 0x0003 (LE Read Local Supported Features)*/
/* Bit 0 = LE Encryption (AES-128 available) */Chapter 11 Security Manager — 5-Part Series
Next — The Pairing Process: Phases 1 & 2
Part 3 covers the three-phase pairing process in detail — Feature Exchange (Phase 1) with IO Capability table, OOB flags, key sizes, and the exponential back-off for repeated attempts; then Phase 2 authentication for both LE legacy pairing and LE Secure Connections with the ECDH flow.