如何解决在蓝牙 LE GATT 中，有什么方法可以检测长期密钥何时无效？
我正在使用 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 库的应用程序下游。实际上，从应用程序的角度来看，配对请求会返回“Already Paired”，并不表示出现任何问题。当然，一旦应用程序尝试访问受保护的特征，它将无法访问，并且到目前为止，这是配对未成功的唯一迹象。更糟糕的是，它收到的错误并不一致。有时，它会“无法访问”。有时，它会收到协议错误。其他时候，它会收到 ABORT。
现在，作为一种启发式方法，我可以使用对这种情况的检测作为尝试重新配对的标准。不幸的是，这并不理想，因为这些错误实际上并不意味着设备不再遵守 LTK，而是可能表明其他问题，例如设备超出范围。
有什么方法可以检测到现有的 LTK 已被设备拒绝了吗？
解决方法
让我们看看蓝牙规范对此是怎么说的。
蓝牙核心版本 5.2，第 3 卷（主机），C 部分（通用访问配置文件）
第 10.3.2 节发起服务请求：
在本节中，本地设备是向某个设备发起服务请求的设备。 远程设备。在 L2CAP 协议中，本地设备发送连接 请求，远程设备发送连接响应。 在关贸总协定中， 本地设备是 GATT 客户端，远程设备是 GATT 服务器。 当本地设备向远程设备发起服务请求时，它应该 按照以下规则行事：
- [...]
- 如果 LTK 可用且需要加密（LE 安全模式 1），则 应在服务请求按定义进行之前启用加密。如果加密失败要么绑定不再存在于远程 设备，或者连接了错误的设备。 本地设备必须， 用户交互确认远程设备后，重新绑定，执行服务 发现并重新配置远程设备。 [...]
如果 Windows 的 BLE 堆栈不支持规范要求的内容，在我看来，它不符合规范，因此请向 Microsoft 提交问题报告。
需要用户交互而不是盲目重新绑定的原因是为了避免黑客可以简单地欺骗蓝牙设备地址的情况，表明它已经失去了绑定并自动重新绑定而用户没有注意到任何事情。
>编辑：
安全管理器章节还有一个表，列出了由于删除密钥而导致加密失败时要执行的操作。参见第 3 卷 H 部分的 2.4.4.2 节。
它特别说明在设备绑定之前，启用加密失败时采取的操作是“通知用户安全失败。”
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
