[参考译文] CC2540：CVE-2019-2102 - LTK 身份验证问题

您好、Frederik、

指派一名专家来逐一查看详细信息。 敬请期待。

您好、Joakim、

感谢您的帮助-同时、我们还关注2017年的生产线、该生产线会影响更多的传感器！

因此、2016年生产的器件有时似乎具有相同的 LTK - 2017年生产的器件具有相同的 LTK。

有趣的不同的洗浴线，不要阻挡其他的。

因此、对于存在该问题的器件、我们看到：

-配对1设备2016 -正常工作

-配对2台设备2016 -失败- 1台设备配对-第二台设备将失败(始终第一次配对尝试成功)

-配对1器件2017 -正常工作

-配对2台设备2017 -失败- 1台设备配对-第二台设备将失败(始终第一次配对尝试成功)

-配对1台设备2016和1台设备2017 -工作正常！！！

如果自更新1903以来已有另一个配对设备与相同密钥、Windows 将阻止该设备。

我们使用2017年的18个器件产品线对其进行了测试- 11个似乎创建了相同的 LTK (无法再配对)- 7个器件仍按预期工作

此外、我们还可以确定问题与接收器相关、因为我们使用两个 BCM20702芯片组器件和一个 CSR 器件对其进行了测试。

此外、它与 PC 无关-我们可以在3台具有最新1903更新版本的 PC 上使用同样受影响的传感器重现此问题。

我们还使用 BTool 和北欧接收器调查了问题-如果我们看不到设备产生相同的 LTK -仍然在 Windows 环境中、我们无法再将它们配对。

下一步是监听配对过程...

即使是上面提到的 Microsoft 文章、Windows 也会创建错误22、我们也会得到错误35！

ProtocolName：系统
资料来源：BTHUSB
ID：35
DAS Gerät (xx：xx：xx：xx：xx：xx：xx) versecht、einen Identitätsauflösungsschlüssel zu verteilen、der bereits von einem gekoppelten Gerät verwendet wrd。 DAS 配对 wurde abgelehnt。 wenn Sie beabsichigen、mit diesem Gerät zu koppeln、müssen Sie möglicherweise zuerst die vorhandenen Pair-Informationen löschen。

(Sry German PC)

因此问题不是所描述的一个(默认密钥)、而是 Microsoft 还为创建相同 LTK 的设备添加了一个新块、这似乎是发生的。

如果您需要调查硬件 ID、请向我发送 PM。

此致

您好、Fredrik、

根据我的翻译、错误消息如下所示：

设备(xx: XX: XX: XX: XX: XX: XX: XX)尝试分发已被配对设备使用的标识解析密钥。 配对被拒绝。 如果您计划与此设备配对、您可能需要先清除现有的配对信息。

1) 1)您是否正在使用粘合剂？

2) 2)如果您是-在第二次(失败)配对尝试之前、是否擦除了任何设备上的绑定信息？ (如果在一个器件上擦除绑定信息、但在另一个器件上擦除绑定信息、则可能会发生这种情况)

3) 3)您是否使用 MIPTM、设备上的 I/O 功能是什么(使用哪种配对)？

4) 4)当您说 2016量产线 和 2017量产线时、是否所有器件都使用相同的软件(BLE Stack 1.5.0.16)？

您好、Marie、

翻译效果不会太差-当配对第二台设备而不是 LTK 时、Windows 可能会抱怨相同的问题、这可能是正确的。

根据：

"两个器件具有相同的 irk 并生成相同随机数的概率很低、但不是绝对的。"

如果这是问题-我们如何解决？ 我不知道我们的 FW 中是否有任何特殊的隐私功能？ 我们的设备可通过公共地址连接。

1) 1)是的

2) 2)我们不会手动擦除传感器上的任何粘接信息

我们的固件完全基于 SimpleBlePeripheral -无附加- BondMgrCBs = NULL

3)

4) 4)当您说 2016量产线 和 2017量产线时、是否所有器件都使用相同的软件(BLE Stack 1.5.0.16)？

是-所有产品线的最新固件均基于1.5.0.16 -但我甚至使用旧的1.4.0进行了测试... Stack FW ->相同的结果

此致

是的、我可以确认某些器件的 irk 是相同的！

我刚刚使用 BTool 测试了11个"非工作设备"中的3个设备和1个"工作设备"中的1个设备

3个器件都具有相同的 irk！

一个 wokring 有另一个 irk！

很抱歉、我还不知道 irk、因为我们不使用私人地址/隐私功能。

因此，Windows 似乎会阻止具有与1903年更新相同 irk 的设备！

在中 ，如果将其全部设置为0，则将随机生成 irk…… 我们没有显式设置该值。

1) 1)如果我在启动时将其设置为0、会发生什么情况？ 是否会在每次启动时随机进行->随每次启动而更改？

2) Woudl 1)是否是已绑定的设备的问题(因为在中央保存该密钥后、它会再次更改)？ (是否符合规格？)

3) 3)如果我们不明确设置、那么当前的 irk 生成过程是如何的？ (=我们的固件= SimpleBlePeripheral)

4) 4)为什么有这么多的器件！！！ 18岁中的11岁！！！ 随机选择的器件具有相同的 irk？ 这是一个错误吗？ 根据上述消息来源、这种情况很少发生... [我们还尝试了2016系列中的一些器件- 7个器件中有3个发生了这种情况-我想这种情况会发生很多]

5) 5)我们如何更改 irk 生成以解决此问题？

此致

您好、Frederik、

1) 1) irk 存储在 nV 中、因此它将只设置一次。 启动时、从 nV 读取。 (请参阅 peripheral.c) 如果您希望在启动时出现新的 irk、则必须特意覆盖 SNV BLE_NVID_irk 区域。

2) 2)否、由于您不使用隐私、因此 irk 实际上不会被使用。 (我不确定该规范是否明确禁止此行为。)

3) 3) irk 由 RFPSRND 寄存器生成。 您可以看到您链接的文档(swru191) 、第25.10章、随机数生成。

4) 4)在这里、我需要返回给您。

5) 5)是、您可以手动为设备分配不同的辐条。

-或者、由于您未使用隐私、您可以尝试更改配对响应数据包以不包括 irk。  

- 您还应在开始测试之前手动删除 Win10中蓝牙设置菜单下的所有配对设备。

您好、Fredrik、

你明白了吗？

由于不活动、我将关闭此线程。

您好、Marie、

4)我仍然在跳过以获得答案4)、因为这似乎是主要问题、而且它仍然存在... 只要我们了解我们可以正确解决它的原因。

此致

您好、Fredrik、

我希望每个器件都有一个新的 irk。 您是否使用包含‘golden’unit 的 OSAL NV 镜像的镜像对他的设备进行编程，而该镜像先前已计算并存储了它的 irk？ ( 如果在器件上重新编程 simpleBLEperipheral，则可以排除这种情况，然后使用 CC 调试器检查 irk 和 GAP DeviceInit 的相关 NV 读取返回值(如果 NV 值被读作所有 FF)。 GAP DevInit 应该为您提供“随机”irk。)

我们目前不是这样做的、而是通过连接图像来创建一个 SuperHex。 但在较旧的生产线中、这可能是这样的。 一定会再来的……

感谢您的提示。 我仍然不确定、因为我们也有具有相同生产中不同密钥的器件。 那么、所有器件都应该受到影响、还是都不应该受到影响？ 还有其他建议吗？

此致