LTK 是如何在低功耗蓝牙连接中形成的？
How is LTK formed in Bluetooth Low Energy connections?
我正在通过 Android 和传感器之间的 BLE 连接进行渗透测试，当我尝试解密 Wireshark .pcap 文件时遇到问题，因为我不太确定LTK成立。
有一个包含数据包 [Encryption_Req] 和 [Encryption_Rsp] 的屏幕截图，关于我使用带嗅探器的 Texas Instrument Dongle 得到的结果。
Encryption_Req & Encryption_Rsp
我认为 LTK 是匹配 [SKDm & SKDs] 或 [SKDs & SKDm] 形成的。
这意味着：BE952D3D760331A834CC6A4274417E48 (SKDm -> SKDs)
或：A834CC6A4274417E48BE952D3D760331（SKD -> SKDm）
我不确定这是正确的还是我遗漏了什么。
LTK是存储在设备中的长期密钥，绑定后交换。在 Legacy 配对中，从设备只是选择一个随机的 LTK 并将其发送给主设备。在 LE 安全连接中，LTK 源自 diffie hellman 交换。
LL_ENC_REQ 和 LL_ENC_RSP 数据包包含 "session key diversifiers" 而不是 LTK（因为如果在启用加密之前以明文形式发送密钥，这会破坏安全性）。为了确保每个新连接的安全，每个连接都使用一个新的会话密钥。为了创建这个会话密钥，每个设备生成 8+4 字节的随机数据。 SKDm 和 SKDs 值连接成一个 16 字节的 SKD。会话密钥由作为值的 LTK 和作为密钥的 SKD 的 AES 加密生成。请注意，在连接 SKDm 和 SKDs 之后，在将其输入标准 AES 函数之前反转所有 16 个字节，因为蓝牙使用小端但 AES 标准使用大端。
所以 487E4174426ACC34A83103763D2D95BE 是所有 AES 库都期望的格式的 SKD。
LL_ENC_REQ 中的 Rand 和 EDIV 字段作为密钥的标识符发送到从属设备，以便它可以在其数据库中查找 LTK。
应将 IVm 和 IVs 值连接起来以获得 IV（不可反转）。此 IV 在 AES-CCM 加密中用作随机数的一部分。请参阅蓝牙核心规范 5.0，第 6 卷，E 部分，第 2.1 章。
我正在通过 Android 和传感器之间的 BLE 连接进行渗透测试，当我尝试解密 Wireshark .pcap 文件时遇到问题，因为我不太确定LTK成立。
有一个包含数据包 [Encryption_Req] 和 [Encryption_Rsp] 的屏幕截图，关于我使用带嗅探器的 Texas Instrument Dongle 得到的结果。
Encryption_Req & Encryption_Rsp
我认为 LTK 是匹配 [SKDm & SKDs] 或 [SKDs & SKDm] 形成的。
这意味着：BE952D3D760331A834CC6A4274417E48 (SKDm -> SKDs)
或：A834CC6A4274417E48BE952D3D760331（SKD -> SKDm）
我不确定这是正确的还是我遗漏了什么。
LTK是存储在设备中的长期密钥，绑定后交换。在 Legacy 配对中，从设备只是选择一个随机的 LTK 并将其发送给主设备。在 LE 安全连接中，LTK 源自 diffie hellman 交换。
LL_ENC_REQ 和 LL_ENC_RSP 数据包包含 "session key diversifiers" 而不是 LTK（因为如果在启用加密之前以明文形式发送密钥，这会破坏安全性）。为了确保每个新连接的安全，每个连接都使用一个新的会话密钥。为了创建这个会话密钥，每个设备生成 8+4 字节的随机数据。 SKDm 和 SKDs 值连接成一个 16 字节的 SKD。会话密钥由作为值的 LTK 和作为密钥的 SKD 的 AES 加密生成。请注意，在连接 SKDm 和 SKDs 之后，在将其输入标准 AES 函数之前反转所有 16 个字节，因为蓝牙使用小端但 AES 标准使用大端。
所以 487E4174426ACC34A83103763D2D95BE 是所有 AES 库都期望的格式的 SKD。
LL_ENC_REQ 中的 Rand 和 EDIV 字段作为密钥的标识符发送到从属设备，以便它可以在其数据库中查找 LTK。
应将 IVm 和 IVs 值连接起来以获得 IV（不可反转）。此 IV 在 AES-CCM 加密中用作随机数的一部分。请参阅蓝牙核心规范 5.0，第 6 卷，E 部分，第 2.1 章。