【消息序列】详解(3)：探究蓝牙 ACL 连接确立后的可选操作

蓝牙ACL（Asynchronous Connection-Less）连接确立后，存在一系列可选操作，这些操作旨在进一步增强连接的安全性、可靠性和功能性。本文将深入探究蓝牙 ACL 连接确立后的可选操作，包括认证请求、获取远程设备信息、数据传输优化、服务发现和连接以及安全和认证等方面。

一、请求认证

1.1. 连接建立后的认证执行

在蓝牙设备之间的连接成功建立之后，可以随时明确执行认证过程。认证是确保设备间安全通信的重要步骤，它验证了设备的身份并防止了未经授权的访问。

• 链路密钥（Link Key）的获取：如果当前没有可用的链路密钥，那么需要从主机（Host）获取。链路密钥是用于加密和认证蓝牙设备之间通信的密钥。

执行说明：

• 检查链路密钥：在发起认证请求之前，控制器或链路管理器应检查是否已存在有效的链路密钥。如果不存在，则需要进行下一步操作。

• 请求链路密钥：如果链路密钥不可用，控制器或链路管理器应向主机发送请求，以获取所需的链路密钥。

• 接收并存储链路密钥：主机在接收到链路密钥请求后，应返回相应的链路密钥。控制器或链路管理器在接收到链路密钥后，应将其存储在安全的位置，以便后续使用。

• 执行认证：在获得链路密钥后，控制器或链路管理器可以使用该密钥来执行认证过程，确保连接的安全性。 

链路密钥的来源：链路密钥可以预先存储在设备中，也可以在需要时从主机获取。主机通常会管理和存储与各个连接设备相关的链路密钥。如果在连接建立后发现没有可用的链路密钥，就需要采取措施获取它。

配对过程的触发:  如果控制器、链路管理器和主机都没有链路密钥，那么设备就需要进行配对操作。配对是为了建立新的链路密钥或者获取已有的链路密钥。具体的配对方式取决于设备的类型、安全需求以及应用场景等因素。

例如，在一些对安全要求较高的应用场景中，如金融交易或敏感数据传输，设备可能会在连接建立后立即进行认证操作，以确保通信的安全性。如果没有链路密钥，设备将按照特定的配对流程进行配对，生成新的链路密钥或者从其他存储位置获取已有的链路密钥。

1.2. 安全连接与安全认证

当两个设备都支持安全连接（Secure Connections）时，它们会使用安全认证（Secure Authentication）来确保连接的安全性。安全连接是蓝牙技术中一种增强的安全机制，它采用了更先进的加密算法和认证流程，以保护设备之间的通信不被未经授权的访问和窃听。

在安全认证过程中，设备会交换一系列的加密信息，并使用这些信息来验证对方的身份。安全认证的优势在于它提供了更高的安全性，因为使用了更强大的加密算法和更复杂的认证流程。例如，安全认证可能使用椭圆曲线密码学（ECC）等更先进的加密算法，提供更高的安全性和性能。同时，安全认证可能还包括设备身份验证、数字签名等机制，以防止中间人攻击和其他安全威胁。

需要注意的是，安全认证并不是蓝牙连接中唯一的安全机制。蓝牙技术还提供了其他的安全特性，如加密、身份验证和数据完整性检查等，这些特性与安全认证一起工作，共同确保蓝牙连接的安全性。

二、安全简单配对（Secure Simple Pairing）

安全简单配对（Secure Simple Pairing，SSP）是一种在蓝牙设备之间建立安全连接的方法，旨在提供更便捷、更安全的配对体验。这个过程涉及多个步骤，包括信息收集、启用安全功能、连接建立、认证和密钥计算等。两个设备之间的安全简单配对流程图如下图所示。

这个过程分为 11 个不同的步骤，其中一些步骤有多个不同的选项。这些步骤共同构成了Secure Simple Pairing的完整流程，确保了两个设备之间安全、可靠的连接。在实际应用中，这些步骤可能因设备的具体实现和蓝牙版本的差异而略有不同。

2.1.  可选的带外（OOB）信息收集

OOB（Out of Band）信息收集是指在蓝牙设备间进行OOB信息交换之前，设备的主机（Host）从控制器（Controller）中获取必要的OOB信息（如C值和R值）的过程。这些信息通常用于后续的设备配对和认证过程，以增强连接的安全性。

2.1.1. 流程与步骤

• 支持检查：首先，设备的主机和控制器需要支持OOB信息交换。如果支持，主机将向控制器请求必要的OOB信息。

• 信息请求：主机使用适当的HCI（Host Controller Interface）命令从控制器获取OOB信息。对于支持安全连接的设备，应使用HCI_Read_Local_OOB_Data命令。

• 信息获取：控制器响应主机的请求，并返回所需的OOB信息（如C值和R值）。这些信息是后续OOB信息交换和配对过程中必不可少的。

  • C值和R值：C值和R值是用于蓝牙配对过程中的两个关键参数。它们通常用于生成确认值（Confirmation Value），这是蓝牙安全连接的一部分，用于验证配对的完整性。

• 信息传输：主机获取OOB信息后，可以将其传输给OOB系统（如NFC芯片、二维码生成器等），以便与其他设备进行交换。这个传输过程可以在设备出厂前完成，也可以由用户在设备使用过程中进行。

• 存储与准备：OOB信息被传输到OOB系统后，设备就准备好了与其他支持OOB信息交换的设备进行配对。这些信息将在后续的配对过程中被使用，以增强连接的安全性。

2.1.2. 应用场景与影响

OOB信息收集通常应用于需要高度安全性的蓝牙设备配对场景中。例如，在智能家居、医疗设备或汽车蓝牙连接等领域，使用OOB信息收集可以增强设备间的认证过程，防止未经授权的设备接入网络。

通过OOB信息收集，设备可以在不依赖传统蓝牙通信通道的情况下，通过其他安全通道（如NFC、二维码等）交换关键认证信息。这有助于降低蓝牙通信被拦截或干扰的风险，提高设备间的互操作性和安全性。

2.1.3. 注意事项

• 兼容性：在使用OOB信息收集功能之前，请确保设备的主机和控制器都支持该功能，并已正确配置相关参数。
• 安全性：在传输和存储OOB信息时，请确保采取适当的安全措施，以防止信息泄露或被恶意利用。
• 用户指导：对于需要用户参与的OOB信息收集过程（如通过NFC芯片或二维码扫描），请提供清晰的用户指导，以确保用户能够正确完成操作。

OOB信息收集是蓝牙设备间进行安全配对的重要步骤之一。通过从控制器获取必要的OOB信息，并将其传输给OOB系统，设备可以准备好与其他支持OOB信息交换的设备进行安全配对。

2.1.4. HCI_Read_Local_OOB_Extended_Data命令

当控制器和主机都支持安全连接时，为了更好地处理带外信息，会使用 “HCI_Read_Local_OOB_Extended_Data” 命令。这个命令可能提供了更丰富的功能或者更安全的方式来获取和处理带外信息，相比 “HCI_Read_Local_OOB_Data” 命令更加适合安全连接的场景。

例如，在某些安全要求较高的工业环境中，无源标签可能在生产阶段就通过带外信息交换进行了预配置。当设备在实际使用中需要进行配对或认证时，主机可以根据设备的支持情况选择合适的命令来获取带外信息，确保安全连接的建立。

在实际应用中，设备制造商可能会根据他们的具体需求和设计来实现OOB信息收集的流程和机制。这包括确定如何存储和传输OOB信息，以及如何在蓝牙配对过程中使用这些信息。

2.2. 启用安全简单配对和安全连接（Enable Secure Simple Pairing and Secure Connections）

2.2.1. 启用安全简单配对（Secure Simple Pairing）

为了启用安全简单配对功能，蓝牙设备需要使用HCI_Write_Simple_Pairing_Mode命令。这个命令是在设备之间建立任何使用安全简单配对的连接之前必须执行的。安全简单配对是一种增强的配对机制，旨在提高蓝牙设备间配对的安全性和易用性。

在执行HCI_Write_Simple_Pairing_Mode命令时，设备可以指定其支持的配对模式，如数字比较、仅输入（Passkey Entry）或仅输出（Passkey Display）等。这些模式决定了在配对过程中用户需要执行的操作。

2.2.2. 配置安全连接（Secure Connections）

为了配置控制器以使用安全连接相关的HCI命令和事件，设备需要使用HCI_Write_Secure_Connections_Host_Support命令。这个命令必须在没有任何ACL（Asynchronous Connection-Less）连接存在的情况下执行。

安全连接是蓝牙技术的一项安全增强功能，它提供了更强大的加密算法和更安全的密钥交换机制。通过使用安全连接，设备可以确保在配对和连接过程中数据的安全性，并降低被攻击的风险。

2.2.3. 配置认证有效载荷超时（Authenticated Payload Timeout）

除了启用安全简单配对和配置安全连接外，设备还可以通过执行HCI_Write_Authenticated_Payload_Timeout命令来配置控制器。

这个命令允许设备设置在使用AES-CCM加密时，包含MIC（Message Integrity Code，消息完整性代码）的数据包之间的最大间隔时间。如果在这个时间间隔内没有接收到包含MIC的数据包，控制器可能会认为连接已经中断或存在安全问题，并采取相应的措施。

2.2.4. 命令执行时机与影响

• HCI_Write_Simple_Pairing_Mode：必须在建立任何使用安全简单配对的连接之前执行。这个命令的执行将启用设备的安全简单配对功能，并为后续的配对过程做好准备。
• HCI_Write_Secure_Connections_Host_Support：必须在没有任何ACL连接存在的情况下执行，以配置控制器以支持安全连接相关的HCI命令和事件。
• HCI_Write_Authenticated_Payload_Timeout：可以在任何时间执行，但通常建议在配置安全连接后执行，以确保在加密通信中设置合适的超时参数。

通过执行这些命令，设备可以启用安全简单配对和安全连接功能，并配置认证有效载荷超时参数，从而提高蓝牙通信的安全性和可靠性。这些功能对于保护用户数据和隐私至关重要，特别是在需要高度安全性的蓝牙应用场景中。

2.2.4. 注意事项

• 在执行这些命令之前，请确保设备的主机和控制器都支持所需的功能，并已正确配置相关参数。
• 在执行HCI_Write_Secure_Connections_Host_Support命令时，请确保没有任何ACL连接存在，以避免命令执行失败或导致连接中断。
• 在配置认证有效载荷超时参数时，请根据实际情况和安全性需求进行合理的设置，以避免因超时参数设置不当而导致的连接中断或安全问题。
• 在启用安全简单配对和安全连接功能后，请确保遵循相关的安全最佳实践，以保护设备免受潜在的攻击和威胁。

2.3. 连接建立（Connection establishment）

安全简单配对的主要作用是提高蓝牙设备间配对的安全性和易用性。通过减少用户输入和提供更强的加密，它使得设备之间的配对过程更加简单和安全。

2.3.1. 安全简单配对的触发机制

一旦安全简单配对功能被启用，可以通过以下两种可能的动作之一被触发：

• L2CAP连接请求触发：
  • 当一个设备尝试通过L2CAP（Logical Link Control and Adaptation Protocol Layer）协议层建立到另一个设备的连接，并且这个连接请求是针对一个需要安全性的服务时，安全简单配对将被触发。
  • 在这种情况下，如果目标设备尚未与发起设备配对，或者配对信息已经过时，那么将启动安全简单配对过程，以确保连接的安全性。
• OOB信息传输触发：
  • OOB（Out Of Band）信息传输是指通过蓝牙技术之外的其他方式（如NFC、二维码等）在设备之间传输配对信息。
  • 当两个设备通过OOB方式交换了必要的配对信息后，安全简单配对过程也可以被触发。
  • 这种方式通常用于简化配对过程，特别是在用户希望快速建立连接而不想手动输入配对码（如Passkey）的情况下。

2.3.2. 连接建立的过程

一旦安全简单配对被触发，设备将开始执行一系列步骤来建立安全的连接：

• 配对信息交换：设备之间将交换必要的配对信息，如随机数、公钥等。
• 加密密钥生成：使用交换的信息，设备将共同生成一个加密密钥，用于后续的通信加密。
• 认证过程：设备将验证对方身份的合法性，确保连接的安全性。
• 连接建立：一旦认证成功，设备将建立连接，并开始使用生成的加密密钥进行通信。

2.3.3. 注意事项

• 在使用安全简单配对时，请确保设备支持该功能，并已正确配置相关参数。
• 在通过OOB方式传输配对信息时，请确保信息的安全性和完整性，避免被第三方截获或篡改。
• 在建立连接之前，请确保设备之间的配对信息是最新的，以避免使用过时的配对信息导致连接失败或安全性问题。

安全简单配对是一种重要的蓝牙安全技术，它可以通过L2CAP连接请求或OOB信息传输来触发，从而确保设备之间建立安全的连接。

2.4. 对安全服务的 L2CAP连接请求(L2CAP connection request )

在蓝牙技术中，L2CAP（Logical Link Control and Adaptation Protocol Layer）是蓝牙协议栈中的一层，它负责数据包的传输和适配。当两个蓝牙设备之间已经建立了连接（通常是指ACL连接，即Asynchronous Connection-Less连接），并且其中一个设备希望与另一个设备上的某个特定服务进行通信时，它会发起一个L2CAP连接请求。

2.4.1. 安全服务的L2CAP连接请求

如果请求连接的服务是一个需要认证和加密的服务（即安全服务），那么发起连接请求的设备将启动安全简单配对（Secure Simple Pairing，SSP）过程。这是为了确保在传输敏感数据之前，两个设备之间已经建立了安全的连接，并且双方的身份都得到了验证。

2.4.2. 安全简单配对的启动

当设备收到一个针对需要安全性的服务的L2CAP连接请求时，它将检查是否已经与该设备配对，并且配对信息是否仍然有效。如果设备尚未配对，或者配对信息已经过时，那么它将启动安全简单配对过程。这个过程通常包括以下几个步骤：

• 信息交换：设备之间交换必要的配对信息，如随机数、公钥等。
• 密钥生成：使用交换的信息，设备共同生成一个用于后续通信加密的密钥。
• 认证：设备验证对方的身份，确保连接的安全性。
• 加密：一旦认证成功，设备将开始使用生成的密钥对通信进行加密。

2.4.3. 连接建立与服务访问

一旦安全简单配对过程完成，并且设备之间建立了安全的L2CAP连接，那么发起连接请求的设备就可以开始访问目标设备上的安全服务了。这通常涉及到数据包的传输和接收，以及可能的服务特定协议的处理。

2.4.4. 注意事项

• 在请求安全服务的L2CAP连接之前，请确保设备支持安全简单配对功能，并已正确配置相关参数。
• 如果设备已经配对，并且配对信息仍然有效，那么可能不需要重新执行安全简单配对过程。
• 在传输敏感数据之前，始终确保设备之间的连接是安全的，并且已经通过了适当的认证和加密步骤。

当设备请求一个需要认证和加密的服务的L2CAP连接时，它将启动安全简单配对过程，以确保在传输敏感数据之前建立安全的连接。

2.5. 可选的带外信息传输

OOB（Out of Band）信息传输是一种在蓝牙设备间传输额外信息的方法，这些信息通常用于增强设备间的认证过程。即使两个蓝牙设备之间尚未建立连接，OOB信息传输也可以发生。它主要用于传输设备的蓝牙设备地址和用于身份验证的其他OOB信息。

2.5.1. 传输内容

• 蓝牙设备地址：每个蓝牙设备都有一个唯一的设备地址，这个地址在OOB信息传输中被传输，以便设备间能够相互识别。
• 其他OOB信息：除了蓝牙设备地址外，OOB信息传输还可以包括其他用于身份验证的信息，如随机数、时间戳等。这些信息有助于设备间在后续建立连接时进行更安全的认证。

2.5.2. 触发与流程

• 触发条件：OOB信息传输可以在两个设备之间尚未建立蓝牙连接时发生。它通常由用户操作或设备间的某种交互触发，如通过NFC（近场通信）或其他无线技术传输信息。

• 传输流程：

  • 设备A生成或获取要传输的OOB信息，并将其存储在本地。
  • 设备A通过某种方式（如NFC、二维码扫描等）将OOB信息传输给设备B。
  • 设备B接收并存储OOB信息。
  • 如果设备A和设备B都支持OOB信息交换，并且已经配置了相应的功能，则它们可以在后续建立蓝牙连接时使用这些信息来增强认证过程。

2.5.3. 应用与影响

• 应用场景：OOB信息传输在蓝牙设备间建立安全连接时非常有用。例如，在两个设备首次配对时，它们可以使用OOB信息来验证对方的身份，从而确保连接的安全性。
• 影响：通过OOB信息传输，蓝牙设备可以更安全地建立连接，并减少被未经授权的设备接管的风险。此外，它还可以提高设备间的互操作性和用户体验。

2.5.4. 注意事项

• 兼容性：并非所有蓝牙设备都支持OOB信息传输。因此，在使用此功能之前，请确保设备支持该功能并已正确配置。
• 安全性：虽然OOB信息传输可以增强设备间的认证过程，但用户仍需注意保护个人信息和设备安全。避免将OOB信息泄露给未经授权的设备或人员。

OOB信息传输是一种在蓝牙设备间传输额外信息以增强认证过程的方法。它可以在设备间尚未建立连接时发生，并包括蓝牙设备地址和其他用于身份验证的OOB信息。通过OOB信息传输，蓝牙设备可以更安全地建立连接并提高用户体验。

2.6. 启动安全简单配对（Start Secure Simple Pairing）

在蓝牙设备之间建立连接的过程中，如果主机（Host）确定需要启动安全简单配对（Secure Simple Pairing，SSP），它将向控制器（Controller）发出一个HCI_Authentication_Requested命令。这个命令是蓝牙主机控制器接口（HCI）的一部分，用于指示控制器开始认证过程。

2.6.1. 控制器的响应与链路密钥请求

• 接收到HCI_Authentication_Requested命令后，控制器会生成一个链路密钥（Link Key）请求。链路密钥是用于加密蓝牙设备之间通信的密钥。
• 如果主机已经为这个连接存储了一个有效的链路密钥（即之前已经成功配对过，并且配对信息仍然有效），那么就不需要重新进行配对过程，可以直接使用这个链路密钥进行通信，前提是它已经被认证过。

2.6.2. 链路密钥请求的负面回复与SSP的启动

• 然而，如果主机没有为这个连接存储有效的链路密钥，或者链路密钥已经过时，那么主机将不会立即回复控制器以提供链路密钥。
• 相反，它可能会向控制器发送一个HCI_Link_Key_Request_Negative_Reply命令，表示它无法提供链路密钥。这个回复是启动安全简单配对过程的触发点。
• 一旦控制器接收到HCI_Link_Key_Request_Negative_Reply命令，它将知道需要通过安全简单配对过程来生成一个新的链路密钥。这个过程通常包括交换随机数、生成密钥、进行认证等步骤，以确保两个设备之间能够安全地建立连接。
• 例如，当设备连接到一个新的、之前从未配对过的蓝牙服务，或者之前的链路密钥由于某些原因（如长时间未使用被删除、设备进行了安全策略更新等）已不可用时，就会触发这样的机制，启动安全简单配对过程，通过后续一系列的操作（如交换公钥、进行认证等步骤）来获取新的链路密钥，确保通信安全。

2.6.3. 安全简单配对的过程

• 安全简单配对过程旨在提高蓝牙设备之间配对的安全性和易用性。
• 它通过使用椭圆曲线密码学（ECC）等更强大的加密算法，以及减少用户输入（如通过数字比较或OOB方式交换信息）来简化配对过程。
• 一旦安全简单配对过程完成，两个设备之间将生成一个新的、经过认证的链路密钥，用于后续的通信加密。

2.6.4. 注意事项

• 在启动安全简单配对之前，请确保设备支持该功能，并已正确配置相关参数。
• 如果设备之前已经配对过，并且配对信息仍然有效，那么可能不需要重新进行安全简单配对过程。
• 在安全简单配对过程中，请确保设备之间的通信是安全的，避免被第三方截获或篡改。

当主机确定需要启动安全简单配对时，它会向控制器发出HCI_Authentication_Requested命令。如果主机没有为这个连接存储有效的链路密钥，它将发送一个负面回复来触发安全简单配对过程。这个过程将确保两个设备之间能够安全地建立连接，并生成一个新的、经过认证的链路密钥用于后续的通信加密。

2.7. IO 能力交换（IO capability exchange）

在蓝牙SSP配对过程中，为了确定使用哪种正确的认证算法，两个设备需要交换它们的输入输出（IO）能力。这些能力决定了设备在配对过程中能够支持哪些类型的用户交互和认证方法。

2.7.1. 输入输出能力的类型

蓝牙标准定义了四种主要的IO能力：

• DisplayOnly：设备只能显示信息，不能接收用户输入。例如，一个只有LED显示屏的蓝牙音箱。
• DisplayYesNo：设备可以显示信息，并且能够通过用户按键（如“是”或“否”）来响应。这通常用于确认配对请求。
• KeyboardOnly：设备只能接收用户输入，不能显示信息。这通常用于没有显示屏的蓝牙设备，如某些蓝牙耳机。
• NoInputNoOutput（NINO）：设备既不能显示信息，也不能接收用户输入。这种设备通常依赖于其他方式（如OOB，即Out Of Band，带外方式）来进行配对。

2.7.2. 交换输入输出能力的过程

在蓝牙设备开始配对之前，它们会通过蓝牙协议栈中的相关层（如L2CAP和HCI）来交换这些IO能力信息。一旦两个设备知道了彼此的IO能力，它们就可以根据这些信息来选择最合适的认证算法。

2.7.3. 认证算法的选择

根据交换的IO能力，设备可以选择以下四种认证方法之一：

• Numeric Comparison：如果两个设备都支持显示和输入（或至少一个支持显示，另一个支持输入），则可以使用数字比较方法。在这种方法中，两个设备会生成一个相同的数字，并显示在屏幕上供用户比较。如果数字匹配，则用户确认配对。

• Passkey Entry：如果一个设备是键盘输入型（KeyboardOnly），而另一个是显示型（DisplayOnly或DisplayYesNo），则可以使用Passkey Entry方法。在这种方法中，用户会在键盘输入型设备上输入一个Passkey（通常是六位数字），而显示型设备会显示这个Passkey供用户确认。

• Out Of Band（OOB）：如果设备支持OOB方式，则可以通过蓝牙之外的其他通信手段（如NFC、二维码等）来交换配对信息。这种方法不需要用户输入或显示数字。

• Just Works：如果两个设备都不支持上述任何一种方法（例如，它们都是NINO设备），则可以使用Just Works方法。在这种方法中，设备会自动完成配对过程，而不需要用户交互。但是，这种方法的安全性较低，因为它不使用用户提供的任何信息来增强配对的安全性。

2.7.4. 注意事项

• 在交换IO能力时，请确保设备之间的通信是安全的，避免被第三方截获或篡改。
• 根据设备的IO能力选择正确的认证算法对于确保配对过程的安全性和用户体验至关重要。

输入输出能力交换是蓝牙安全简单配对过程中的一个重要步骤，它允许设备根据彼此的IO能力来选择最合适的认证算法。这个过程对于确保配对过程的安全性和用户体验至关重要。

2.8. 公钥交换（Public key exchange）

接下来，两个设备之间会进行公钥交换。一旦某个设备接收到了对等设备的公钥，它就能够开始计算迪菲 - 赫尔曼密钥（Diffie-Hellman Key，简称 DHKey）了。这个密钥将用于后续的加密和认证过程，确保设备之间通信的安全性。

公钥是一种基于非对称加密算法的概念，每个设备都有自己的公钥和与之对应的私钥，公钥可以公开分享给其他设备，而私钥则需要严格保密。通过交换公钥，设备之间就建立起了后续进行密钥协商和生成的基础，为安全通信做好准备。

例如，就好比两个人要进行秘密通信，他们先互相交换了一把特制的 “公开锁”（公钥），后续基于对方提供的这把 “公开锁” 来进一步打造只有彼此能打开的 “专属锁”（DHKey 等用于安全通信的密钥）。 

2.8.1. 公钥交换的过程

• 生成公钥和私钥对：在公钥交换开始之前，每个设备都会生成自己的公钥和私钥对。这些密钥对是使用椭圆曲线密码学（ECC）算法生成的，具有高度的安全性和效率。

• 交换公钥：一旦公钥和私钥对生成完毕，两个设备就会通过蓝牙协议栈中的相关层（如L2CAP和HCI）来交换它们的公钥。这个过程中，设备会将自己的公钥发送给对方，并接收对方的公钥。

• 计算DHKey：接收到对方的公钥后，每个设备都会使用自己的私钥和对方的公钥来计算DHKey。这个过程可能比较耗时，因为它涉及到复杂的数学运算。因此，建议尽早开始这个计算过程，以便在用户进行其他交互（如确认配对请求）时能够隐藏计算时间。

2.8.2. DHKey的作用

DHKey在蓝牙安全简单配对过程中起着至关重要的作用。它是基于两个设备共享的私钥和公开的公钥计算得出的，因此只有这两个设备才能知道这个密钥。这个密钥将用于后续的加密和认证过程，确保设备之间通信的安全性。

需要注意的是，虽然DHKey在公钥交换后就开始计算，但它并不是立即需要的。实际上，它直到配对过程的第8步（即加密和认证步骤）才会被使用。因此，在计算DHKey的过程中，设备可以继续进行其他配对相关的操作。

2.8.3. 注意事项

• 在公钥交换过程中，请确保设备之间的通信是安全的，避免被第三方截获或篡改。
• 由于计算DHKey可能比较耗时，建议尽早开始这个计算过程，以便在用户进行其他交互时能够隐藏计算时间。
• 请确保设备支持椭圆曲线密码学（ECC）算法，以便能够生成和交换公钥。

公钥交换是蓝牙安全简单配对过程中的一个重要步骤，它允许两个设备共享一个基于Diffie-Hellman密钥交换算法的密钥（即DHKey）。这个密钥将用于后续的加密和认证过程，确保设备之间通信的安全性。在计算DHKey的过程中，设备可以继续进行其他配对相关的操作，但需要注意确保通信的安全性和设备的支持情况。

2.9. 认证（Authentication）

在蓝牙SSP配对过程中，认证是一个至关重要的步骤。它的主要目的是验证两个设备的身份，确保它们确实是彼此想要通信的设备，从而防止中间人攻击和其他安全威胁。

2.9.1. 认证算法的选择

蓝牙标准定义了三种主要的认证算法，这些算法的选择取决于两个设备的输入输出（IO）能力的组合。以下是这三种算法及其适用场景：

• Numeric Comparison（数字比较）：
  • 适用场景：当两个设备都支持显示和输入时。
  • 工作原理：两个设备会生成一个相同的随机数（通常是六位数字），并显示在屏幕上供用户比较。如果数字匹配，则用户确认配对，从而完成认证过程。
• Passkey Entry（密码输入）：
  • 适用场景：当一个设备是输入型（如键盘），而另一个是显示型时。
  • 工作原理：用户会在输入型设备上输入一个密码（通常是六位数字），而显示型设备会显示这个密码供用户确认。如果密码匹配，则完成认证过程。
• Just Works（直接工作）：
  • 适用场景：当两个设备都不支持上述任何一种方法时（例如，它们都是无法显示或输入的设备）。
  • 工作原理：在这种情况下，设备会使用一种简化的认证过程，通常不涉及用户交互。然而，这种方法的安全性较低，因为它不使用用户提供的任何信息来增强配对的安全性。因此，它通常只在没有其他更安全的方法可用时才使用。

2.9.2. 认证过程

一旦选择了合适的认证算法，两个设备就会开始执行认证过程。这个过程可能包括生成随机数、显示或输入数字、进行数学运算等步骤。在认证过程中，设备会验证对方的身份，并确保它们确实是彼此想要通信的设备。

2.9.3. 注意事项

• 在认证过程中，请确保设备之间的通信是安全的，避免被第三方截获或篡改。
• 根据设备的IO能力选择正确的认证算法对于确保配对过程的安全性和用户体验至关重要。
• 如果可能的话，建议使用更安全的认证算法（如数字比较或密码输入），因为它们提供了更高的安全性。

认证是蓝牙安全简单配对过程中的一个重要步骤，它允许设备验证彼此的身份，并确保它们之间的通信是安全的。在选择认证算法时，需要考虑设备的IO能力，并根据实际情况选择最合适的算法。在认证过程中，需要确保通信的安全性和设备的支持情况，以确保配对过程的安全性和用户体验。

2.10. 数字比较（Numeric Comparison）

在蓝牙SSP配对过程中，数字比较是一个关键的认证步骤。当两个设备都具备输出能力，或者其中一个设备没有输入或输出能力时，就会执行这一步。数字比较的目的是通过显示一个用户确认值来验证两个设备是否正在尝试与正确的对方进行配对。

例如，在蓝牙设备配对场景中，如果是两个智能手机进行配对，它们都拥有屏幕等输出方式，满足第一种情况，就会执行数字比较步骤。又比如，一个简单的蓝牙传感器（可能只具备基本的数据采集功能，没有输入或输出能力用于复杂交互）与一个智能终端设备配对时，就符合第二种情况，同样也会进入数字比较环节。

2.10.1. 数字比较的执行条件

• 两个设备都具备输出能力：此时，两个设备都会显示一个相同的数字（用户确认值），供用户进行比较。
• 其中一个设备没有输入或输出能力：虽然这种情况不太常见，但如果发生，数字比较的步骤仍然会执行，但主机会跳过要求用户确认的步骤。这是因为没有输入或输出能力的设备无法参与比较过程。然而，在实际应用中，如果两个设备都无法进行输入或输出，它们通常会使用“Just Works”方法来进行配对。

2.10.2. 数字比较的过程

• 生成用户确认值：两个设备会各自生成一个相同的用户确认值。这个值通常是一个六位数字，但也可以是其他长度的数字或字符序列。
• 显示用户确认值：具备输出能力的设备会在屏幕上显示这个用户确认值。这个值会一直显示到配对过程的第8步结束。
• 用户比较和确认：用户需要比较两个设备上显示的数字是否相同。如果相同，则确认配对；如果不同，则拒绝配对。

2.10.3. 与“Just Works”方法的比较

数字比较方法与“Just Works”方法在流程上非常相似，但有一个关键的区别：在数字比较方法中，主机会显示数字给用户进行比较；而在“Just Works”方法中，主机不会显示任何数字给用户，因为这种方法通常用于没有输入或输出能力的设备，或者当安全性要求不是非常高时。

2.10.4. 注意事项

• 在数字比较过程中，请确保设备之间的通信是安全的，避免被第三方截获或篡改用户确认值。
• 如果设备没有输出能力，但支持其他形式的用户交互（如声音提示），也可以考虑使用这些交互方式来替代数字显示。
• 在实际应用中，数字比较方法通常用于那些对安全性要求较高的场景，如配对高价值的蓝牙设备时。

数字比较是蓝牙安全简单配对过程中的一个重要步骤，它允许用户通过比较两个设备上显示的数字来验证配对的正确性。在执行数字比较时，需要考虑设备的输出能力和用户交互方式，以确保配对过程的安全性和用户体验。

2.11.  发起方数字比较失败

如果发起方（即主动发起配对请求的设备）上的用户发现两个设备显示的用户确认值不匹配，他们可能会选择拒绝配对。这种情况下，数字比较步骤就会失败。

例如，在用户将手机与一个新的蓝牙音箱进行配对时，手机作为发起方，在数字比较步骤中，手机屏幕上显示的数字本应和音箱上显示（如果音箱有显示功能）或者提示（通过语音等其他方式）的数字一致。但如果用户发现手机上的数字与音箱那边对应的数字不一样，那么按照安全机制，就表明此次配对存在问题，为了保障数据安全以及避免连接到不可信的设备，整个安全简单配对流程就会立刻终止，手机和音箱之间也就无法成功建立蓝牙连接。 

2.11.1. 数字比较失败的影响

• 配对终止：一旦数字比较失败，整个Secure Simple Pairing过程将被终止。这意味着两个设备将无法建立安全连接，也无法进行后续的通信。
• 用户体验受损：数字比较失败可能会导致用户感到困惑或不满，特别是当他们确信两个设备应该是可以配对的时候。这可能会影响用户对蓝牙设备的整体印象和信任度。
• 安全风险：数字比较失败也可能意味着存在安全风险，例如中间人攻击或设备被冒充。因此，用户应该谨慎对待失败的配对尝试，并确保他们只与可信的设备进行配对。

2.11.2. 应对措施

• 重新尝试配对：如果数字比较失败，用户可以尝试重新发起配对请求，并仔细比较两个设备上显示的用户确认值。确保在比较过程中没有受到任何干扰或误导。
• 检查设备兼容性：在重新尝试配对之前，应该检查两个设备的兼容性，确保它们都支持Secure Simple Pairing，并且具有相同的输入输出（IO）能力。

2.11.3. 注意事项

• 在进行数字比较时，请确保设备之间的通信是安全的，避免被第三方截获或篡改用户确认值。
• 如果用户不确定是否应该接受配对请求，他们应该谨慎行事，并考虑咨询设备制造商或技术支持团队的建议。
• 在数字比较过程中，用户应该保持专注和耐心，以确保能够准确比较和确认两个设备上的数字。

数字比较失败是蓝牙安全简单配对过程中可能遇到的一个问题。当发生这种情况时，用户应该采取适当的应对措施来解决问题，并确保他们只与可信的设备进行配对。

2.12.  响应方数字比较失败

如果响应方（即接收配对请求的设备）上的用户发现两个设备显示的用户确认值不匹配，他们可能会拒绝配对。这种情况下，数字比较步骤在响应方就会失败。

例如，在将智能手表与手机进行蓝牙配对时，手机发起配对请求后，智能手表作为响应方会展示相应的确认值（可能通过屏幕显示或者语音提示等方式），此时用户需要核对手表显示的确认值和手机上显示的是否一样。 

2.12.1. 数字比较失败的影响

• 配对终止：与发起方数字比较失败一样，响应方数字比较失败也会导致整个Secure Simple Pairing过程被终止。这意味着两个设备将无法建立安全连接，也无法进行后续的通信。
• 用户体验受损：数字比较失败在响应方同样会导致用户感到困惑或不满，特别是当他们确信两个设备应该是可以配对的时候。这可能会影响用户对蓝牙设备的整体印象和信任度。
• 潜在的安全风险：数字比较失败可能意味着存在潜在的安全风险，例如设备可能被冒充或受到中间人攻击。因此，用户应该谨慎对待失败的配对尝试，并确保他们只与可信的设备进行配对。

2.12.2. 应对措施

• 重新尝试配对：如果数字比较在响应方失败，用户可以尝试重新发起配对请求，并确保在响应设备上仔细比较和确认用户确认值。
• 检查设备设置和兼容性：在重新尝试配对之前，用户应该检查两个设备的设置和兼容性，确保它们都支持Secure Simple Pairing，并且具有正确的输入输出（IO）能力。
• 确认设备身份：在配对过程中，用户应该确保他们正在与正确的设备进行配对。可以通过查看设备的名称、地址或其他标识符来确认设备身份。

2.12.3. 注意事项

• 在进行数字比较时，请确保设备之间的通信是安全的，避免被第三方截获或篡改用户确认值。
• 用户应该保持警惕，避免受到任何形式的欺骗或误导，特别是在公共场所或不受信任的网络环境中。
• 如果用户不确定是否应该接受配对请求，他们应该谨慎行事，并考虑咨询设备制造商或技术支持团队的建议。

数字比较失败在响应方同样会导致蓝牙安全简单配对过程被终止。为了解决这个问题，用户应该采取适当的应对措施，并确保他们只与可信的设备进行配对。同时，设备制造商和技术支持团队也应该提供必要的帮助和指导，以改善用户体验和确保设备的安全性。

2.13.  密码输入（Passkey Entry）

密码输入步骤是蓝牙安全简单配对过程中的一个重要环节。它确保了只有经过用户确认的设备才能成功配对。通过遵循正确的输入步骤和注意事项，用户可以确保他们的蓝牙设备能够安全地与其他设备建立连接。

2.13.1. 密码输入步骤的适用场景

密码输入步骤主要用于以下两种情况：

• 一个设备仅有数字输入能力，另一个设备具有显示或数字输入能力：在这种情况下，具有显示能力的设备会显示一个数字（通常称为密码或密钥），然后用户需要在另一个设备上输入这个数字。
• 两个设备都只有数字输入能力：在这种情况下，用户需要在两个设备上分别输入相同的数字。

2.13.2. 密码输入步骤的过程

• 显示数字：在具有显示能力的设备上，会显示一个由另一设备（或系统）生成的随机数字（密码）。这个数字会一直显示到配对过程的第8步结束。
• 用户输入：用户需要在另一个设备上（如果它具有输入能力）或通过某种方式（如键盘）在两个设备上输入显示的数字。
• 按键通知：在用户输入阶段，设备可能会显示按键通知消息，以提示用户正在输入数字。这有助于用户确认他们的输入操作。

2.13.3. 注意事项

• 数字的准确性：用户必须确保输入的数字与显示的数字完全相同。任何差异都可能导致配对失败。
• 输入时间限制：某些设备可能会为密码输入设置一个时间限制。如果用户在规定时间内未完成输入，配对过程可能会终止。
• 安全性：密码输入是蓝牙配对过程中的一个重要安全机制。它有助于防止未经授权的设备与您的设备建立连接。
• 用户体验：为了提高用户体验，设备可能会提供视觉或听觉反馈来确认用户的输入操作。

2.13.4. 与其他配对方法的比较

与数字比较方法相比，密码输入方法更适用于那些只有一个设备具有显示能力，而另一个设备只能输入数字的情况。数字比较方法则要求两个设备都具有显示能力，以便用户可以比较两个设备上显示的数字是否相同。

请注意，上述描述是基于蓝牙安全简单配对过程的一般理解。不同设备和制造商可能会有一些特定的实现细节和差异。因此，在实际操作中，用户应该参考他们所使用的设备和软件的官方文档或指南来获取更详细的信息。

2.14 响应方密码输入失败

如果响应方（即接收配对请求并需要输入密码的设备）上的用户未能正确输入或确认密码，就会导致密码输入失败。这种情况可能由以下原因引起：

• 用户输入错误：用户可能在响应设备上输入了错误的密码，或者由于某种原因（如按键不灵敏、视线不佳等）未能准确输入。
• 超时：如果用户在规定的时间内没有完成密码输入，某些设备可能会自动终止配对过程。
• 设备故障：响应设备可能存在故障或问题，导致无法正确接收或处理用户输入的密码。

2.14.1. 密码输入失败的影响

当响应方密码输入失败时，整个Secure Simple Pairing过程将被终止。这意味着两个设备将无法建立安全连接，也无法进行后续的通信。此外，密码输入失败还可能导致用户感到困惑或不满，特别是当他们确信已经正确输入了密码时。

2.14.2. 应对措施

• 重新尝试配对：如果密码输入失败，用户可以尝试重新发起配对请求，并确保在响应设备上准确输入密码。
• 检查设备状态：在重新尝试配对之前，用户应该检查响应设备的状态，确保它处于可配对模式并且没有故障或问题。
• 确认密码正确性：用户应该确保他们输入的密码与发起设备上显示的密码完全相同。如果可能的话，可以在发起设备上再次查看密码以确保准确性。

2.14.3. 注意事项

• 在进行密码输入时，请确保设备之间的通信是安全的，避免被第三方截获或篡改密码。
• 用户应该保持耐心和专注，以确保能够准确输入密码。
• 如果用户不确定是否应该输入密码或如何输入密码，他们应该参考设备的使用手册或在线支持资源以获取帮助。

响应方密码输入失败是蓝牙安全简单配对过程中可能遇到的一个问题。为了解决这个问题，用户应该采取适当的应对措施，并确保他们只与可信的设备进行配对。

2.15 发起方密码输入失败

如果发起方（即主动发起配对请求的设备）上的用户未能正确输入或确认密码，就会导致密码输入失败。这种情况可能由以下原因引起：

• 用户输入错误：用户在发起设备上输入的密码与响应设备上显示的密码不匹配。
• 设备兼容性问题：某些设备可能在处理密码输入时存在兼容性问题，导致发起方无法正确接收或处理用户输入的密码。
• 软件或硬件故障：发起设备可能存在软件或硬件故障，导致无法正确执行密码输入步骤。

2.15.1. 密码输入失败的影响（发起方）

当发起方密码输入失败时，整个Secure Simple Pairing过程将被终止。这意味着两个设备将无法建立安全连接，也无法进行后续的通信。此外，密码输入失败还可能导致用户感到困惑或不满，特别是当他们确信已经正确输入了密码时。

2.15.2. 特定条件

值得注意的是，发起方密码输入失败的情况通常只在以下特定条件下发生：

• 发起方的本地管理器（Local Manager，LM）发送了一个HCI_User_Passkey_Request事件。这个事件通常用于请求用户输入密码。如果用户在规定的时间内没有输入或确认密码，或者输入的密码与响应设备上的不匹配，就会触发密码输入失败。

2.15.3. 应对措施

• 重新尝试配对：如果密码输入失败，用户可以尝试重新发起配对请求，并确保在发起设备上准确输入密码。
• 检查设备兼容性：在重新尝试配对之前，用户应该检查两个设备的兼容性，确保它们支持相同的蓝牙版本和配对协议。
• 确认密码正确性：用户应该确保他们输入的密码与响应设备上显示的密码完全相同。如果可能的话，可以在响应设备上再次查看密码以确保准确性。
• 更新设备软件或固件：如果设备存在软件或固件问题，用户应该尝试更新到最新版本以解决可能的兼容性问题或故障。

2.15.4. 注意事项

• 在进行密码输入时，请确保设备之间的通信是安全的，避免被第三方截获或篡改密码。
• 用户应该保持耐心和专注，以确保能够准确输入密码。
• 如果用户不确定是否应该输入密码或如何输入密码，他们应该参考设备的使用手册或在线支持资源以获取帮助。

发起方密码输入失败进而终止安全简单配对这一机制，是蓝牙安全机制中不可或缺的一部分，它有力地保障了蓝牙设备间配对过程的严谨性以及后续通信的安全性，为用户营造一个安全可靠的蓝牙使用环境。

2.16 带外认证（Out of Band ）

带外认证（Out of Band，OOB）是一种蓝牙配对过程中的安全机制，它利用设备之间的非蓝牙通信渠道来增强配对的安全性。这种机制通常用于确保只有经过用户确认的设备才能成功配对，从而防止未经授权的设备接入。

重要的是，带外认证步骤不需要用户直接交互。一旦设备之间建立了带外通信通道并成功交换了必要的认证信息，它们就可以使用这些信息来完成蓝牙配对的认证阶段，而无需用户手动输入密码或进行其他形式的确认。使得整个配对过程更加自动化和便捷，尤其是在一些对效率要求较高或者用户操作不太方便的场景下，显得尤为重要。

2.16.1. 带外认证的应用场景

带外认证主要在以下情况下使用：

• 当两个设备都具备某种形式的带外通信能力时，例如通过NFC（近场通信）、二维码扫描、可见光通信和Wi-Fi Direct等其他非蓝牙技术交换方式。
• 用户希望提高配对过程的安全性，确保只有他们信任的设备才能建立连接。

例如在一些物联网设备的批量部署场景中，众多蓝牙传感器需要与控制中心进行配对，如果每个传感器在带外认证环节都需要用户手动输入信息或者进行确认等操作，那将会耗费大量的人力和时间成本。而带外认证无需用户交互，只要设备自身具备了相应的带外信息，就能自动完成认证过程，大大提高了配对的效率，同时也能保证一定的安全性，确保配对的设备是符合预期且相互信任的。 

2.16.2. 带外认证的过程

• 信息交换：在配对开始之前，两个设备通过带外通信渠道交换一些认证信息。这些信息可能包括随机数、哈希值或其他形式的加密数据。
• 验证信息：在蓝牙配对过程中，设备会使用这些带外交换的信息来验证对方的身份。这通常涉及对信息的加密、解密或哈希运算等操作。
• 完成配对：如果验证成功，两个设备将能够成功建立蓝牙连接，并进行后续的通信。

2.16.3. 带外认证的优势

• 提高安全性：通过引入带外通信渠道，带外认证能够防止中间人攻击和蓝牙劫持等安全威胁。
• 用户友好：由于带外认证通常不需要用户输入复杂的密码或进行繁琐的操作，因此它能够提高用户的配对体验。
• 兼容性：带外认证机制可以与多种蓝牙设备和操作系统兼容，因此具有广泛的应用前景。

2.16.4. 注意事项

• 在进行带外认证时，请确保设备之间的带外通信渠道是安全的，避免被第三方截获或篡改信息。
• 用户应该了解并信任所使用的带外认证方法，以确保其有效性和安全性。
• 如果设备不支持带外认证或用户不希望使用这种方法，他们可以选择其他蓝牙配对方式，如数字比较或密码输入等。

带外认证是一种有效的蓝牙配对安全机制，它能够提高配对过程的安全性和用户友好性。然而，用户在使用这种方法时应该了解并遵守相关的安全注意事项，以确保其有效性和安全性。

2.17 发起方带外认证失败

如果发起方（即主动发起配对请求的设备）没有可用的带外（Out of Band，OOB）信息，那么带外认证步骤将无法进行，从而导致带外认证失败。带外信息通常是通过非蓝牙通信渠道（如NFC、二维码等）在设备之间交换的。

如果发起方缺少带外信息，就如同在一场需要双方出示特定 “入场券” 的验证活动中，发起方却拿不出自己的那份 “入场券”，那么整个验证环节就无法正常进行下去。  

2.17.1. 带外认证失败的影响

当发起方带外认证失败时，整个Secure Simple Pairing过程将被终止。这意味着两个设备将无法建立安全连接，也无法进行后续的通信。此外，带外认证失败还可能导致用户感到困惑或不满，特别是当他们期望使用带外认证来提高配对安全性时。

2.17.2. 应对措施

• 检查设备支持：在尝试配对之前，用户应该检查发起设备和响应设备是否都支持带外认证。如果其中一方不支持，那么应该选择其他配对方式。
• 确认带外信息：用户应该确保在发起配对之前，两个设备之间已经通过带外通信渠道成功交换了必要的认证信息。

2.17.3. 注意事项

• 在进行带外认证时，请确保设备之间的带外通信渠道是安全的，避免被第三方截获或篡改信息。
• 用户应该了解并信任所使用的带外认证方法，以确保其有效性和安全性。
• 如果设备不支持带外认证或用户不希望使用这种方法，他们可以选择其他蓝牙配对方式，如数字比较、密码输入或传统配对等。

在进行蓝牙配对时，确保设备具备可用的带外信息是非常重要的。这不仅可以提高配对的成功率，还可以增强连接的安全性。如果设备不支持带外认证或没有可用的带外信息，那么用户可能需要使用其他方法（如手动输入密码）来完成配对过程。

2.18 DHKey 检查

当设备已经完成认证流程，并且迪菲 - 赫尔曼密钥（DHKey）的计算也顺利结束后，接下来就要对所生成的 DHKey 值进行检查了。这里的认证过程是通过前面一系列步骤中所采用的诸如基于设备 I/O 能力选择合适的认证算法等方式来完成的，其目的是确保参与配对的双方设备是合法且相互信任的。而 DHKey 的计算则是在设备间交换公钥之后启动的一个耗时的后台运算过程，它对于后续建立安全的蓝牙通信链路起着至关重要的作用。

例如，在智能手机与蓝牙耳机进行蓝牙配对时，智能手机和蓝牙耳机首先会按照既定的认证规则完成相互认证，确认彼此身份合法。然后，它们在之前交换公钥的基础上各自进行 DHKey 的计算，这个计算可能会花费一定时间，不过在后台默默进行，不影响前面认证等步骤的推进。 

2.18.2. DHKey检查的目的和重要性

对 DHKey 值进行检查的意义重大，它相当于对整个安全连接建立过程中的一个关键 “成果” 进行审核。通过特定的检查机制，确保这个生成的密钥符合预期的安全标准和算法要求，以此来验证后续将要用于加密蓝牙通信数据的这个密钥是可靠且有效的。

如果 DHKey 值检查出现问题，那就意味着可能存在安全漏洞，比如计算过程中受到干扰出现错误，或者有恶意攻击篡改了密钥生成相关的数据等情况，这样一来，设备之间的安全通信就无法得到保障。

2.18.2. DHKey检查成功后的操作

• 倘若 DHKey 值检查成功了，这意味着设备间的安全连接又顺利通过了一个重要的关卡。此时，两边的设备都已经完成了向用户展示关于配对及密钥生成等过程的相关信息，这些信息可能是在前面的认证、公钥交换以及 DHKey 计算等环节中，通过设备的显示屏或者语音提示等输出方式呈现给用户的，目的是让用户知晓配对过程的进展情况。

• 而当 DHKey 值检查通过后，就会从控制器向主机发送一个消息，通知主机可以停止继续展示这些信息了。这就好比一场演出已经顺利结束，工作人员会通知舞台上的展示设备可以关闭相应的展示画面一样，意味着这个阶段的任务圆满完成，设备可以进入到后续正常的、基于安全连接的通信状态了。

• 例如，在智能手表与手机配对成功后，手表和手机可能都在屏幕上向用户展示了一些配对进度、密钥生成情况等信息，当 DHKey 值检查无误后，手机和手表内部的控制器就会分别向各自的主机发送通知，手机屏幕和手表屏幕上相关的配对进度展示信息就会消失，它们之间便可以利用生成的安全密钥开始进行诸如同步数据、接收通知等正常的蓝牙通信操作了。

2.18.3. 注意事项

• 在进行DHKey检查时，请确保设备之间的通信是安全的，避免被第三方截获或篡改信息。
• 用户应该保持耐心，等待配对过程完成。在配对过程中，设备可能会显示一些状态信息或进度条，用户应该根据这些信息来判断配对是否成功。
• 如果DHKey检查失败，用户应该尝试重新进行配对操作，并确保两个设备都处于可配对状态且没有受到任何干扰。

DHKey检查是蓝牙安全简单配对过程中的一个重要步骤，它确保了两个设备能够成功生成并验证相同的DHKey，从而建立一个安全的连接。如果DHKey检查成功，那么两个设备就可以开始进行后续的通信了。

2.19 计算链路密钥（Calculate link key）

在蓝牙设备的SSP配对流程全部完成之后，接下来就要进行链路密钥（link key）的计算工作了。

2.19.1. 基于 DHKey 计算链路密钥

• 链路密钥的计算是以迪菲 - 赫尔曼密钥（DHKey）为基础来进行的。在前面的步骤中，设备之间先是通过交换公钥启动了 DHKey 的计算过程，而后经过一系列的认证以及 DHKey 值的检查等环节，确保了 DHKey 的准确性和安全性。此时，利用这个已经生成且验证通过的 DHKey，按照特定的算法和规则，就能计算出链路密钥。这个链路密钥对于后续建立起更加稳固且安全的蓝牙通信链路有着至关重要的作用，它可以被视作是后续诸多安全相关操作的一个关键 “钥匙”。
• 例如，想象在智能音箱与手机进行蓝牙配对的场景中，它们先是完成了安全简单配对里的各个步骤，包括认证环节、DHKey 的生成及检查等。随后，手机和智能音箱就会依据最终得到的那个合法有效的 DHKey，通过内置的加密算法模块来计算出链路密钥，为后续更深入的安全通信做好准备。

2.19.2. 用于标准相互认证

• 计算得出的链路密钥会被用作标准相互认证的输入参数。在蓝牙通信的安全体系里，相互认证是确保通信双方身份合法性以及连接安全性的重要机制。通过将链路密钥应用到这个相互认证过程中，设备之间可以再次对彼此的身份进行确认，并且验证整个通信链路是否可靠，防止出现非法接入、数据篡改等安全问题。
• 就好比两个人在交换了一把特制的 “信物”（链路密钥）后，彼此通过核对这一 “信物” 来确认对方就是预期中可以信任的人，从而放心地开展后续的交流互动（数据传输等通信行为）。

2.19.3. 生成通知事件HCI_Link_Key_Notification

• 一旦上述基于链路密钥的标准相互认证过程完成，系统就会生成一个 “HCI_Link_Key_Notification” 事件。这个事件的作用在于向相关的模块或者设备的主机等告知，链路密钥的计算以及相互认证这些重要步骤已经顺利结束了。
• 例如，在蓝牙耳机与手机配对成功且完成链路密钥相关操作后，手机端的蓝牙模块会收到这个 “HCI_Link_Key_Notification” 事件，得知链路密钥已经成功应用于相互认证，意味着接下来可以放心地利用这条安全的蓝牙链路进行音频数据等信息的传输了，手机也就可以根据这个通知做一些后续的设置或者准备工作，以便更好地与蓝牙耳机进行交互通信。

计算链路密钥这一环节在蓝牙设备完成安全简单配对后起着关键的承接作用，它不仅为后续的相互认证提供了重要依据，而且通过生成通知事件，让整个蓝牙通信系统知晓安全保障环节的进展情况，为后续安全、稳定的蓝牙通信奠定了坚实基础。

2.20 启用加密（Enable encryption）

在链路密钥（link key）被通知到主机之后，“HCI_Authentication_Requested” 命令将会伴随着 “HCI_Authentication_Complete” 事件完成执行。至此，主机就能够运用标准方法来开启加密功能了。

该过程的详细步骤：

• 链路密钥通知：当链路密钥通过 HCI_Link_Key_Notification 事件被成功生成并通知给主机时，这意味着两个蓝牙设备已经成功完成了相互认证过程。

• 认证完成事件：紧接着链路密钥通知，HCI_Authentication_Requested 命令会触发一个 HCI_Authentication_Complete 事件。这个事件表明认证过程已经结束，设备间已经建立了安全的连接。

• 启用加密：在收到认证完成事件后，主机可以使用标准的方法来启用加密。发送一个 HCI_Set_Connection_Encryption 命令给蓝牙控制器，指定要加密的连接句柄（Handle）和之前生成的链路密钥。

• 加密过程：一旦加密被启用，蓝牙控制器将开始使用链路密钥对传输的数据进行加密和解密。这确保了数据在设备间的传输过程中是安全的，即使数据被截获，也无法被未经授权的设备解密。

• 加密状态确认：加密启用后，主机会收到一个 HCI_Encryption_Change 事件，通知它加密状态已经改变（例如，从未加密变为已加密）。这个事件是可选的，具体取决于蓝牙控制器的实现。

例如，当手机与蓝牙耳机之间开启加密后，音频数据在从手机传输到耳机的过程中，就会以加密后的形式存在于蓝牙信号中，即使有人恶意监听蓝牙信号，接收到的也只是一堆毫无意义的乱码，只有耳机凭借正确的链路密钥等要素才能对其进行解密，还原出原本的音频内容，让用户能够安全地享受音乐等音频服务。

启用加密这一环节是在完成链路密钥相关操作以及认证流程之后的关键步骤，它基于前面的工作成果，进一步强化了蓝牙通信链路的安全性，为用户在使用蓝牙设备进行数据传输时提供了可靠的隐私保护，确保信息在蓝牙传输过程中不被泄露或篡改。

2.21 L2CAP 连接响应（L2CAP connection response）

在蓝牙设备的交互过程中，如果此次SSP配对是由一个 L2CAP（Logical Link Control and Adaptation Protocol Layer，逻辑链路控制和适配协议）连接请求所触发的，那么只有在完成了上述所有步骤之后，才能够发送 L2CAP 连接响应消息。

该过程的详细说明：

• L2CAP连接请求：L2CAP是蓝牙协议栈中的一个重要层，它负责在蓝牙设备间传输数据。当一个设备想要与另一个设备建立数据连接时，它可能会发送一个L2CAP连接请求。

• 触发SSP：如果L2CAP连接请求需要安全连接（例如，传输敏感数据），则可能会触发安全简单配对过程。这个过程包括相互认证、生成链路密钥等步骤，以确保两个设备之间的安全连接。

• 完成SSP步骤：在触发SSP后，必须完成所有相关的步骤，包括认证环节中验证设备的合法性、通过 DHKey（迪菲 - 赫尔曼密钥）计算及检查来生成可靠的密钥、依据链路密钥进行标准的相互认证、启用加密等，每一个环节都是在为蓝牙连接的安全性添砖加瓦。这些步骤确保了设备间的连接是安全的，并且数据在传输过程中不会被未经授权的设备截获或篡改。

  • 如果在前置步骤还未完成的情况下就贸然发送连接响应消息，就如同在房屋还未打好地基、砌好墙壁等基础建设时就急于安装屋顶一样，整个蓝牙连接的安全性将无法得到保障，很可能面临数据被窃取、篡改等风险。

  • 例如，若没有完成链路密钥相关的相互认证就发送 L2CAP 连接响应消息，可能会导致恶意设备伪装成合法设备接入蓝牙连接，进而获取本应保密的音频数据或者其他敏感信息，给用户带来隐私泄露等严重后果。

• 发送L2CAP连接响应：只有在上述所有SSP步骤都成功完成后，才能发送L2CAP连接响应消息。这个响应消息是对L2CAP连接请求的回应，表明设备已经准备好建立安全的数据连接。

• 建立L2CAP连接：一旦L2CAP连接响应被发送并接收，两个设备之间就建立了L2CAP连接。这个连接可以用于传输各种类型的数据，包括音频、视频、文件等。

L2CAP 连接响应这一环节是建立在完成安全简单配对诸多前置步骤基础之上的，它是确保蓝牙连接安全可靠且能够正常开展数据传输的关键一步，对于保障蓝牙通信的安全性和功能性有着重要意义。

2.22 LMP ping

在蓝牙通信中，当认证有效载荷超时（Authenticated Payload Timeout）即将到期时，链路管理器（Link Manager）会发送一个LMP_PING_REQ协议数据单元（PDU）给远程设备，以强制其发送一个包含消息完整性校验（MIC，Message Integrity Check）的数据包。当在经过认证的有效载荷超时时间内没有接收到包含 MIC 的数据包时，主机将被通知定时器已过期。

该过程的详细说明：

• 认证有效载荷超时：在蓝牙连接中，为了保持连接的安全性，设备间会定期交换认证的数据包。如果在一定时间内没有收到这些认证数据包，就会触发认证有效载荷超时。这个超时机制是为了确保连接仍然是活跃的，并且没有被未经授权的设备接管。

• LMP_PING_REQ PDU：当认证有效载荷超时即将到期时，链路管理器会发送一个LMP_PING_REQ PDU给远程设备。这个PDU是一个简单的请求，要求远程设备回应一个包含MIC的数据包。MIC是用于验证数据包完整性和真实性的一个校验码。

• 远程设备响应：收到LMP_PING_REQ PDU后，远程设备会生成一个包含MIC的响应数据包，并将其发送回发起请求的设备。这个响应数据包证明了远程设备仍然在线，并且连接仍然是安全的。

• 验证MIC：发起请求的设备会验证接收到的响应数据包中的MIC。如果MIC验证成功，那么连接被认为是安全的，并且认证有效载荷超时会被重置。如果MIC验证失败，那么连接可能会被认为是不安全的，并且可能会触发一些安全措施，如断开连接或重新进行认证过程。

• 保持连接安全：通过定期发送LMP_PING_REQ PDU并验证MIC，蓝牙设备可以确保它们之间的连接是安全的，并且没有被未经授权的设备接管。这对于维护蓝牙通信的完整性和安全性至关重要。

LMP_PING_REQ PDU是蓝牙通信中用于保持连接安全的一种机制。通过发送这个PDU并验证响应数据包中的MIC，设备可以确保它们之间的连接仍然是活跃的，并且没有被未经授权的设备接管。

三、HCI_Link_Supervision_Timeout_Changed事件

当主机（Host）启用链路监督超时（Link Supervision Timeout, LSTO）更改功能时，外设（Peripheral）在接收到LMP_SUPERVISION_TIMEOUT协议数据单元（PDU）后会生成一个HCI_Link_Supervision_Timeout_Changed事件。

3.1. 链路监督超时（Link Supervision Timeout, LSTO）

链路监督超时是蓝牙连接中的一个重要参数，它定义了如果两个设备在指定的时间内没有交换任何数据包，则蓝牙连接将被视为无效并断开。这个机制有助于节省设备的电源，并防止因设备长时间未通信而导致的资源占用。

3.2. LMP_SUPERVISION_TIMEOUT PDU

LMP（链路管理层协议，Link Manager Protocol）是蓝牙协议栈中的一层，负责处理链路层的连接管理。LMP_SUPERVISION_TIMEOUT PDU是LMP层用于更改链路监督超时值的一个协议数据单元。当一方设备希望更改连接的链路监督超时值时，它会发送这个PDU给另一方设备。

3.3. HCI_Link_Supervision_Timeout_Changed事件

HCI（主机控制器接口，Host Controller Interface）是蓝牙协议栈中用于主机和蓝牙控制器之间通信的接口。当外设接收到LMP_SUPERVISION_TIMEOUT PDU并成功更改了链路监督超时值时，它会通过HCI层向主机发送一个HCI_Link_Supervision_Timeout_Changed事件。这个事件通知主机链路监督超时值已经被更改，并可能包含新的超时值信息。

3.4. 工作流程

• 主机启用LSTO更改功能：主机通过HCI命令启用外设的LSTO更改功能。
• 外设接收LMP_SUPERVISION_TIMEOUT PDU：外设从连接的另一方接收到LMP_SUPERVISION_TIMEOUT PDU。
• 外设更改LSTO值：外设根据接收到的PDU更改其链路监督超时值。
• 生成HCI_Link_Supervision_Timeout_Changed事件：外设通过HCI层向主机发送一个HCI_Link_Supervision_Timeout_Changed事件，通知主机LSTO值已经被更改。
• 主机处理事件：主机接收到事件后，可以根据需要采取相应的操作，比如更新其内部状态或通知应用程序。

3.5. 注意事项

• 链路监督超时值的更改可能会影响蓝牙连接的稳定性和电源消耗。因此，在更改这个值时应该谨慎考虑。
• 不同的蓝牙设备和版本可能支持不同的LSTO值范围。在更改LSTO值之前，应该检查设备的规格和文档。
• HCI_Link_Supervision_Timeout_Changed事件是蓝牙协议栈中的一个高级特性，通常用于需要精细控制蓝牙连接行为的场景。在大多数普通应用中，可能不需要直接处理这个事件。

四、设置连接加密（Set Connection Encryption）

在蓝牙通信中，数据的安全性至关重要，尤其是涉及到一些个人隐私信息、敏感业务数据等的传输场景。通过设置连接加密及终止加密的操作流程，能够让蓝牙设备之间灵活地根据实际需求来保障数据安全。无论是开启加密以防止数据被窃取、篡改，还是在合适的情况下终止加密以减少不必要的资源消耗、提高传输效率等，都为蓝牙通信在不同应用场景下的数据安全管理提供了标准化、规范化的操作方式，确保蓝牙连接既能满足安全需求又能兼顾实际使用的便利性和效率。

4.1. 开启加密（发送HCI_Set_Connection_Encryption命令）

• 命令发起：主机可以随时使用HCI_Set_Connection_Encryption命令来开启蓝牙连接的加密。这个命令可以由Central（中心设备）或Peripheral（外围设备）任何一方发起。上面的图示中，只展示了Central发起命令的情况。
• 命令执行：当此命令由Central发送时，Central会向蓝牙控制器发送一个包含目标设备地址和加密模式的HCI_Set_Connection_Encryption命令。蓝牙控制器随后会处理这个命令，并准备与对应的外围设备进行加密通信。
• PDU 发送情况：
  • 不同发起方的区别：如果这个加密命令是由外围设备（Peripheral）发起的，和中心设备发起时唯一的区别在于，“LMP_ENCRYPTION_MODE_REQ PDU”将会由外围设备发送出去。这个协议数据单元主要用于向对方请求设置特定的加密模式，比如确定采用何种加密算法、加密的具体参数模式等相关信息，向外传达外围设备对于加密模式方面的期望和要求，以便对方知晓并进行相应的后续处理。
  • 固定的请求来源：而 “LMP_ENCRYPTION_KEY_SIZE_REQ”和 “LMP_START_ENCRYPTION_REQ”这两个协议数据单元则总是由中心设备（Central）来请求发送的。“LMP_ENCRYPTION_KEY_SIZE_REQ” 用于确定加密所使用的密钥的长度等尺寸相关信息，不同的安全级别、加密算法可能需要不同长度的密钥来保障安全性，中心设备通过请求这个 PDU 来明确密钥大小要求；“LMP_START_ENCRYPTION_REQ” 则是正式发起启动加密操作的请求，通知对方开始按照前面确定的加密模式、密钥尺寸等要求来实际启动加密流程，保障数据传输开始受到加密保护。

4.2. 终止加密（使用HCI_Set_Connection_Encryption命令）

• 命令发送：要终止加密的使用，同样可以使用HCI_Set_Connection_Encryption命令，但此时需要指定一个表示不加密的模式。这个命令通常需要从Central侧发起。
• 命令处理：蓝牙控制器接收到这个命令后，会停止当前的加密通信，并恢复到未加密的状态。

4.3. 注意事项

• 加密模式：在发送HCI_Set_Connection_Encryption命令时，需要指定加密模式。这个模式决定了蓝牙连接将使用哪种加密算法和密钥长度。
• 密钥管理：在加密过程中，密钥的管理是非常重要的。蓝牙设备通常使用预共享密钥或公钥加密等方式来确保密钥的安全性。
• 命令响应：当HCI_Set_Connection_Encryption命令被发送后，蓝牙控制器会返回一个命令完成事件来确认命令的执行结果。如果命令执行失败，事件中会包含错误代码和相关信息。

“Set Connection Encryption”过程涉及主机通过HCI命令来设置蓝牙连接的加密状态。这个过程包括发送加密命令、协商加密模式和密钥大小、启动加密以及（如果需要）终止加密等步骤。在加密过程中，需要特别注意密钥的管理和命令的响应情况。

五、更改连接链路密钥（Change connection link key ）

更改连接链路密钥在蓝牙通信安全管理方面有着重要意义。随着蓝牙技术应用场景日益广泛，涉及的数据敏感性不断提高，例如在传输个人健康数据（如智能穿戴设备与手机的连接）、金融支付信息（如支持蓝牙支付的设备与终端连接）等情况下，定期或者按需更改链路密钥可以增强对中间人攻击、密钥破解等安全威胁的防范能力。及时更新密钥能够让蓝牙连接持续保持较高的安全等级，确保数据在传输过程中的保密性、完整性以及设备间认证的可靠性，更好地保护用户的隐私和数据安全，提升用户对蓝牙设备及相关应用的信任度。

中央设备的主机（主机A）可以使用HCI_Change_Connection_Link_Key命令来更改连接链路密钥。系统会生成一个新的链路密钥，并且所有相关主机（这里涉及的通信双方主机，包括中心设备的 Host A 以及与之连接的其他设备对应的主机等）都会收到这个新链路密钥的通知。

在这个步骤中，中央设备（通常是蓝牙设备网络中的管理者或控制者）通过发送一个特定的命令给其蓝牙硬件接口（HCI），来请求更改与某个从设备（Slave）之间的连接链路密钥。这个命令触发了一个过程，该过程生成一个新的、随机的链路密钥，用于加密和解密两个设备之间的通信。

一旦新的链路密钥生成，中央设备会将其存储在自己的内存中，并且通常会通过某种形式的通信（可能是蓝牙本身，也可能是其他通信手段）将这个新密钥安全地发送给从设备。这样，两个设备就可以使用这个新的链路密钥来加密它们之间的后续通信，从而增强安全性。

此外，如果网络中有其他主机或设备需要知道这个新的链路密钥（例如，为了监控或管理目的），它们也会被相应地通知。这确保了网络中的所有相关方都能保持同步，并使用最新的安全密钥进行通信。

请注意，这个过程的具体实现可能会因不同的蓝牙设备和软件栈而有所不同，但基本概念和步骤是相似的。在实际应用中，更改链路密钥的操作可能需要管理员权限，并且应该谨慎进行，以避免破坏现有的通信链路或引入安全风险。

六、改变连接链路密钥并暂停和恢复加密（Change connection link key with encryption pause and resume）

在蓝牙通信中，连接链路密钥（link key）是保障连接安全的重要元素。当需要更新这个链路密钥时，为了确保数据加密的连贯性和安全性，采用了带有加密暂停和恢复的操作方式。这一操作的主要目的是在更新链路密钥的同时，避免数据在过渡阶段出现安全漏洞，并且能够顺利地切换到基于新链路密钥的加密机制。

6.1. 前提准备

• 设备支持：确保中央设备（Central）和外围设备（Peripheral）均支持加密暂停和恢复功能。
• 连接建立：设备间已经建立了蓝牙连接，并且处于活动状态。

6.2. 使用HCI_Change_Connection_Link_Key命令更改连接链路密钥

• 发起命令：Host A通过蓝牙主机控制器接口（HCI）发送HCI_Change_Connection_Link_Key命令。这个命令包含了要更改链路密钥的连接的句柄（Handle）以及新的链路密钥。

• 生成新链路密钥：一旦接收到这个命令，蓝牙硬件或控制器会生成一个新的链路密钥，并准备将其应用于指定的连接。

• 通知主机：蓝牙硬件或控制器会通知Host A和其他相关主机（如果有的话），新的链路密钥已经生成并准备好使用。

6.3. 加密暂停和恢复

• 加密暂停：在新链路密钥生成并通知主机后，会暂停当前的加密操作。这是因为在链路密钥更换期间，如果继续使用旧的加密方式，可能会导致数据加密和解密出现混乱，所以需要暂停加密，为后续的加密机制转换创造一个稳定的环境。

• 使用新链路密钥生成新加密密钥：一旦新的链路密钥准备就绪，蓝牙硬件会使用这个新密钥来生成一个新的加密密钥。这个过程通常涉及一些复杂的加密算法，以确保通信的安全性。

• 加密恢复：使用新生成的加密密钥，加密会话会被恢复。此时，所有的通信数据都会使用新的加密密钥进行加密，从而确保数据在更新链路密钥的情况下依然能够安全、准确地在设备之间传输，维持蓝牙连接的安全性和稳定性。

6.4. 后续操作

• 验证新密钥：设备间可能会进行一些额外的验证步骤，以确保新密钥已正确应用并正在使用。这些验证步骤可能包括发送和接收加密的数据包，并验证它们是否能够被正确解密。

• 更新密钥存储：中央设备和外围设备都会更新它们的密钥存储，以包含新的链路密钥和（如果适用）新的加密密钥。这确保了在未来通信中能够使用正确的密钥进行加密和解密。

• 继续通信：一旦密钥更改完成并验证无误，设备间就可以继续以加密的方式通信了。

6.5. 实际应用场景和重要性

• 应用场景：在许多对数据安全要求较高的蓝牙应用场景中，如移动支付设备与终端的连接、医疗设备与数据采集系统的连接等，这种操作方式非常重要。例如，在移动支付场景中，蓝牙连接可能会定期更新链路密钥以防止支付信息泄露，而加密暂停和恢复机制可以确保支付过程不受影响，数据始终处于安全加密状态。

• 重要性：这种操作方式增强了蓝牙连接的安全性，能够有效应对潜在的安全威胁，如密钥泄露或被破解。同时，加密暂停和恢复机制保证了数据传输的连续性和稳定性，避免了因密钥更新导致的数据传输中断或用户体验下降，对于维护蓝牙通信的安全性和可靠性至关重要。

6.6. 注意事项

• 在加密暂停和恢复的短暂期间，通信可能会暂时处于未加密状态，这可能会增加被截获的风险。因此，这个过程应该尽快完成。
• 更换链路密钥通常是在特定条件下进行的，例如当检测到潜在的安全威胁时，或者为了符合某些安全策略的要求。
• 在实际的应用中，蓝牙设备和主机通常会实现一套完整的安全机制，包括密钥管理、加密和认证等，以确保通信的安全性和可靠性。

通过这个过程，蓝牙设备可以在不中断通信的情况下，安全地更换连接链路密钥，从而提高通信的安全性。

七、临时链路密钥（Temporary Link Key）

在蓝牙通信的安全机制中，链路密钥（Link Key）起着至关重要的作用，它用于对设备间传输的数据进行加密等安全相关操作，保障通信内容不被未授权的第三方获取或篡改。这里涉及到两种链路密钥，分别是半永久链路密钥和临时性链路密钥，并且通过 HCI_Link_Key_Selection 命令来实现它们之间的切换操作，而这种切换操作是在特定条件下进行的，即当至少有一个设备不支持加密暂停与恢复（Encryption Pause and Resume）功能时，需要按照以下步骤来进行链路密钥的变更。

7.1. 步骤 1: 从半永久链路密钥切换到临时链路密钥

当蓝牙设备不支持加密暂停和恢复功能时，主机可以使用HCI_Link_Key_Selection命令将当前使用的链路密钥从半永久链路密钥更改为临时链路密钥。这个步骤通常是为了提高安全性，因为临时链路密钥的使用可以减少长时间使用同一密钥所带来的安全风险。

• 主机请求切换：Host A（作为中央设备）通过发送HCI_Link_Key_Selection命令来请求从半永久链路密钥切换到临时链路密钥。该命令包含指示要使用临时链路密钥的参数。
• HCI命令状态：Host A接收到HCI_Command_Status事件，确认HCI_Link_Key_Selection命令已被成功发送。
• LMP消息交换：
  • 接下来，Host A和Host B之间通过LMP消息进行一系列交互，以完成链路密钥的切换。
  • LMP_TEMP_RAND和LMP_TEMP_KEY消息可能用于生成和交换临时随机数（用于生成临时链路密钥）。
  • LMP_AU_RAND和LMP_SRES（认证随机数和短期响应）可能用于认证过程。
  • 这些消息的具体内容和格式可能因蓝牙规范版本而异。
• 加密重启：
  • 如果加密已经启用，则需要先关闭加密，然后再重新启用，以确保使用新的临时链路密钥进行加密。
  • 通过发送LMP_ENCRYPTION_MODE_REQ (off)消息来关闭加密。
  • 接收到LMP_ACCEPTED确认后，发送LMP_STOP_ENCRYPTION_REQ消息来停止加密。
  • 再次接收到LMP_ACCEPTED后，发送LMP_ENCRYPTION_MODE_REQ (on)消息来请求重新启用加密。
  • 然后，通过LMP_ENCRYPTION_KEY_SIZE_REQ和LMP_START_ENCRYPTION_REQ消息来设置加密密钥大小并启动加密。
• 链路密钥类型改变通知：最后，Host A和Host B都通过HCI_Link_Key_Type_Changed事件来通知上层应用程序链路密钥类型已经改变。

7.2. 步骤 2: 从临时链路密钥切换回半永久链路密钥

在某些情况下，主机可能需要将链路密钥从临时链路密钥切换回半永久链路密钥。可能是为了恢复与不支持临时链路密钥的设备的兼容性，或者是因为临时链路密钥的使用期限已到。

• 主机请求切换：Host A（作为中央设备）通过发送HCI_Link_Key_Selection命令来请求从临时链路密钥切换回半永久链路密钥。该命令包含指示要使用半永久链路密钥的参数。
• HCI命令状态：Host A接收到HCI_Command_Status事件，确认HCI_Link_Key_Selection命令已被成功发送。
• LMP消息交换：
  • 接下来，Host A和Host B之间通过LMP消息进行交互，以完成链路密钥的切换。
  • LMP_USE_SEMI_PERMANENT_KEY消息用于指示将使用半永久链路密钥。
  • Host B通过发送LMP_ACCEPTED消息来确认接受该请求。
• 加密重启：
  • 如果加密已经启用，则需要先关闭加密，然后再重新启用，以确保使用新的半永久链路密钥进行加密。
  • 通过发送LMP_ENCRYPTION_MODE_REQ (off)消息来关闭加密。
  • 接收到LMP_ACCEPTED确认后，发送LMP_STOP_ENCRYPTION_REQ消息来停止加密。
  • 再次接收到LMP_ACCEPTED后，发送LMP_ENCRYPTION_MODE_REQ (on)消息来请求重新启用加密。
  • 然后，通过LMP_ENCRYPTION_KEY_SIZE_REQ和LMP_START_ENCRYPTION_REQ消息来设置加密密钥大小并启动加密。
• 链路密钥类型改变通知：最后，Host A和Host B都通过HCI_Link_Key_Type_Changed事件来通知上层应用程序链路密钥类型已经改变。

7.3. 注意事项

• 安全性：使用临时链路密钥可以增强蓝牙通信的安全性，因为它减少了密钥被长时间破解或截获的风险。

• 兼容性：并非所有蓝牙设备都支持临时链路密钥。因此，在尝试使用此功能之前，请确保所有相关设备都兼容。

• 命令参数：HCI_Link_Key_Selection命令的确切参数和格式可能因蓝牙规范版本和特定实现而异。因此，请查阅相关蓝牙规范或设备文档以获取详细信息。

• 错误处理：如果命令执行失败（例如，由于设备不支持该功能或由于其他错误），主机应能够适当地处理错误并可能回退到使用半永久链路密钥或其他安全措施。

八、读取远程设备支持功能（HCI_Read_Remote_Supported_Features命令）

在蓝牙通信中，了解远程设备所支持的功能特性是非常重要的，有助于实现设备间更好的兼容性以及充分利用双方具备的各种功能来进行高效通信。通过使用 HCI_Read_Remote_Supported_Features 命令，就可以实现读取远程设备所支持的链路管理协议（LMP）相关功能的操作，以此来知晓远程设备在蓝牙通信方面能够支持哪些具体的能力，比如是否支持特定的加密模式、不同的连接类型或者某些高级的链路管理功能等。

8.1. 主机请求远程设备的支持特性（The Host requests the supported features of a remote device） 

主机作为发起方，希望获取与之通信的远程设备所支持的功能情况，这一请求的出发点是为了后续能够根据远程设备的能力来调整自身的通信策略、选择合适的连接方式、启用匹配的功能等，以实现与远程设备之间最优的通信效果。例如，如果主机知道远程设备支持某种高效的加密模式，那么它就可以在后续建立连接或者数据传输过程中优先选择使用该加密模式，既能保障通信安全又能提升通信效率；或者若得知远程设备支持特定的高级链路管理功能，主机就可以利用这些功能来更好地维护和管理通信链路。

• HCI命令发送：Host A通过发送HCI_Read_Remote_Supported_Features命令来请求Device B的支持特性。这个命令包含了Device B的蓝牙地址（BD_ADDR），以指定要查询的设备。
• HCI命令状态确认：Host A接收到HCI_Command_Status事件，确认HCI_Read_Remote_Supported_Features命令已经被成功发送并正在处理中。
• LMP消息交换：
  • 接下来，Host A的蓝牙控制器和Device B的蓝牙控制器之间通过LMP消息进行交互。
  • Host A的控制器发送LMP_FEATURES_REQ消息给Device B，请求其支持的特性。
  • Device B接收到请求后，通过LMP_FEATURES_RES消息返回其支持的特性给Host A。
• HCI事件返回：最后，Host A接收到HCI_Read_Remote_Supported_Features_Complete事件，该事件包含了Device B的支持特性。这个事件是由Host A的蓝牙控制器生成的，作为对HCI_Read_Remote_Supported_Features命令的响应。

8.2. 注意事项

• 安全性：在请求和接收远程设备支持特性的过程中，应该确保通信的安全性。例如，可以使用蓝牙的加密和认证机制来保护这些交换的数据。
• 缓存机制：为了提高效率，蓝牙控制器可能会实现缓存机制来存储之前获取过的远程设备支持特性。然而，在这个特定的步骤中，缓存机制不是必需的，因为每次请求都会触发新的LMP消息交换。
• 兼容性：不同的蓝牙设备可能支持不同的LMP特性。因此，在设计和实现蓝牙应用程序时，应该考虑到这一点，并确保应用程序能够处理不同设备的特性差异。

通过HCI_Read_Remote_Supported_Features命令和后续的LMP消息交换，Host A能够成功地获取到Device B的支持特性。这些信息对于后续的蓝牙通信配置和优化是非常重要的。

九、读取远程设备的扩展功能

在蓝牙通信体系中，除了常规的一些链路管理协议（LMP）功能外，还存在扩展功能，这些扩展功能能够进一步丰富和增强蓝牙设备间的通信能力与交互方式。通过使用 HCI_Read_Remote_Extended_Features 命令，主机（Host）便能够读取远程设备的扩展 LMP 功能，这有助于更全面地了解远程设备的能力情况，从而在后续建立连接、配置通信参数以及启用各类应用场景时，可以充分利用双方所具备的扩展功能，实现更高效、更优化的蓝牙通信。

与读取常规支持功能类似，这里也存在一种效率优化机制，即如果之前已经获取过远程设备的扩展功能信息，那么控制器（Controller）有可能直接返回这些已有信息，而无需再次发送链路管理协议数据单元（LMP PDUs）进行重新查询，以此节省通信资源和时间，提高操作效率。

9.1. 主机请求远程设备的扩展特性

使用HCI_Read_Remote_Extended_Features命令来读取远程设备的扩展特性的过程与读取标准LMP特性的过程类似，但专注于获取远程设备支持的更高级或额外的功能。

• HCI命令发送：Host A通过发送HCI_Read_Remote_Extended_Features命令来请求Device B的扩展特性。这个命令通常包含远程设备的蓝牙地址（BD_ADDR）和一个页面编号（Page Number），页面编号用于指定要读取的特性页（因为扩展特性可能分为多个页面存储）。
• HCI命令状态确认：Host A接收到HCI_Command_Status事件，确认HCI_Read_Remote_Extended_Features命令已经被成功发送并正在处理中。
• LMP消息交换：
  • 接下来，Host A的蓝牙控制器和Device B的蓝牙控制器之间通过LMP消息进行交互。
  • Host A的控制器发送LMP_FEATURES_REQ_EXT消息给Device B，请求其扩展特性。
  • Device B接收到请求后，通过LMP_FEATURES_RES_EXT消息返回其扩展特性给Host A。
• HCI事件返回：最后，Host A接收到HCI_Read_Remote_Extended_Features_Complete事件，该事件包含了Device B的扩展特性。这个事件是由Host A的蓝牙控制器生成的，作为对HCI_Read_Remote_Extended_Features命令的响应。

9.2. 注意事项

• 页面编号：由于扩展特性可能很多，可能被分成多个页面存储。在请求扩展特性时，需要指定页面编号来读取特定的页面。
• 安全性：在请求和接收远程设备扩展特性的过程中，应该确保通信的安全性。例如，可以使用蓝牙的加密和认证机制来保护这些交换的数据。
• 缓存机制：为了提高效率，蓝牙控制器可能会实现缓存机制来存储之前获取过的远程设备扩展特性。然而，在这个特定的步骤中，缓存机制不是必需的，因为每次请求都会触发新的LMP消息交换（除非控制器决定从缓存中返回数据）。
• 兼容性：不同的蓝牙设备可能支持不同的扩展LMP特性。因此，在设计和实现蓝牙应用程序时，应该考虑到这一点，并确保应用程序能够处理不同设备的特性差异。

通过HCI_Read_Remote_Extended_Features命令和后续的LMP消息交换，Host A能够成功地获取到Device B的扩展特性。这些信息对于了解远程设备的高级功能和优化蓝牙通信配置是非常重要的。

十、读取远程蓝牙设备的时钟偏移（Clock Offset）

在蓝牙通信的环境中，时钟信息起着重要作用，其中时钟偏移（Clock Offset）是一个关键要素。通过使用 HCI_Read_Clock_Offset 命令，扮演中央设备（Central）角色的设备能够读取外围设备（Peripheral）的时钟偏移值。获取这个时钟偏移值有很重要的实际用途，比如它可以被用来在后续的连接尝试中加快寻呼（paging）流程。寻呼流程通常涉及设备去搜索并建立与其他设备的连接，知晓时钟偏移能让中央设备更精准地把握时机，减少不必要的等待和搜索时间，从而更高效地与外围设备重新建立连接，优化整个蓝牙通信链路的连接效率。

10.1. 中央设备请求远程设备的时钟偏移

中央设备 发起这一请求，主要是出于对后续可能的连接操作进行优化的考虑。例如，当预计在不久后要与外围设备再次建立连接，或者处于一个频繁连接、断开又重连的通信场景中，提前获取外围设备的时钟偏移值，就能利用该信息在后续寻呼过程中节省时间，提高连接效率，所以会启动对时钟偏移值的读取流程。

• HCI命令发送：中央设备（Host A）通过发送HCI_Read_Clock_Offset命令来请求外围设备（Device B，或称为Host B的蓝牙模块）的时钟偏移。这个命令包含了外围设备的蓝牙地址（BD_ADDR）和连接句柄（Connection Handle），以指定要查询的设备和当前的连接。
• HCI命令状态确认：中央设备接收到HCI_Command_Status事件，确认HCI_Read_Clock_Offset命令已经被成功发送并正在处理中。
• LMP消息交换：
  • 接下来，中央设备和外围设备之间通过LMP消息进行交互。
  • 中央设备的控制器发送LMP_CLKOFFSET_REQ消息给外围设备，请求其时钟偏移。
  • 外围设备接收到请求后，通过LMP_CLKOFFSET_RES消息返回其时钟偏移给中央设备。
• HCI事件返回：最后，中央设备接收到HCI_Read_Clock_Offset_Complete事件，该事件包含了外围设备的时钟偏移。这个事件是由中央设备的蓝牙控制器生成的，作为对HCI_Read_Clock_Offset命令的响应。

10.2. 特殊情况（外围设备请求时钟偏移）

外围设备 发起这一请求可能也是出于自身对于时间同步或者优化后续与中央设备连接等方面的需求。比如，外围设备希望自身能更好地与中央设备的时钟进行同步，以便在后续的数据传输等操作中能更精准地配合，或者同样是为了在后续可能的连接场景中利用时钟偏移信息来提升连接效率等，所以启动对中央设备时钟偏移值的读取流程。

外围设备（通过 Host A 发起操作）向中央设备（通过 Host B 关联的对应设备）请求读取时钟偏移值的情况，与中央设备发起请求有所不同，其交互过程相对更简洁一些。 

• 外围设备发送HCI_Read_Clock_Offset命令。
• 控制器直接返回HCI_Command_Status事件和HCI_Read_Clock_Offset_Complete事件，而不发送任何LMP PDUs（协议数据单元）。
• 在这种情况下，由于外围设备通常不会主动发起分页操作，因此它不需要知道中央设备的时钟偏移。这个命令的响应可能是为了符合某种特定的协议要求或调试目的。

10.3. 注意事项

• 时钟偏移的作用：时钟偏移信息可以帮助中央设备在后续的连接尝试中更快地找到外围设备。这是因为蓝牙设备的时钟可能会因为各种原因（如晶体振荡器的微小差异）而略有不同。
• 安全性：在请求和接收时钟偏移的过程中，应该确保通信的安全性。例如，可以使用蓝牙的加密和认证机制来保护这些交换的数据。
• 兼容性：不同的蓝牙设备可能支持不同的时钟偏移读取方式。因此，在设计和实现蓝牙应用程序时，应该考虑到这一点，并确保应用程序能够处理不同设备的差异。

通过HCI_Read_Clock_Offset命令和后续的LMP消息交换（或由控制器直接返回的事件），中央设备能够成功地获取到外围设备的时钟偏移。这些信息对于优化蓝牙连接建立过程和提高通信效率是非常重要的。

十一、在加密链路上使用加密暂停和恢复进行角色切换

在蓝牙通信中，设备之间的角色划分（如中央设备 Central 和外围设备 Peripheral）对于通信的组织和管理起着关键作用。有时候，在已经建立加密链路的情况下，出于各种需求（例如优化通信效率、改变通信模式或者适应不同应用场景等），需要对设备的角色进行切换。HCI_Switch_Role命令可用于明确地将本地设备与指定设备之间的当前中央设备（Central）/外围设备（Peripheral）角色进行切换。中央设备的主机（A）向一个外围设备请求角色切换。这个过程首先会暂停加密，然后发送切换请求，外围设备将以槽偏移量和接受响应作为回应。角色切换是通过进行时分双工（TDD）切换和微微网（piconet）切换来完成的。

在角色切换过程中，当加密被暂停后，一旦角色切换完成，加密也会被恢复。最终，在双方都会发送一个HCI_Role_Change事件，以通知主机设备角色已经成功切换。

• 初始状态：Host A通过LM­A（链路管理层A）作为中央设备（Central）与LM­B（链路管理层B）作为外围设备（Peripheral）的Host B进行通信。
• 角色切换请求：Host A发送HCI_Switch_Role命令来请求与Host B进行角色切换。
• 加密暂停：LM­A和LM­B分别发送LMP_PAUSE_ENCRYPTION_REQ请求来暂停加密。注意：在实际操作中，可能只会发送一个暂停加密的请求，然后由接收方确认并执行，但图中为了清晰展示了双方都发送了请求。
• 加密停止：LM­A发送LMP_STOP_ENCRYPTION_REQ来完全停止加密。
• 角色切换准备：LM­B发送LMP_ACCEPTED表示接受暂停加密请求。
• 角色切换请求：加密暂停后，LM-A发送LMP_SWITCH_REQ消息给LM-B来请求角色切换。LM-B在接收到切换请求后，计算所需的槽偏移量（LMP_SLOT_OFFSET），并通过LMP_ACCEPTED消息确认接受切换请求。
• 角色切换发生：LM­A和LM­B分别更新它们的角色，LM­A变为外围设备，LM­B变为中央设备。
• 加密恢复：LM­A和LM­B分别发送LMP_RESUME_ENCRYPTION_REQ和LMP_START_ENCRYPTION_REQ来恢复加密。注意：这里使用了“恢复”和“开始”两个术语，但实际上它们都是指重新建立加密连接。在某些实现中，可能只需要一个请求来指示加密的重新建立。
• 加密密钥刷新：双方都会发送HCI_Encryption_Key_Refresh_Complete事件来表示加密密钥刷新已完成。这是加密恢复过程的一部分，确保新的加密密钥被正确应用。
• 角色切换事件：最后，Host A和Host B分别接收HCI_Role_Change事件，通知它们角色已经成功切换。

通过这个过程，中央设备和外围设备可以在保持通信连续性的同时，灵活地切换它们的角色。这对于动态变化的蓝牙网络环境来说是非常重要的，因为它允许设备根据当前的需求和资源状况来优化它们的通信行为。

十二、加密密钥刷新（Refreshing encryption keys ）

在蓝牙通信的安全保障机制中，加密密钥（encryption key）起着核心作用，它决定了数据在传输过程中的加密方式以及安全性程度。随着通信的持续进行、设备所处环境的变化或者基于一定的安全策略要求，需要定期对加密密钥进行更新（刷新），以维持较高的安全性水平，防止因密钥长时间使用可能导致的安全漏洞被利用等情况。“HCI_Refresh_Encryption_Key” 命令就是供中央设备的主机（Central's Host）使用的一个工具，通过它可以显式地暂停和恢复加密过程，进而实现加密密钥的刷新操作。在完成加密恢复后，两端设备会发送 “HCI_Encryption_Key_Refresh_Complete” 事件来告知整个通信链路加密密钥刷新工作已经完成，同时，当参与通信的双方设备都支持安全连接（Secure Connections）时，加密密钥刷新流程会遵循特定的顺序开展。

• 加密密钥刷新请求：
  • Host A（作为中央设备）的主机通过发送HCI_Refresh_Encryption_Key命令来请求刷新与Host B（作为外围设备）之间的加密密钥。
  • 这个命令是可选的，意味着在某些情况下，加密密钥的刷新可能是由其他机制触发的（例如，定时器到期或安全策略要求）。
• 加密暂停：
  • 在接收到刷新密钥的请求后，LM-A发送LMP_PAUSE_ENCRYPTION_REQ消息给LM-B，请求暂停加密。
  • LM-B接收到请求后，也会发送一个相同的LMP_PAUSE_ENCRYPTION_REQ消息给LM-A（尽管在实际协议中，这可能是一个单独的确认消息，但为简化流程，这里用相同的消息表示）。
  • 随后，LM-A会发送LMP_STOP_ENCRYPTION_REQ消息来明确表示加密已被暂停。
• 加密恢复与密钥刷新：
  • 在加密暂停后，LM-A会准备新的加密密钥，并发送LMP_START_ENCRYPTION_REQ消息给LM-B，请求恢复加密并同时使用新密钥。
  • LM-B接收到请求后，确认接受新密钥，并通过LMP_ACCEPTED消息进行确认。
  • 此时，加密恢复，双方开始使用新的加密密钥进行通信。
• 密钥刷新完成通知：
  • 加密恢复并成功切换到新密钥后，Host A和Host B都会收到HCI_Encryption_Key_Refresh_Complete事件通知。
  • 这个事件表明加密密钥刷新过程已完成，双方都已成功切换到新密钥。

通过这个流程，两个蓝牙设备可以在不中断通信的情况下，安全地它们的刷新加密密钥。这对于需要长期保持安全通信的蓝牙应用场景来说是非常重要的。 

当两个蓝牙设备都支持Secure Connections时，刷新加密密钥使用AES-CCM（高级加密标准计数器模式）作为加密算法。AES-CCM是一种结合了认证和加密的模式，广泛应用于蓝牙等无线通信协议中。

• 加密密钥刷新请求：
  • Host A（作为中央设备）的主机通过发送HCI_Refresh_Encryption_Key命令来请求刷新与Host B（作为外围设备）之间的加密密钥。
  • 这个命令表明Host A希望使用AES-CCM加密算法来刷新密钥。
• 加密暂停：
  • 在接收到刷新密钥的请求后，LM-A发送LMP_PAUSE_ENCRYPTION_AES_REQ消息（这里特别指出了AES，以区别于其他可能的加密算法）给LM-B，请求暂停当前使用AES-CCM加密的通信。
  • LM-B接收到请求后，也会发送一个LMP_PAUSE_ENCRYPTION_REQ消息（尽管这里未特别指出AES，但在上下文中应理解为使用相同的加密算法）给LM-A，作为对暂停请求的确认。
  • 随后，LM-A会发送LMP_STOP_ENCRYPTION_REQ消息来明确表示加密已被暂停。
• 准备新密钥并恢复加密：
  • 在加密暂停后，LM-A和LM-B都会根据它们各自的长期密钥（LTK）和当前的随机数（如计数器值或时间戳）生成一个新的短期密钥（STK）或临时密钥（TK），这个新密钥将用于后续的AES-CCM加密过程。
  • LM-A会发送LMP_START_ENCRYPTION_REQ消息给LM-B，请求恢复加密并同时使用新密钥。这个请求中包含了新密钥的相关信息，以便LM-B能够验证并接受新密钥。
  • LM-B接收到请求后，验证新密钥的有效性，并通过LMP_ACCEPTED消息进行确认。
• 密钥刷新完成通知：
  • 加密恢复并成功切换到新密钥后，Host A和Host B都会通过接收HCI_Encryption_Key_Refresh_Complete事件通知来确认加密密钥刷新过程的完成。
  • 这个事件表明双方都已成功切换到新密钥，并准备好使用AES-CCM算法进行安全的数据传输。
• 注意事项：
  • AES-CCM算法提供了强大的加密和认证功能，能够抵御多种攻击，是蓝牙Secure Connections的重要组成部分。
  • 如果设备之间的信任关系被破坏，则可能需要重新进行配对过程，而不仅仅是刷新加密密钥。重新配对将生成新的长期密钥（LTK），并可能涉及其他安全参数的更新。

通过这个流程，两个支持Secure Connections的蓝牙设备可以在保持通信连续性的同时，安全地刷新它们的加密密钥。这对于维护长期安全通信至关重要。

十三、读取远程版本信息（Read remote version information ）

在蓝牙通信环境中，了解与之通信的远程设备（remote device）的版本信息是很有必要的，这有助于判断设备间的兼容性、确认对方设备所具备的功能特性以及为后续的通信交互提供合适的配置依据等。通过 “HCI_Read_Remote_Version_Information” 命令，本地设备就能够读取远程设备的版本信息。

• 请求远程版本信息：
  • Host A（作为请求方）的主机发送HCI_Read_Remote_Version_Information命令给其控制器（LM-A），请求读取Host B（作为远程设备）的版本信息。
  • 这个命令包含了远程设备的蓝牙地址，以便控制器能够识别并请求正确的设备信息。
• 命令状态确认：LM-A接收到命令后，会向Host A发送一个HCI_Command_Status事件，确认命令已被接收并正在处理。
• 发送LMP版本请求：
  • 如果LM-A尚未拥有Host B的版本信息，它会通过链路管理层发送LMP_VERSION_REQ消息给LM-B（Host B的控制器）。
  • 这个请求包含了LM-A自己的版本信息，以便LM-B在响应时能够考虑到兼容性。
• 接收LMP版本响应：
  • LM-B接收到LMP_VERSION_REQ消息后，会检查自己的版本信息，并发送LMP_VERSION_RES消息作为响应。
  • 这个响应包含了LM-B的版本信息，如LMP版本、制造商名称、子版本等。
• 完成远程版本信息读取：
  • LM-A接收到LMP_VERSION_RES消息后，会将远程版本信息传递给Host A。
  • 然后，Host A会收到一个HCI_Read_Remote_Version_Information_Complete事件，这个事件包含了远程设备的完整版本信息。
• 缓存和重用：如果Host A之前已经获取过Host B的版本信息，并且这些信息仍然有效，那么LM-A可能会直接返回这些缓存的信息给Host A，而不是重新发送LMP PDU（协议数据单元）。
• 注意事项：
  • 版本信息的读取是蓝牙设备间建立连接和进行后续通信时的一个重要步骤，它有助于设备了解彼此的兼容性和功能。
  • 在某些情况下，如果设备已经缓存了远程设备的版本信息，并且这些信息在一段时间内没有变化，那么可以跳过重新读取的步骤，以节省资源和时间。
  • 如果设备间的连接被断开或重新建立，那么可能需要重新读取远程设备的版本信息，以确保信息的准确性和时效性。

通过这个流程，Host A能够安全地获取Host B的蓝牙版本信息，这对于后续的通信和兼容性检查至关重要。

十四、QoS设置（QoS setup ）

在蓝牙通信中，服务质量（Quality of Service，QoS）参数的设定与通知是保障通信能够按照期望的性能和质量标准进行的重要环节。

上图展示了如何使用HCI_Flow_Specification命令来设置蓝牙连接的服务质量（QoS）和流规范。这个过程涉及到了主机控制器接口（HCI）和链路管理层（LMP）之间的消息交换，以确保数据传输的质量和效率。

• 发送QoS参数：Host A（作为中央设备）的主机发送HCI_Flow_Specification命令给其控制器（LM-A），通知LM-A关于期望的QoS参数和流规范。这些参数可能包括服务类型、令牌速率、最大传输单元（MTU）大小、服务数据单元（SDU）间隔等。
• 命令状态确认：LM-A接收到命令后，会向Host A发送一个HCI_Command_Status事件，确认命令已被接收并正在处理。
• 传输QoS设置完成：如果LM-A能够成功应用这些QoS参数，它会向Host A发送一个HCI_Flow_Specification_Complete事件（针对Tx方向），表明传输方向的QoS设置已完成。
• 接收QoS参数：
  • 接下来，Host A可能会发送另一个HCI_Flow_Specification命令给LM-A，这次是通知关于接收（Rx）方向的QoS参数。
  • 同样，LM-A会确认命令状态，并在成功应用参数后发送一个HCI_Flow_Specification_Complete事件（针对Rx方向）。
• LMP QoS请求：
  • 在确定了本端的QoS参数后，LM-A会通过链路管理层发送LMP_QUALITY_OF_SERVICE_REQ消息给LM-B（作为外围设备的控制器），请求与远程设备建立相应的QoS。
  • 这个请求包含了LM-A期望的QoS参数和流规范。
• LMP QoS接受：
  • LM-B接收到请求后，会检查请求的QoS参数是否可接受，并根据自身能力和远程设备的配置来决定是否接受这些参数。
  • 如果接受，LM-B会发送LMP_ACCEPTED消息作为响应。
• 接收QoS设置完成：Host A和Host B都会通过接收HCI_Flow_Specification_Complete事件来确认接收方向的QoS设置也已完成。
• 注意事项：
  • QoS设置是蓝牙设备间确保数据传输质量和效率的重要手段，特别是在需要处理大量数据或实时通信的应用中。
  • QoS参数的选择应该基于设备的实际能力和应用的需求，以确保设置的合理性和有效性。
  • 如果设备间的连接被断开或重新建立，那么可能需要重新进行QoS设置，以确保数据传输的质量。

通过这个流程，Host A能够与其远程设备（Host B）建立和维护所需的QoS和流规范，从而确保数据传输的可靠性和效率。

十五、角色切换（Switch role）

在蓝牙通信中，设备可以扮演中心设备（Central）或外围设备（Peripheral）的角色。中心设备通常是发起连接请求的设备，而外围设备则是响应这些请求的设备。然而，在某些情况下，可能需要更改这些角色，这就是HCI_Switch_Role命令的用武之地。HCI_Switch_Role 命令可用于明确地将本地设备与指定设备之间的当前中心设备（Central）/外围设备（Peripheral）角色进行切换。

15.1. 请求角色切换

15.1.1. 中心设备的主机请求角色切换

中心设备的主机发送角色切换请求，外围设备将使用槽偏移量和接受状态进行响应。

• HCI_Switch_Role：从Host A发送到LM-A的指令，请求与外围设备B进行角色切换。
• HCI_Command_Status：LM-A向Host A发送的响应，表示HCI_Switch_Role命令已被接收并正在处理。
• LMP_SWITCH_REQ：LM-A通过蓝牙空中接口发送到LM-B的消息，请求进行角色切换。
• LMP_SLOT_OFFSET：LM-B响应LMP_SWITCH_REQ的消息，包含一个槽偏移量（slot offset），为了同步两个设备之间的通信而计算的。
• LMP_ACCEPTED：LM-B发送回LM-A的消息，表示它已接受角色切换的请求。

一旦LMP_ACCEPTED消息被发送，两个设备就达成了进行角色切换的协议。接下来，它们将执行实际的角色切换过程，可能包括调整通信参数、重新分配微微网成员关系等。最后，两个设备都会向它们各自的主机发送一个HCI_Role_Change事件，通知角色已经成功切换。

15.1.2. 外围设备的主机请求角色切换

外围设备的主机发送槽偏移量和角色切换请求，中心设备将使用 LMP_ACCEPTED 协议数据单元（PDU）进行响应。

• HCI_Switch_Role：从Host B发送到LM-B的指令，请求与中心设备进行角色切换。
• HCI_Command_Status：LM-B向Host B发送的响应，表示HCI_Switch_Role命令已被接收并正在处理。
• LMP_SLOT_OFFSET 和 LMP_SWITCH_REQ：当请求消息传递到链路层进行实际发送时，在外围设备的链路管理协议层面，会将角色切换请求以及槽位偏移信息一起以 LMP_SLOT_OFFSET 和 LMP_SWITCH_REQ 这两个消息格式发送给中心设备。LMP协议规定了这样的消息格式用于在链路间传递角色切换相关的关键信息，其中 LMP_SWITCH_REQ 明确表明了是角色切换请求，而 LMP_SLOT_OFFSET 所携带的槽位偏移信息对于后续双方在角色切换后进行时分双工（TDD）通信机制调整等方面有着重要作用，有助于协调通信时间片分配等操作。
• LMP_ACCEPTED：中心设备（LM-A）发送回外围设备（LM-B）的消息，表示它已接受角色切换的请求。

一旦LMP_ACCEPTED消息被发送，两个设备就达成了进行角色切换的协议。接下来，它们将执行实际的角色切换过程，可能包括调整通信参数、重新分配微微网成员关系等。最后，两个设备都会向它们各自的主机发送一个HCI_Role_Change事件，通知角色已经成功切换。这个事件标志着角色切换过程的完成。

15.2. 执行角色切换

通过执行时分双工（TDD）切换和微微网（piconet）切换来完成角色切换。最后，双方都会发送一个 HCI_Role_Change 事件。

• 角色切换的执行：在这一步中，中心设备（Central）和外围设备（Peripheral）将它们的角色互换。意味着原本作为中心设备的设备将转变为外围设备，而原本作为外围设备的设备将转变为中心设备。
• TDD（时分双工）切换：TDD是一种通信模式，其中上行链路（从外围设备到中心设备）和下行链路（从中心设备到外围设备）使用相同的频率，但在不同的时间间隔内传输。在角色切换过程中，TDD模式可能需要调整，以确保新的中心设备和外围设备能够正确地发送和接收数据。TDD切换可能涉及调整时间间隔的分配，以适应新的角色关系。
• 微微网（Piconet）切换：微微网是由一个主设备（在角色切换之前是中心设备）和最多七个从设备（在角色切换之前可能是外围设备）组成的蓝牙网络。在角色切换过程中，微微网的成员关系可能会发生变化。Piconet切换可能涉及重新分配微微网中的成员关系，以确保新的中心设备能够有效地管理微微网中的设备。
• HCI_Role_Change事件：一旦角色切换完成，两个设备都会向它们各自的主机发送一个HCI_Role_Change事件。这个事件通知主机设备已经成功切换了角色。
  • 对于外围设备（现在转变为新的中心设备）来说，它会发送一个HCI_Role_Change（Peripheral -> Master）事件。
  • 对于中心设备（现在转变为新的外围设备）来说，它会发送一个HCI_Role_Change（Master -> Peripheral）事件。

 注：

• LMP（Link Manager Protocol）是蓝牙协议栈中的链路管理层协议，用于管理蓝牙设备之间的链路。
• PDU（Protocol Data Unit）是协议数据单元，是网络中交换与传输的数据单元。
• TDD（Time Division Duplexing）是时分双工，是一种通信系统的传输技术，它允许信号在单个载波上，既发送也接收，但发送和接收是在不同的时隙上进行的。
• piconet是蓝牙网络的基本单元，由一台主设备（Master）和最多七台从设备（Slave）组成。

十六、时隙可用性掩码（Slot Availability Mask, SAM）

16.1. SAM设置的触发

槽位可用性掩码（SAM）的设置可以由链路管理器（Link Manager）发起，其触发目的主要是为了实现多无线系统（MWS）共存或者进行拓扑管理。例如，在一个设备同时存在蓝牙连接以及其他无线通信连接（如 Wi-Fi 等）的场景下，为了让这些不同的无线系统能够和谐共处、避免相互干扰并且合理利用通信资源，就需要通过设置 SAM 来调整蓝牙通信中的槽位可用性情况，从而协调各无线系统间的通信时间分配等。同样，在对蓝牙网络自身的拓扑结构（比如微微网中设备连接关系、主从角色分布等情况）进行管理和优化时，也可能需要通过 SAM 设置来调整通信资源的分配方式。

除了链路管理器主动发起外，SAM 的设置还可以通过HC命令来触发，具体的触发方式和相关命令交互参考下图 。

设备A通过HCI发送一系列命令来配置MWS传输层、信号、外部帧配置和MWS模式配置。

• HCI_Set_MWS_Transport_Layer：用于设置MWS传输层的参数，如传输速率、数据格式等。
• HCI_Command_Complete：当HCI_Set_MWS_Transport_Layer命令成功执行后，Host A会收到一个HCI_Command_Complete事件，表示该命令已完成。
• HCI_Set_MWS_Signaling：用于配置MWS信号参数，如信号类型、信号周期等。
• HCI_Command_Complete：同样，当HCI_Set_MWS_Signaling命令成功执行后，Host A会收到一个HCI_Command_Complete事件。
• HCI_Set_External_Frame_Configuration：用于设置外部帧的配置参数，如帧长度、帧周期等。这些参数对于同步MWS设备和优化通信性能至关重要。
• HCI_Command_Complete：当HCI_Set_External_Frame_Configuration命令成功执行后，Host A会收到一个HCI_Command_Complete事件。
• HCI_Set_MWS_PATTERN_Configuration：用于配置MWS模式参数，这些参数定义了MWS设备在何时可以通信以及通信的持续时间。这对于避免与其他无线系统的干扰至关重要。
• HCI_Command_Complete：当HCI_Set_MWS_PATTERN_Configuration命令成功执行后，Host  A会收到最后一个HCI_Command_Complete事件。
• PCA（性能校准和验证）执行：在所有HCI命令成功执行并完成配置后，设备A可能会执行性能校准和验证（PCA）过程。这是为了确保新的配置能够正常工作，并且满足预期的通信性能和共存要求。

通过实时信号触发（来自共存逻辑接口）：另外，来自共存逻辑接口（Coexistence Logical Interface）的实时信号，比如 MWS_PATTERN_Index（多无线系统模式索引，可能用于标识不同的多无线系统共存模式）、FRAME_SYNC（帧同步信号，用于协调不同无线系统间的帧同步情况等）等信号，也能够触发 SAM 的设置。这些实时信号可以为设备提供当前多无线系统运行环境下的实时状态信息，根据这些信息设备可以动态地调整 SAM，以更好地适应无线通信环境的变化。

16.2. SAM配置的设置和启用

在这一步中，设备A的链路管理器负责将SAM的配置发送给设备B。之后，设备A会选择一个SAM映射，这个映射定义了哪些时隙是可用的，哪些是不可用的。这个选择是基于当前的通信需求、MWS共存的要求以及可能的微微网时钟调整。

• LM A 决定启用SAM：设备A的链路管理器（LM­A）决定启用SAM功能，以优化通信效率和避免与其他无线系统的干扰。
• 发送 LMP_SAM_SET_TYPE0 命令：LM­A 向设备B发送 LMP_SAM_SET_TYPE0 命令，该命令用于设置SAM的类型。
• 接收 LMP_ACCEPTED_EXT 响应：设备B的链路管理器（LM­B）接收到 LMP_SAM_SET_TYPE0 命令后，如果接受该命令，则发送 LMP_ACCEPTED_EXT 响应给 LM­A。
• 发送 LMP_SAM_DEFINE_MAP 命令：LM­A 接收到 LMP_ACCEPTED_EXT 响应后，发送 LMP_SAM_DEFINE_MAP 命令给设备B。该命令用于定义SAM映射，即哪些时隙是可用的，哪些是不可用的。
• 再次接收 LMP_ACCEPTED_EXT 响应：LM­B 接收到 LMP_SAM_DEFINE_MAP 命令后，如果接受该命令并成功定义了SAM映射，则再次发送 LMP_ACCEPTED_EXT 响应给 LM­A。
• 发送 LMP_SAM_SWITCH 命令：LM­A 接收到第二个 LMP_ACCEPTED_EXT 响应后，发送 LMP_SAM_SWITCH 命令给设备B。该命令用于通知设备B切换到新的SAM配置。
• 最终接收 LMP_ACCEPTED_EXT 响应：LM­B 接收到 LMP_SAM_SWITCH 命令后，如果成功切换到新的SAM配置，则发送最终的 LMP_ACCEPTED_EXT 响应给 LM­A。
• 发送 HCI_SAM_Status_Change 事件：LM­A 在成功完成SAM配置和切换后，可能会向主机A发送 HCI_SAM_Status_Change 事件，通知主机A SAM状态已经改变。
• 设备B也可能发送 HCI_SAM_Status_Change 事件：同样地，设备B的链路管理器（LM­B）也可能向主机B发送 HCI_SAM_Status_Change 事件，以通知主机B SAM配置已经成功应用。

16.3. SAM配置更改

SAM配置保证通信双方能顺利更新槽位使用规则，适应新的通信需求。

• 接收新配置（可选）：Host A可能通过HCI接口接收到一个新的MWS模式配置。这个新配置可能包含了关于时隙可用性、信号周期等的新信息。如果这一步是可选的，那么设备A也可能通过其他方式获取新配置。
• 发送 HCI_Set_MWS_PATTERN_Configuration 命令：如果设备A通过HCI接收到了新配置，并且这个新配置需要应用到SAM上，那么设备A会发送一个 HCI_Set_MWS_PATTERN_Configuration 命令来设置新的MWS模式配置。
• 接收 HCI_Command_Complete 响应：当 HCI_Set_MWS_PATTERN_Configuration 命令成功执行后，LM-A会收到一个 HCI_Command_Complete 响应，表示该命令已完成。
• LM A 决定添加一个新的SAM时隙映射：根据新的MWS模式配置，设备A的链路管理器（LM A）决定添加一个新的SAM时隙映射。这个新的时隙映射将反映新的MWS模式配置中的时隙可用性。
• 发送 LMP_SAM_DEFINE_MAP 命令：LM A 发送一个 LMP_SAM_DEFINE_MAP 命令给设备B，该命令包含了新的SAM时隙映射的信息（通过新的SAM_Index标识）。
• 接收 LMP_ACCEPTED_EXT 响应：设备B的链路管理器（LM B）接收到 LMP_SAM_DEFINE_MAP 命令后，如果接受该命令并成功定义了新的SAM时隙映射，则发送 LMP_ACCEPTED_EXT 响应给 LM A。
• LM A 决定切换到新的时隙映射：在确认设备B已经成功定义了新的SAM时隙映射后，LM A 决定切换到这个新的时隙映射。
• 发送 LMP_SAM_SWITCH 命令：LM A 发送一个 LMP_SAM_SWITCH 命令给设备B，该命令包含了要切换到的新的SAM时隙映射的索引（新的SAM_Index）。
• 再次接收 LMP_ACCEPTED_EXT 响应：LM B 接收到 LMP_SAM_SWITCH 命令后，如果成功切换到新的SAM时隙映射，则发送 LMP_ACCEPTED_EXT 响应给 LM A。
• 发送 HCI_SAM_Status_Change 事件（新的本地SAM索引）：LM A 在成功切换到新的SAM时隙映射后，可能会向主机A发送一个 HCI_SAM_Status_Change 事件，通知主机A本地的SAM状态已经改变（通过新的Local_SAM_Index标识）。
• 设备B也可能发送 HCI_SAM_Status_Change 事件（新的远程SAM索引）：同样地，设备B的链路管理器（LM B）也可能向主机B发送一个 HCI_SAM_Status_Change 事件，以通知主机B远程设备（即设备A）的SAM状态已经改变（通过新的Remote_SAM_Index标识）。但请注意，在实际应用中，设备B通常不需要通知主机B关于远程设备SAM状态的变化，除非这是特定应用或协议的要求。

这些步骤共同确保了设备A和设备B能够正确地应用新的SAM配置，以实现优化的通信性能和避免干扰。

十七、LMP事务冲突

在蓝牙通信中，中心设备（Central）和外围设备（Peripheral）的链路管理器（Link Manager）有可能会同时发起相同的链路管理协议（LMP，Link Manager Protocol）事务，进而产生冲突的情况。这里以请求嗅探模式（Sniff Mode）为例，展示从主机发起请求到链路层处理以及最终结果反馈的整个流程，说明事务冲突时的表现及相应处理结果。

17.1. 主机A和主机B同时请求Sniff模式

• 发送HCI_Sniff_Mode命令：主机A（Host A）和主机B（Host B）几乎同时向它们各自的控制器（中央设备和外围设备）发送HCI_Sniff_Mode命令。这个命令的目的是请求设备进入Sniff模式。
• 接收HCI_Command_Status响应：控制器接收到HCI_Sniff_Mode命令后，会发送一个HCI_Command_Status响应给主机，表示命令已经被接收并正在处理。然而，在这个特定的场景中，由于两个控制器几乎同时接收到相同的命令，它们可能会同时尝试发起相同的LMP事务（即LMP_SNIFF_REQ）。

17.2. LMP事务冲突

• 发送LMP_SNIFF_REQ事务：中央设备和外围设备的链路管理器（LM A和LM B）几乎同时尝试发送LMP_SNIFF_REQ事务。这个事务包含了进入Sniff模式所需的参数，如sniff间隔、sniff窗口等。
• 接收LMP_NOT_ACCEPTED响应（LMP错误：事务冲突）：由于两个设备几乎同时尝试发起相同的LMP事务，它们会检测到事务冲突。在这种情况下，一个（或两个）设备会发送LMP_NOT_ACCEPTED响应，并包含LMP错误代码“事务冲突”。这表示由于冲突，LMP_SNIFF_REQ事务没有被接受。

17.3. 处理冲突

• 可能的重试机制：在接收到LMP_NOT_ACCEPTED响应后，主机可能会决定重试发送HCI_Sniff_Mode命令。然而，为了避免再次冲突，它可能需要实现某种退避算法或等待一段时间后再重试。
• 成功进入Sniff模式：如果冲突被解决，并且一个设备成功地发送了LMP_SNIFF_REQ事务并被另一个设备接受（通过发送LMP_ACCEPTED响应），则两个设备将进入Sniff模式。
• 发送HCI_Mode_Change事件：一旦设备成功进入Sniff模式，它们的链路管理器会向各自的主机发送HCI_Mode_Change事件，通知主机连接模式已经改变。然而，在图示中，由于之前的事务冲突，第一个HCI_Mode_Change事件（标记为“LMP错误：事务冲突”）表示由于冲突而未能成功进入Sniff模式。而后续的HCI_Mode_Change（sniff）事件则表示设备最终成功进入了Sniff模式。

当两个设备的链路管理器几乎同时尝试发起相同的LMP事务时可能发生的冲突情况。这种冲突可能导致事务被拒绝，并需要实现适当的冲突解决机制来确保设备能够成功地进入所需的连接模式。