有关EDIV和Rand的两个问题：
我需要确定我完全理解EDIV和Rand如何在BLE Legacy Pairing中使用。我从蓝牙规范中理解的是，它们是在配对阶段由从设备生成的，并与主设备一起与LTK一起交换。我不太清楚我理解的部分是在加密设置期间从设备如何使用它。在我看来，规范为实际的BLE实现提供了自由：在接收加密请求后使用EDIV / Rand作为一种索引来检索关联的LTK，或者每次使用EDIV /重新生成LTK Rand和特定于设备，永不共享的秘密值。这是对的吗？
为什么他们已从Secure Connections配对中删除？在这种情况下，LTK和对等设备之间的关联如何？使用身份地址？
提前致谢。
答案 0 :(得分：2)
你似乎对所有想法都是正确的。
对于LE Legacy Pairing ，根据蓝牙核心规范，第3卷第H部分2.4.1：
- 加密分集器（EDIV）是一个16位存储值，用于识别LE传统配对期间分配的LTK。每次分配一个唯一的LTK时，都会生成一个新的EDIV。
- 随机数（Rand）是64位存储值，用于标识在LE遗留配对期间分发的LTK。每次分配唯一的LTK时都会生成一个新的Rand。
因此，在Legacy Pairing中，想法是EDIV和随机数对识别要使用的LTK。
在第2.4.2节中：
2.4.2 生成分布式密钥
可以使用任何生成正在分发的密钥的方法，这些密钥导致密钥具有128位熵，因为生成方法在从属设备外部不可见（参见章节附录B）。密钥不应仅从分发给主设备的信息生成，也不应仅从从设备外部可见的信息生成。
所以是的，只要该方法提供了良好的安全性，您就可以使用任何方法生成EDIV / Rand / LTK值。规范本身在第3卷H部分附录B＆＃34;密钥管理＆＃34;：
中提出了两种不同的方法第一个是EDIV是LTK数据库的索引。我想这里他们的意思是为每个配对生成一个新的EDIV和LTK对。对我来说，不使用EDIV和Rand作为查找键似乎有点愚蠢。提到的变体是使用(AES(DHK, Rand) mod 2^16) XOR EDIV（其中DHK是每个设备唯一的密钥）作为索引，我也没有得到他们的观点。
第二种方法是使每个设备唯一的密钥DHK和ER。然后，对于每个新配对，您随机生成16位DIV和64位Rand。 EDIV派生为(AES(DHK, Rand) mod 2^16) XOR DIV。 LTK派生为AES(ER, DIV)，据我所知，与简单AES(ER, Rand || EDIV)相比非常愚蠢（并且让EDIV随机生成而不是DIV），因为他们的方法只能有2 ^ 16个不同的密钥，应用生日悖论时，意味着在大约256个生成的密钥后，可能会有重复。 （如果Bluetooth SIG中的任何人正在阅读此内容 - 请告诉我这种奇怪方法的原因）。无论如何，从EDIV和Rand获得LTK，您不需要存储LTK或EDIV / Rand值。他们似乎忘记的一件事是，由于在配对期间可以协商不同的密钥大小（7-16字节），因此您必须仍然为每个绑定的设备存储密钥大小，在进一步加密时应该截断所得到的密钥。或者你可以解决这个问题，例如硬编码Rand值中的4位，使用哪个密钥大小。
有一个问题就是完全忽略了一个安全数据库而只是依赖LTK总能从主人的EDIV和Rand中恢复：你将永远无法＆＃34;删除＆＃ 34;债券或撤销关键。此外，如果您严格遵循GAP，您应该知道您是否有可用的密钥来启动当前连接的加密。例如，当读取GATT特性时因错误响应，因为该特性需要加密链接，根据LTK是否可用，存在不同的错误代码; ＆＃34;加密不足＆＃34;如果LTK可用且＆＃34;认证不足＆＃34;如果没有。
在LE安全连接中，LTK不是分布式的，而是贡献，这意味着它来自两个对等体的值（使用Diffie Hellman函数作为核心）。因此，一部分不能自由选择LTK。 LTK生成函数的输入值是Diffie Hellman共享密钥，来自两个对等体的随机随机数和两个对等体的蓝牙设备地址（连接中使用的地址，而不是身份地址）。由于输入值比LTK占用更多空间，因此将LTK存储在数据库中更为可行。
由于每个绑定设备必须只有一个LTK，因此在EDIV和Rand中没有任何意义，因此在加密请求中它们应设置为0。这意味着我们现在还必须将设备映射到LTK而不是EDIV / Rand到LTK。为此，在查找LTK时使用标识地址。如果一个随机可解析地址用于连接，我们必须测试所有存储的IRK并获得相应的身份地址。如果公共或静态随机地址用于连接 - 即身份地址。