我正在使用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库的应用程序。事实上，从应用程序一侧，配对请求将返回"0"；"已配对"；，并且并不表示出了任何问题。当然，一旦应用程序尝试访问受保护的特征，它将无法访问，而到目前为止，这是配对不成功的唯一迹象。更糟糕的是，它收到的错误并不一致。有时；无法访问"；。有时，它会出现协议错误。其他时候，它会收到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节
它特别指出，当设备在此之前被绑定时，当启用加密失败时要采取的行动是"加密"；通知用户安全故障">