LTK

What Is the LTK?

The Long Term Key (LTK) is a 128-bit AES encryption key that two BLE devices store after bonding. It is the permanent secret that enables instant link encryption on reconnection, bypassing the full pairing procedure. Every encrypted BLE session between bonded devices is ultimately secured by the LTK.

LTK in Legacy vs. LESC Pairing

The way the LTK is generated differs between Legacy Pairing and LE Secure Connections (LESC):

• pairing/" class="glossary-term-link" data-term="Legacy Pairing" data-definition="Original BLE pairing (pre-4.2), now deprecated." data-category="Security">Legacy Pairing: the LTK is a random 128-bit value generated by the peripheral and distributed to the central during Phase 3 of pairing, along with EDIV (Encrypted Diversifier) and Rand (Random Number). These two companion values help the peripheral locate the correct LTK when multiple bonds exist. The central sends EDIV and Rand in the LE Start Encryption request.
• LESC: both devices independently derive the same LTK from the ECDH shared secret (DHKey) using a key derivation function. No EDIV or Rand is needed because the derivation is deterministic given the DHKey and nonces. Both devices end up with an identical LTK without it ever being transmitted over the air.

Reconnection with the LTK

When a bonded central reconnects to a bonded peripheral:

1. The central resolves the peripheral's RPA using the stored IRK to confirm identity.
2. The central sends LE Start Encryption with the stored EDIV and Rand (Legacy) or zeros (LESC).
3. The peripheral looks up the corresponding LTK in its bond database.
4. Both devices derive the session key from the LTK and begin encrypted communication.

This process completes within a single connection event, adding negligible latency compared to an unencrypted connection.

Key Hierarchy

The LTK sits at the top of the BLE key hierarchy. From it, the Link Layer derives a Session Key (SK) using AES-CCM for each connection. The SK is unique per session (derived with a per-session initialization vector), so compromising one session's SK does not expose the LTK or other sessions. However, compromising the LTK itself allows decryption of all past and future sessions that used it.

Storage and Security

The LTK must be stored in non-volatile memory (flash, EEPROM). On embedded SoCs, it is typically stored in a dedicated flash page managed by the BLE stack's bond manager. Best practices include:

• Encrypting the bond storage page with a device-unique key if the SoC supports it.
• Implementing secure erase on factory reset.
• Limiting the number of stored bonds to prevent exhaustion attacks.
• Never logging or transmitting the LTK in diagnostic output.

Key Rotation

The BLE specification does not mandate LTK rotation. Once bonded, devices use the same LTK indefinitely unless they explicitly re-pair. Some security-sensitive applications (medical devices, payment terminals) implement periodic re-pairing policies to limit the window of exposure if an LTK is compromised. This requires application-layer coordination because the BLE stack does not automate key rotation.