我是一名开发人员，正在开发一款使用高通SoC进行蓝牙和音频处理的蓝牙耳机产品。我们的产品使用BREDR蓝牙；经典的"；配置文件(HFP/AVRCP/A2DP(和LE。
我们期望用户执行的典型流程是：
- BREDR使用智能手机的蓝牙设置进行配对。这使用传统的BREDR"；简单配对"；产生P192加密密钥的方法
- 用户打开我们的应用程序，当应用程序尝试访问我们的自定义GATT服务时，该应用程序将触发LE配对
由于兼容性问题，我们的耳机不支持BREDR上的安全连接，但它支持LE安全连接。因此，通常情况下，在LE配对完成后，会根据LE长期密钥重新计算BREDR链路密钥，这使其具有P256加密能力。例如，以下是BREDR配对后耳机永久存储中的链接键的样子：
Device #0: addr_type=PUBLIC
BDADDR = xxxx xx xxxxxx
BREDR key: bbb...b (AUTHENTICATED P192)
LE配对后：
Device #0: addr_type=PUBLIC
BDADDR = xxxx xx xxxxxx
BREDR key: aaa...a (AUTHENTICATED P256)
LE CENTRAL Key : 0000 (EVID) 0000000000000000 (RAND) bbb...b (LTK)
LE IRK: ccc...c
现在，这对大多数平台来说都不是问题，但最近我开始看到某些运行Android 10/11的Android设备和一些运行带有最新安全补丁的Android 9的设备出现问题。基本上，在LE配对后，我无法创建任何新的BREDR ACL。连接总是在LMP_rand_au->sres响应阶段-本质上，移动设备在LE配对后没有重新计算其BREDR链路密钥，现在设备不再同意LTK。我在耳机设备中明确禁用了跨传输密钥派生，但在LE密钥分发后，BREDR密钥仍然更改。这在iOS设备上似乎根本不是问题。有其他人遇到这个问题吗？关于如何进行有什么建议吗？到目前为止，我已经尝试过：
- 禁用LE链接密钥分发：这可以防止BREDR密钥被重新计算，因为没有LE LTK/IRK。然而，一旦移动电话改变其随机LE地址，用户将被迫重新配对。这也导致我在耳机设备上的可信设备列表膨胀，而且受到了严格的限制
- 在LE安全性完成后强制更改LTK-有一个HCI命令明确用于重新派生LTK。然而，尝试这样做会导致各种令人讨厌的奇怪行为。也许我的耳机SoC不完全支持它
- 在LE配对前保存BREDR LTK，并在LE配对后重置。这允许BREDR连接，这让我怀疑问题出在移动设备上。然而，这当然会阻止用户访问移动应用程序
好吧，我实际上设法从高通公司获得了一些关于这个问题的技术支持。问题出现在Android设备中，因此解决方案是在禁用BREDR安全连接的情况下，也要强制禁用耳机中的CTKD。这在高通公司的API中是不可能的，我不得不更改高通公司在ADK中提供的开源连接库中的一些文件。