BLE配对完成缺失何种SMP数据包？MitM攻击场景排查

核心排查方向 #

• 优先确认SMP配对全流程的完整性：Bluetooth 5.3规范中，配对初始化（Request/Response）完成后，必须完成密钥分发、加密会话确认等后续步骤。如果中间人未处理这些阶段的SMP包，主机会触发SMP_TIMEOUT（默认30秒）强制断连。
• 对比合法配对与MitM流程的数据包差异：用Sniffle捕获正常配对的完整序列，和当前MitM流程对比，重点检查是否缺失以下关键SMP包：
  • Legacy配对模式下的Pairing Confirm、Pairing Random包
  • Secure Connections模式下的Session Key Distribution系列包
  • 主机发起的Security Request确认包
• 检查自行修改的Mirage PR：确认是否遗漏了加密会话维持阶段的包转发/响应逻辑——MitM场景下，中间人不能只处理配对初始化，必须完整转发两端的所有SMP协商包。

日志与数据包分析步骤 #

1. 梳理Mirage日志中配对完成到断连前的所有SMP记录：
   • 查找是否有主机重复发送某类SMP包但无响应的情况
   • 确认中间人是否正确转发了键盘端的SMP响应包
   • 检查是否存在SMP Timeout的明确日志标记
2. 分析Sniffle捕获的Request/Response数据包：

   正常配对流程中，Pairing Response发送后会立即进入密钥交换环节。如果你的MitM流程在这一步之后停止处理SMP包，主机因无法完成加密确认，会在30秒后触发超时断连。

修复建议 #

• 补全Mirage的SMP全流程转发逻辑：确保中间人对配对从初始化到加密会话维持的所有SMP数据包，进行透明转发或符合规范的响应
• 验证加密链路是否成功建立：配对完成后，用Sniffle捕获后续数据包，确认是否已进入加密传输状态
• 核对Bluetooth 5.3规范中的SMP超时触发条件：确认断连时间是否与规范定义的默认30秒超时完全匹配，以此验证超时原因的准确性

内容的提问来源于stack exchange，提问作者Pascal Rockenstiehl