CTKD Cross-Transport Key Derivation in Bluetooth

Overview

In Bluetooth, CTKD (Cross-Transport Key Derivation) is a security mechanism defined in the Bluetooth Core Specification (introduced in version 4.2 and gradually improved). Its main purpose is to simplify the pairing process for dual-mode Bluetooth devices (which support both Classic Bluetooth BR/EDR and Low Energy Bluetooth BLE/LE), enhance user experience, and ensure security consistency.

Core Issue: Why is CTKD Needed?

Before the emergence of dual-mode devices (such as smartphones, Bluetooth-enabled computers, modern headphones/speakers):

1. 1. Devices needed to pair separately: Users had to perform a complete pairing process for the same physical device (like a headset) in both Classic Bluetooth mode and Low Energy Bluetooth mode.
2. 2. Poor user experience: Users might need to enter a PIN code twice (or perform two confirmation actions), which felt cumbersome and unnatural.
3. 3. Complex management: The device side needed to maintain two sets of independent link keys and secure connections.

CTKD was designed to solve this problem: it securely derives a connection key for another transport layer (BR/EDR or LE) through a single pairing process.

Core Ideas and Mechanism of CTKD

1. 1. “Master” Pairing and “Slave” Derivation:

• • Users only need to perform a complete, secure pairing process on one transport layer (referred to as the CTKD pairing transport layer). This pairing will generate a long-term key specific to that transport layer.
• • The CTKD mechanism will use the shared secret information generated during this pairing process (specifically the Long Term Key – LTK or Link Key) to securely derive a long-term key for another transport layer.
• • Once the derivation process is complete, the other transport layer is considered paired, and the user does not need to perform a complete pairing process again.

2. Key Derivation Direction:

• • LE Secure Connection Pairing Derives BR/EDR Key: When the user performs a pairing on the LE transport layer that meets the LE Secure Connection requirements (using Passkey Entry, Numeric Comparison, or OOB methods, satisfying MITM protection), CTKD can derive a Link Key for the BR/EDR transport layer.
• • BR/EDR Secure Simple Pairing Derives LE Key: When the user performs a pairing on the BR/EDR transport layer that meets the Secure Simple Pairing requirements (using Passkey Entry, Numeric Comparison, or OOB methods, satisfying MITM protection), CTKD can derive an LTK for the LE transport layer.
• • Note: Pairing using the Just Works method (whether LE or BR/EDR) cannot trigger CTKD, as it does not provide MITM protection and is insufficiently secure. The derivation direction depends on which transport layer performed the compliant “master” pairing.

3. Key Role:<span>Cross-transport Key</span>

• • The LTK (LE) or Link Key (BR/EDR) generated on the CTKD pairing transport layer is referred to as the <span>Cross-transport Key</span>.
• • This key is the foundational input for the derivation process. The derivation algorithm is defined by the Bluetooth specification, ensuring that the derived key has the same security strength as the key generated by direct pairing on the target transport layer.

4. Derivation Process (<span>Cross-transport Key Derivation</span> Function):

• • Uses <span>Cross-transport Key</span> and the addresses of both devices as inputs.
• • Calculated through a secure cryptographic function (usually based on HMAC-SHA-256 KDF).
• • The output is the long-term key for the target transport layer: if deriving BR/EDR from LE, the output is the Link Key; if deriving LE from BR/EDR, the output is the LTK.

5. <span>Bonding Flags</span> and <span>Key Distribution</span>:

• • <span>Bonding Flags</span>: Configuration parameters exchanged during the pairing process. One key flag <span>CTKD</span> needs to be set by both devices to <span>Supported</span> or <span>Not Supported</span> to indicate whether CTKD functionality is supported.
• • <span>Key Distribution</span>: In pairing phase 3, the device executing CTKD will distribute the derived key (BR/EDR Link Key or LE LTK) to the other device. This is equivalent to informing the other device: “We have paired on another transport layer, here is the key for that transport layer.”

6. <span>Derived</span> State and <span>Restricted</span> State:

• • <span>Derived</span>: When a key is obtained through CTKD (rather than direct pairing), that key is marked as <span>Derived</span> state.
• • <span>Restricted</span>: This is a very important security feature! Keys marked as <span>Derived</span> automatically inherit the <span>Restricted</span> state of their source <span>Cross-transport Key</span>. This means:
• • <span>Restricted</span> keys cannot be used to perform CTKD derivation! This is to prevent the key derivation chain from extending indefinitely, leading to blurred security boundaries. For example, a BR/EDR Link Key derived from an LE Secure Connection is <span>Derived</span> and <span>Restricted</span>, and it cannot be used to derive another LE LTK.
• • <span>Unrestricted</span> keys can only be used to perform CTKD derivation. Only keys generated through complete pairing (using compliant security methods) are <span>Unrestricted</span>, and can be used as a <span>Cross-transport Key</span> to derive keys for another transport layer.

Overview of CTKD Process (Example of LE Secure Connection Pairing Deriving BR/EDR Key)

1. 1. User Action: The user pairs the phone (Initiator) and the headset (Responder) on the LE transport layer, using the Passkey Entry (or Numeric Comparison / OOB) method.
2. 2. Pairing Process:

• • Execute the LE Secure Connection pairing process (Pairing Phase 1: Public Key Exchange, Pairing Confirm/Check; Phase 2: Authentication, LTK generation).
• • In Pairing Phase 3 (Key Distribution):
• • Both devices confirm support for CTKD through <span>Bonding Flags</span>.
• • The phone (or headset, depending on who is the deriving party) executes the <span>Cross-transport Key Derivation</span> Function, with inputs being the LE’s LTK (as the <span>Cross-transport Key</span>) and the Bluetooth addresses of both devices.
• • The derivation function outputs a BR/EDR Link Key.
• • The deriving party distributes the generated BR/EDR Link Key to the other device (through an encrypted channel).

3. Result:

• • LE Transport Layer: Has a directly paired <span>Unrestricted</span> LTK. Connection is secure.
• • BR/EDR Transport Layer: Has a <span>Derived</span> and <span>Restricted</span> Link Key derived through CTKD. This key is securely distributed, so the BR/EDR transport layer is also considered paired and securely connected, and the user does not need to perform BR/EDR pairing again.
• • The user only needs to pair once (on LE) to use the device on both transport layers.

Security Significance of CTKD

1. 1. Enhancing User Experience: One pairing, dual-mode available. Simplified operation.
2. 2. Security Inheritance:

• • The security strength of the derived key depends on the security strength of the source <span>Cross-transport Key</span>.
• • The source pairing must use methods that provide MITM protection (Passkey, Numeric Comp, OOB), ensuring that the starting point of the derivation process is secure.
• • The derivation algorithm is a standardized cryptographic secure function.

3. Preventing Misuse of Key Derivation Chain (<span>Restricted</span> Flag): This is the core of the CTKD security architecture. It ensures that key derivation can only occur once (from <span>Unrestricted</span> to <span>Derived Restricted</span>), preventing potential security risks (such as reducing key strength or expanding the attack surface through multiple derivations).

Key Points Summary

• • Purpose: To allow a single pairing of dual-mode Bluetooth devices (on a transport layer that meets security requirements) to establish secure connections on both transport layers (BR/EDR and LE).
• • Foundation: Perform pairing on the source transport layer (CTKD pairing transport layer) using methods that meet security requirements (MITM protection) to generate an <span>Unrestricted</span> <span>Cross-transport Key</span>.
• • Mechanism: Use the <span>Cross-transport Key</span> and device addresses to derive the long-term key for the target transport layer (Link Key or LTK) through a standard KDF.
• • State Management: The derived key is marked as <span>Derived</span> and <span>Restricted</span>, clearly indicating its source and preventing it from being used for further derivation.
• • Dependency: Both devices must declare support for CTKD through <span>Bonding Flags</span>.
• • Prerequisite: The source pairing must use secure methods (not Just Works) to generate a valid <span>Unrestricted</span> <span>Cross-transport Key</span>.

Welcome to Follow:

Feel free to add WeChat to join the group for discussions:

For more, please click the lower left corner Read the original text!