在蓝牙 LE GATT 中，有没有办法检测长期密钥何时无效？

Question

我正在使用 Windows 蓝牙 LE GATT 库连接和配对支持 BLE 的设备 D。由于 D 的存储空间有限，如果与它绑定的客户端超过 N 个，那么它将删除第一个在绑定期间创建的长期密钥对。

假设删除此密钥对的设备是启用 Windows 的机器。我们称之为W。下次W尝试与D连接时，当它接收到来自W的LTK_Request_Event时，它以Long_Term_Key_Requested_Negative_Reply响应，W终止连接。

但这就是事情变得真正令人恼火的地方。尽管 Windows BLE 堆栈似乎知道此响应（因为它断开连接），但这似乎并没有通过蓝牙 LE GATT 库向下游传递给应用程序。实际上，从应用程序的角度来看，配对请求将返回“已配对”，并不表示出现任何问题。当然，一旦应用程序尝试访问受保护的特征，它就无法访问，而且到目前为止，这是配对不成功的唯一迹象。更糟糕的是，它收到的错误并不一致。有时，它会“无法访问”。有时，它会出现协议错误。其他时候，它会收到 ABORT。

现在，作为一种启发式方法，我可以将这种情况的检测用作尝试重新配对的标准。不幸的是，这并不理想，因为这些错误实际上并不意味着设备不再支持 LTK，而是可能表明其他问题，例如设备超出范围。

有什么方法可以检测到现有的 LTK 被设备拒绝了吗？

Answer 1

让我们看看蓝牙规范对此有何规定。

蓝牙核心版本 5.2，第 3 卷（主机），C 部分（通用访问配置文件）

第 10.3.2 节发起服务请求：

在本节中，本地设备是向 远程设备。在 L2CAP 协议中，本地设备发送连接 请求和远程设备发送连接响应。 在关贸总协定中， 本地设备是 GATT 客户端，远程设备是 GATT 服务器。 当本地设备向远程设备发起服务请求时，它应 遵守以下规则：

• [...]
• 如果 LTK 可用且需要加密（LE 安全模式 1），则 加密应在服务请求按照定义的继续进行之前启用。如果加密失败，则远程上不再存在绑定 设备，或连接了错误的设备。 本地设备必须， 用户交互确认远程设备后，重新绑定，执行服务 发现并重新配置远程设备。 [...]

如果 Windows 的 BLE 堆栈不支持规范要求的内容，在我看来，它不符合规范，因此请向 Microsoft 提交问题报告。

要求用户交互而不是盲目重新绑定的原因是为了避免黑客可以简单地欺骗蓝牙设备地址，表明它已丢失绑定并在用户没有注意到任何情况下自动重新绑定的情况。

编辑：

“安全管理器”一章还包含一个在由于删除密钥而导致加密失败时要执行的操作表。请参阅第 3 卷 H 部分的第 2.4.4.2 节。

它特别说明了之前绑定设备的时间，启用加密失败时要采取的操作是“通知用户安全失败”。