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