IOT - SECURITY

This phase is a structured conversation defined by the Bluetooth Core Specification. Its goal is to establish a shared secret and authenticate the devices.

Step 3.1: Pairing Feature Exchange

• What happens: The phone and watch exchange two pieces of data called the "IO Capabilities" and "Authentication Requirements".
  
  • IO Capabilities: What can each device do? (Display? Keyboard? Neither?)
  • Auth Reqs: Does the device require encryption? Is MITM protection required?
• Output & Dependency: Based on this exchange, both devices independently run the same algorithm to select the Pairing Method (Numeric Comparison, Just Works, etc.). This choice is critical because it determines the security strength of the entire process. This step depends on both devices supporting a common, secure method.

Step 3.2: Public Key Exchange

• What happens: This is the foundation of the key generation. Both devices have already generated their own public/private key pairs.
  
  • The watch sends its Public Key (PUK_w) to the phone.
  • The phone sends its Public Key (PUK_p) to the watch.
• Dependency: This step depends on both devices having a valid Elliptic Curve Cryptography (ECC) key pair. This is often done once at the factory.

Step 3.3: Diffie-Hellman Key Exchange (The "Magic")

• What happens: This is a purely mathematical, local computation on each device.
  
  • The phone calculates: DHKey = ECDH(PrivateKey_phone, PublicKey_watch)
  • The watch calculates: DHKey = ECDH(PrivateKey_watch, PublicKey_phone)
• The Result: Due to the mathematical properties of the Elliptic Curve, both calculations result in the exact same 256-bit number, called the DHKey. This is the Shared Secret. It is never transmitted over the air.
• Dependency: This step depends completely on the successful and authentic exchange of public keys in the previous step. If an attacker swaps the public keys, they can perform a MITM attack.

Step 3.4: Authentication (User Verification)

• What happens: The devices must now prove they both computed the same DHKey and that there is no MITM. They use the chosen method from Step 3.1.
  
  • For Numeric Comparison: A 6-digit code is derived from the DHKey and public keys. The user must confirm it matches on both devices. This step depends on the user to be the final authority against a MITM.
  • For Just Works: The authentication is skipped. It only guarantees protection against passive eavesdropping, not active attacks. The security depends entirely on the key exchange being secure.

The DHKey is a temporary secret. We now use it to create the permanent keys. This is done using a Key Derivation Function (KDF), which is like a cryptographic blender.

• Inputs: The KDF takes several inputs:
  
  1. DHKey: The shared secret from Phase 3.
  2. Pre-defined Constants: Values like "btlk" for the LTK.
  3. Nonces: Random numbers exchanged earlier.

• The Process: LongTerm Key = KDF(DHKey, "btlk", nonces, 128)
  
  • The KDF (often based on AES-CMAC) cryptographically "mixes" these inputs to generate a perfectly random, unique output key.
• Dependency: This step is completely dependent on the DHKey. If the DHKey is compromised, all derived keys are compromised. The exact same process is run on both the phone and the watch, ensuring they generate the same set of keys.

The Three Key Outputs:

1. LTK (Long-Term Key): KDF(DHKey, "btlk", ...). Used for link encryption.
2. CSRK (Connection Signature Resolving Key): KDF(DHKey, "btcs", ...). Used for data signing.
3. IRK (Identity Resolving Key): KDF(DHKey, "btid", ...). Used for privacy.

• What happens: The generated keys (LTK, CSRK, IRK) are not just stored in ordinary memory. They are written to non-volatile, secure storage.
  
  • On modern smartphones and watches, this is often a Hardware Security Module (HSM) or a Secure Element (SE). This is a dedicated chip designed to protect secrets from being extracted, even if the main operating system is compromised.
• Dependency: This phase depends on the successful generation of keys in Phase 4. It also depends on the hardware having a trusted execution environment to store them securely. The security of all future connections relies on this storage being tamper-proof.

Now, let's see how the LTK is used to encrypt every single data packet.

The Encryption Process (on the Sender - e.g., Watch):

1. Payload: The watch has data to send (e.g., heart rate = 72 bpm).
2. Nonce/IV: A packet counter is used to generate a unique number for each packet. This ensures that even if the same data is sent twice, the encrypted output is different.
3. Encryption & Signing: The data and nonce are fed into the AES-CCM algorithm along with the LTK.
   
   • AES encrypts the payload (72 bpm -> #kF3&).
   • CCM calculates a Message Integrity Check (MIC) tag, a cryptographic signature that protects the data and the header from being altered.

1. Transmit: The watch transmits the encrypted payload and the MIC tag.

The Decryption Process (on the Receiver - e.g., Phone):

1. Receive: The phone receives the packet.
2. Decryption & Verification: The phone feeds the encrypted data, the nonce, and the received MIC tag into the AES-CCM algorithm with its copy of the LTK.
   
   • The algorithm decrypts the payload (#kF3& -> 72 bpm).
   • It independently calculates what the MIC tag should be based on the received data.

1. Integrity Check: It compares the calculated MIC with the received MIC.
   
   • If they match: The data is authentic and intact. The heart rate value is passed to the phone's app.
   • If they don't match: The packet has been corrupted or tampered with. It is silently discarded.

Dependency: This entire process is utterly dependent on both devices having the exact same LTK stored in their secure storage from Phase 5. Without it, decryption and verification are impossible. It also depends on the AES-CCM algorithm being implemented correctly in both device's Bluetooth stacks.

The entire process forms a critical chain where each link depends on the last:

1. Phase 3 (Key Exchange) depends on authentic Public Key Exchange.
2. Phase 4 (Key Generation) depends entirely on the secret DHKey from Phase 3.
3. Phase 5 (Bonding) depends on the Keys generated in Phase 4.
4. Phase 6 (Encryption) depends on the secure storage and retrieval of the LTK from Phase 5.

If any step in this chain is broken (e.g., a weak pairing method, a flawed random number generator for keys, insecure key storage), the entire security of the connection collapses. This layered, dependent approach is what makes modern Bluetooth pairing both secure and robust.