1

我正在使用 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 已被设备拒绝？

4

1 回答 1

1

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

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

第 10.3.2 节发起服务请求：

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

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

如果 Windows 的 BLE 堆栈不允许规范要求，在我看来，它不符合规范，所以请在 Microsoft 提交问题报告。

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

编辑：

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

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

于 2021-05-17T19:56:57.213 回答