关于BLE传统配对中EDIV和Rand的使用及安全连接配对相关疑问

Great question—let’s unpack the details of BLE pairing keys and how they’ve evolved, since this is a common point of confusion when moving between legacy and secure connections.

1. EDIV & Rand in Legacy Pairing: Valid Implementation Options #

You’re exactly right about both approaches being allowed by the Bluetooth Core Specification—here’s a closer look at each:

• Using EDIV/Rand as an index to retrieve LTK
  This is the most widespread implementation. When a slave device completes legacy pairing, it generates a 16-bit Encryption Diversifier (EDIV) and 64-bit Random Number (Rand), then sends these along with the Long Term Key (LTK) to the master. The slave stores a mapping of (EDIV, Rand) → LTK in its non-volatile memory. Later, when the master initiates an encryption request, it sends the EDIV and Rand it stored; the slave looks up this pair to fetch the corresponding LTK and use it to establish the encrypted link. This method is simple, reliable, and ideal for devices with enough storage to keep track of paired LTKs.

• Deriving LTK from EDIV/Rand + a device-specific secret key
  The spec also permits this "derived" approach, though it’s less common. Here, the slave has a unique, device-specific root secret (e.g., a hard-coded key burned into hardware during manufacturing). Instead of storing LTKs, it uses EDIV, Rand, and this root secret as inputs to a cryptographic function (like AES) to regenerate the LTK on demand when an encryption request comes in. This is useful for devices with limited storage, but you have to protect the root secret fiercely—if it’s compromised, all paired LTKs can be derived.

So your understanding of both valid implementations is spot-on.

2. Why EDIV & Rand Were Removed in Secure Connections Pairing #

EDIV and Rand were phased out because Secure Connections (SC) was designed to address key weaknesses in legacy pairing:

• Limited entropy: EDIV is only 16 bits, and Rand is 64 bits—combined, they don’t provide enough randomness to resist brute-force attacks if an attacker gains access to stored pairing data.
• Redundant indexing: SC uses elliptic curve cryptography (ECC) to generate more secure LTKs, and it introduces a more robust way to associate keys with peer devices: identity addresses.

3. LTK Association in Secure Connections #

Yes, in Secure Connections, LTKs are tied to the peer’s Identity Address (either static or resolvable private). Here’s how it works:

• During pairing, devices exchange Identity Resolving Keys (IRK) along with LTKs.
• When a peer device broadcasts a resolvable private address, the local device uses the stored IRK to decrypt the address and reveal the underlying identity address.
• It then looks up the LTK associated with that identity address to initiate encryption.

For devices using static identity addresses, the process is even simpler—there’s no need for address resolution; the static address directly maps to the stored LTK.

内容的提问来源于stack exchange，提问作者picben