BLE动态密钥抓包专题1

image
我帮你把抓包和配对流程对应起来，先给结论，再拆解细节：

✅ 结论：这张抓包，实现了 BLE 配对流程的 第一阶段：配对信息交换

也就是整个配对流程的第一步：交换双方的安全能力和参数。

一、配对流程的三阶段对照

根据你提供的文档，BLE 配对分为三个阶段：

  1. 第一阶段：配对信息交换（Pairing Request/Response）
  2. 第二阶段：链路认证（根据 IO 能力生成 TK/STK）
  3. 第三阶段：密钥分配（LTK/IRK/CSRK 等）

你这张抓包，就是完整的第一阶段流程，包含了主机发的请求和设备发的响应。

二、抓包的详细拆解（对应第一阶段）

1. 主机（Central）发送的 Pairing Request（Frame 767）

这是配对流程的发起方，包含了主机的所有安全配置信息：

  • Opcode: Pairing Request (0x01)：标准配对请求包
  • AuthReq: 0x05：对应文档里的 AuthReq 字段，解析为：
    • Bonding: 0x01（绑定标志位，请求绑定设备）
    • MITM: 0x01（需要中间人保护）
  • IO Capability: Keyboard, Display：主机支持键盘和显示屏，可输入密码、显示PIN码
  • Initiator/Responder Key Distribution：主机和从机都支持分发 LTK 和 IRK 密钥

这一步的作用，就是文档里说的：客户端告诉服务端“我支持这些安全能力”。

2. 设备（Peripheral）发送的 Pairing Response（Frame 770）

这是设备对主机请求的回应：

  • Opcode: Pairing Response (0x02)：标准配对响应包
  • AuthReq: No Bonding, MITM：设备回应的安全配置，这里设置了 不绑定（No Bonding），但支持 MITM 保护
  • Key Distribution: None：设备暂时不分配任何密钥（LTK/IRK 都为 None）

这一步的作用，就是文档里说的：服务端告诉客户端“我支持这些安全能力”。

三、为什么这是「第一阶段」？

  1. 这两个包交换完成后，只是协商了双方的安全参数和配对方式，还没有进行任何密钥计算和加密。
  2. 后续的链路认证（如 Just Works/输入密码）、密钥分配（LTK/STK 计算）都还没有开始。
  3. 你的设备在响应里设置了 No Bonding 和 Key Distribution: None，说明设备拒绝了主机的绑定请求，配对流程到这里就会终止，不会进入后续的加密阶段。

一句话总结

这张抓包，就是 BLE 配对流程的第一步：配对信息交换，完成了主机和设备之间的安全能力协商，但因为设备拒绝了绑定请求，流程到此结束，没有进入后续的链路认证和密钥分配阶段。

image
这张抓包完整呈现了 BLE配对第一阶段（配对信息交换）的一次协商失败，我给你拆解清楚：

一、抓包的完整流程

  1. Frame 767：主机（手机）发送 Pairing Request（配对请求）

    • AuthReq: 0x05：主机请求开启 Bonding（绑定）+ MITM（中间人保护）
    • IO Capability: Keyboard, Display：主机支持输入/显示（可输入PIN码）
    • Key Distribution：主机请求双方交换 LTK（长期密钥）和 IRK（身份解析密钥）
      → 主机的目标：和设备建立带绑定、可加密、可重连的安全连接

  2. Frame 768：设备回复 Empty PDU（空包）
    这是一个链路层空包，仅捎带对前一个包的ACK，没有任何SMP层的内容。

  3. Frame 770：设备回复 Pairing Response（配对响应）

    • AuthReq: 0x04：设备同意 MITM 保护，但明确拒绝了 Bonding（绑定）
    • IO Capability: Display Only：设备仅支持显示，不支持输入，这意味着设备只能用 Just Works 或显示PIN码的方式配对
    • Key Distribution: <none>：设备明确表示，本次配对不交换任何密钥（LTK/IRK/CSRK都不发）

二、核心矛盾：主机和设备的安全需求不匹配

  • 主机：想要 带绑定的长期安全连接（交换LTK，重连不用再配对）
  • 设备：只接受 无绑定的临时加密连接（不存密钥，断开即失效）

这种需求不匹配，导致了配对流程的提前终止：

  1. 设备回复 No Bonding + No Key Distribution，直接拒绝了主机的绑定请求
  2. 主机收到这个响应后，无法继续后续的密钥分配阶段，配对流程就此结束
  3. 最终结果：连接可以建立，也能使用，但没有绑定，不会生成和存储LTK，下次重连会重新走一次配对流程

三、这个抓包说明了什么？

  1. 配对流程只走完了第一阶段：仅完成了安全参数协商，没有进入第二、第三阶段（链路认证、密钥分配）。
  2. 设备的安全配置是“非绑定模式”：这是Nordic工程的默认配置，设备不想存储任何密钥，只接受一次性的临时连接。
  3. 主机的绑定请求被拒绝：如果你的应用需要绑定功能（比如门锁、心率带重连免配对），就需要修改设备的安全配置，开启绑定（Bonding）和密钥分发。

四、怎么修改配置，让设备支持绑定？

在你的Nordic工程里，需要修改 ble_gap_sec_params_t 结构体：

ble_gap_sec_params_t sec_params = {
    .bond = 1,    // 开启绑定
    .mitm = 1,    // 开启MITM保护
    .lesc = 0,
    .keypress = 0,
    .io_caps = BLE_GAP_IO_CAPS_DISPLAY_ONLY, // 或改为支持键盘的模式
    .oob = 0,
    .min_key_size = 7,
    .max_key_size = 16,
    .kdist_own.enc = 1, // 设备分发LTK
    .kdist_own.id = 1,  // 设备分发IRK
    .kdist_peer.enc = 1,
    .kdist_peer.id = 1,
};

这样修改后，设备的配对响应里就会包含密钥分发标志，主机就能和设备完成完整的绑定流程了。

image
这张抓包展示了 BLE 配对流程的完整第二阶段（链路认证）和第三阶段（加密启动），但最终以「MIC校验失败」告终。我给你逐帧拆解，说明每一步发生了什么。

一、核心结论

这是一次完整的链路认证和加密协商流程，但在最后一步加密启动时失败了，失败原因是：

Encrypted packet decrypted incorrectly (bad MIC)

即：设备和手机生成的加密密钥不一致，导致完整性校验失败。

二、抓包流程逐帧解析

1. Pairing Confirm（配对确认）

  • 包：Sent Pairing Confirm / Rcvd Pairing Confirm
  • 作用：双方根据之前协商的配对方式（如 Just Works / Passkey），生成并交换 Confirm Value，验证对方是否持有相同的临时密钥（TK）。
  • 你截图里的 Confirm Value: 4b752b6c862e5c2d7eab1ef3dd54e693，就是主机发送的确认值。
  • 这一步是链路认证的核心，用来验证双方的临时密钥是否一致。

2. Pairing Random（随机数交换）

  • 包：Sent Pairing Random / Rcvd Pairing Random
  • 作用：双方交换各自生成的随机数（Rand），用来计算最终的短期密钥（STK）。
  • 这两个随机数和之前的 Confirm Value 一起，用来验证对方的密钥是否正确。

3. LL_ENC_REQ / LL_ENC_RSP（加密请求/响应）

  • 包：LL_ENC_REQ（主机发）/ LL_ENC_RSP（设备回）
  • 作用：双方协商加密参数，请求使用STK对连接进行加密。
  • 主机发送加密请求，设备回复加密响应，准备进入加密状态。

4. LL_START_ENC_REQ（启动加密请求）

  • 包：LL_START_ENC_REQ
  • 作用：主机正式请求开启加密连接，使用协商好的STK进行加密。

5. Encrypted packet decrypted incorrectly (bad MIC)（加密包解密错误）

  • 错误标记：Encrypted packet decrypted incorrectly (bad MIC)
  • 原因：Wireshark/nRF Sniffer 无法用当前的密钥解密这个包，说明：
    • 要么是双方生成的STK不一致，导致设备加密的包手机无法解密，反之亦然；
    • 要么是抓包器没有配置正确的LTK/STK，无法解析加密后的数据包。

三、流程整体解读

这是一次完整的配对链路认证流程：

  1. 双方通过 Pairing Confirm 和 Pairing Random 验证了临时密钥（TK）的一致性。
  2. 基于TK计算出了短期密钥（STK），并协商加密参数。
  3. 主机请求启动加密，设备同意。
  4. 当第一个加密包发出时，MIC校验失败，加密流程失败，连接无法进入加密状态。

四、为什么会失败？

最常见的原因有两个：

  1. 配对方式不匹配：主机和设备的IO能力不匹配，导致配对算法（如Just Works）生成的TK不一致，最终STK也不一致。
  2. 抓包器无法解密：nRF Sniffer 没有获取到STK/LTK，无法解密加密包，Wireshark直接标记为 bad MIC。

五、怎么验证？

  • 看你的 Nordic 工程日志，是否输出了 STK generated 和 Encryption enabled 的日志。
  • 如果日志显示加密成功，说明是抓包器没有配置密钥，无法解密；如果日志也显示加密失败，说明是设备端的配对配置有问题。

image
这张抓包是 BLE 配对流程「第二阶段（链路认证）」的核心环节之一，我给你拆解清楚：

🔍 这是什么包？

这是设备（Peripheral，你的 Nordic 板子）发给主机（Central，手机）的 Pairing Confirm（配对确认）包，Opcode 为 0x03，是链路认证的关键步骤。

📌 它在配对流程中的作用

在 BLE 配对的链路认证阶段，双方会按以下步骤交互：

  1. 主机发送 Pairing Confirm（你上一张截图里的包）
  2. 设备回复 Pairing Confirm（就是这张截图里的包）
  3. 双方再交换 Pairing Random 随机数

这一步的核心目的，是验证双方是否持有相同的临时密钥（TK）：

  • 设备根据协商好的配对算法（如 Just Works）和随机数，生成了 Confirm Value: 6e5def29dbcc875e89f76cb9a07220
  • 主机收到这个值后，会用自己生成的 TK 计算一个预期的 Confirm Value
  • 如果两个值匹配，说明双方的临时密钥一致，链路认证通过；如果不匹配，配对就会失败

💡 结合你之前的抓包来看

  1. 主机发了 Pairing Confirm，设备回复了这张 Pairing Confirm，说明双方已经完成了 TK 的生成和交换
  2. 下一步就是交换 Pairing Random 随机数，用来生成最终的短期密钥（STK）
  3. 再之后就是 LL_ENC_REQ/LL_ENC_RSP 加密协商和 LL_START_ENC_REQ 启动加密

一句话总结

这张抓包是设备对主机的 Pairing Confirm 响应，是链路认证阶段验证临时密钥（TK）一致性的关键一步。

image
这张抓包是 BLE 配对第二阶段（链路认证）的关键步骤：主机发送 Pairing Random（配对随机数）包，我给你拆解清楚它的作用和上下文。

🔍 这是什么包？

这是主机（Central，手机）发给设备（Peripheral，你的 Nordic 板子）的 Pairing Random 包：

  • Opcode: 0x04
  • 核心数据: Random Value: 0217c851d848f52723f6ecd8b151a471（16字节随机数）

📌 它在配对流程中的位置

在链路认证阶段，双方的交互顺序是：

  1. 主机发送 Pairing Confirm
  2. 设备回复 Pairing Confirm
  3. 主机发送 Pairing Random（就是你这张截图的包）
  4. 设备回复 Pairing Random

这个包的作用是提供生成短期密钥（STK）所需的随机数。

💡 它的核心作用

  1. STK 生成的输入参数
    STK（短期密钥）的计算公式为：
    STK = E_TK(Rand_M | Rand_S)

    • Rand_M：主机发送的随机数（就是这张截图里的 Random Value）
    • Rand_S：设备回复的随机数
    • TK：链路认证阶段生成的临时密钥
      这一步就是主机把 Rand_M 发给设备，供双方计算STK使用。

  2. 防止重放攻击
    每次配对都会生成不同的随机数，确保每次生成的STK都是唯一的，无法被攻击者重复利用旧的密钥和数据。

🔗 结合你之前的抓包看流程

你现在已经走完了链路认证的完整交互：

  • 主机和设备交换了 Pairing Confirm，验证了TK的一致性
  • 主机发送 Pairing Random，设备也回复了自己的随机数
  • 双方现在可以基于这两个随机数和TK，计算出最终的STK，进入后续的加密协商阶段

✅ 总结

这张抓包是BLE配对第二阶段链路认证的收尾步骤，主机向设备提供了生成STK所需的随机数，为后续的加密连接（LL_ENC_REQ/LL_START_ENC_REQ）提供了必要的输入。

image
这张抓包是 BLE 配对流程中「加密启动阶段」的核心请求包，我给你拆解清楚它的作用和上下文：

🔍 这是什么包？

这是主机（手机）发给设备（你的 Nordic 板子）的 LL_ENC_REQ（链路层加密请求）包，Opcode 为 0x03。

📌 它在配对流程中的位置

这是配对流程的倒数第二步，发生在：

  1. 第一阶段：配对信息交换（Pairing Request/Response）
  2. 第二阶段：链路认证（Pairing Confirm/Random，生成STK）
  3. 第三阶段：加密启动（LL_ENC_REQ/LL_ENC_RSP） ← 你这张截图的位置
  4. 最后一步：LL_START_ENC_REQ（正式启动加密）

💡 包内关键信息解析

  1. Central Session Key Diversifier 和 Central Session Initialization Vector
    这两个字段是主机提供的会话密钥参数，和之前生成的 STK（短期密钥）一起，用来计算本次连接的加密密钥。

  2. Response in Frame: 1491 / 1495
    抓包工具标记了这两个帧是它的响应包，也就是设备会回复 LL_ENC_RSP 来同意加密请求，然后主机再发 LL_START_ENC_REQ 正式开启加密。

  3. Random Number: 0 / Encrypted Diversifier: 0
    这两个值为0，说明这是首次加密，不是重连恢复加密（重连会用EDIV和Rand来恢复LTK）。

🔗 结合你之前的抓包看完整流程

  • 你已经完成了 Pairing Confirm 和 Pairing Random，生成了STK
  • 主机现在发 LL_ENC_REQ，请求用STK对连接进行加密
  • 设备回复 LL_ENC_RSP 同意后，主机发 LL_START_ENC_REQ，连接就进入加密状态了

✅ 一句话总结

这张抓包是主机向设备发起的加密请求，标志着BLE配对流程已经进入了最后的加密启动阶段，只要设备同意并回复响应，连接就会进入加密状态。

image
这张抓包是设备（你的 Nordic 板子）对主机加密请求的正式响应，标志着BLE配对流程的「加密启动阶段」已达成共识。

🔍 包的核心信息

这是设备发给主机的 LL_ENC_RSP（链路层加密响应）包，Opcode 为 0x04，是对前序 LL_ENC_REQ 的回应。

关键字段解读

  • Peripheral Session Key Diversifier：设备生成的会话密钥区分符
  • Peripheral Session Initialization Vector：设备生成的会话初始化向量
  • 这两个参数，会和主机提供的参数、之前链路认证生成的STK一起，计算出本次连接的会话加密密钥。

📌 它在配对流程中的作用

  1. 确认加密请求：设备明确同意主机发起的加密请求，双方就加密参数达成一致。
  2. 提供加密参数：设备提供自己的会话密钥参数，和主机的参数一起，用来计算会话密钥。
  3. 为下一步做准备：主机收到这个响应后，就可以发送 LL_START_ENC_REQ，正式启动加密连接。

🔗 结合你之前的抓包看完整流程

到这一步，配对流程已经走完了：

  1. 第一阶段：配对信息交换（Pairing Request/Response）
  2. 第二阶段：链路认证（Pairing Confirm/Random，生成STK）
  3. 第三阶段：加密协商（LL_ENC_REQ/LL_ENC_RSP，参数交换）

接下来，只要主机发送 LL_START_ENC_REQ，连接就会正式进入加密状态，后续的所有数据包都会被加密传输。

✅ 一句话总结

这张抓包是设备对主机加密请求的同意回应，双方已经完成了加密参数协商，即将进入正式的加密连接状态。

image
这张抓包是BLE配对流程的最后一步：正式启动加密连接，我给你拆解清楚它的意义和上下文。

🔍 包的核心信息

这是设备发给主机的 LL_START_ENC_REQ（启动加密请求）包，Opcode 为 0x05。
它是对前面 LL_ENC_REQ/LL_ENC_RSP 协商的收尾，标志着双方准备好切换到加密模式。

📌 它在配对流程中的位置

这是整个配对流程的最后一步，前面的步骤都已完成：

  1. 第一阶段：配对信息交换（Pairing Request/Response）
  2. 第二阶段：链路认证（Pairing Confirm/Random，生成STK）
  3. 第三阶段：加密协商（LL_ENC_REQ/LL_ENC_RSP，交换会话参数）
  4. 第四阶段：启动加密（LL_START_ENC_REQ） ← 这张截图的位置

💡 它的核心作用

  • 双方通过之前的步骤，已经生成了一致的短期密钥（STK），并交换了会话参数。
  • 这一步是设备向主机发送信号，表示：“我已准备好使用协商好的STK对连接进行加密，请在下次连接事件中切换到加密模式”。
  • 主机收到这个请求后，会在下一个连接事件里，对后续的所有数据包启用加密和MIC校验。

🔗 结合你之前的抓包看结果

到这一步，配对流程已经全部完成：

  • 链路认证通过，双方持有相同的STK
  • 加密参数协商完成
  • 双方都同意启动加密

理论上，后续的所有LL层和ATT层数据包，都应该被加密传输，且包含有效的MIC校验。
你之前抓包中出现的 Encrypted packet decrypted incorrectly (bad MIC)，大概率是抓包器没有配置正确的STK，无法解密导致的，而非设备端配对失败。

✅ 一句话总结

这张抓包是BLE配对流程的终点，标志着双方协商一致，准备正式进入加密连接状态。

image
这张抓包，是你整个配对流程的最终结果：加密连接启动失败，抓包器无法解析后续的加密包。我给你拆解清楚问题根源和含义：

🔍 核心现象

这是一个被标记为 Encrypted packet decrypted incorrectly (bad MIC) 的包：

  1. Encrypted: Yes：连接已经尝试进入加密状态
  2. MIC: Error：消息完整性校验失败，Wireshark/nRF Sniffer 无法解密这个包
  3. Control Opcode: Unknown (0xb8)：因为解密失败，无法解析出实际的控制指令

📌 为什么会出现 bad MIC？

结合你前面的配对流程，有两种完全不同的可能：

可能性1：设备端配对成功，但抓包器配置错误（最常见）

你的设备和手机已经完成了配对、生成了一致的STK，并成功进入了加密状态。但抓包器因为没有配置正确的密钥，无法解密加密后的包，导致误报 bad MIC：

  • 你选的 Legacy Passkey 不对，应该选 Legacy LTK/Legacy Passkey 并填入正确的STK/LTK
  • 密钥填错了、位数不对，或者配对模式和密钥类型不匹配（用了LTK去解首次配对的STK）
  • 抓包器的时序或信道同步有问题，丢了前面的加密协商参数

这种情况下，设备端的配对和加密是正常的，只是抓包工具看不到明文数据。

可能性2：设备端配对失败，STK不一致

设备和手机在链路认证阶段生成的STK不一致，导致加密包的MIC校验失败，手机和设备之间也无法正常通信：

  • 你的设备配置了 Display Only IO能力，和手机的键盘+显示屏能力不匹配，导致Just Works配对算法生成的TK不一致
  • 配对流程中某个环节丢包（比如 Pairing Confirm 或 Random 包丢失），导致STK计算失败
  • 设备的安全配置（如 Bonding、MITM 标志）和手机的需求不匹配，导致配对提前终止，没有生成有效的STK

这种情况下，设备和手机的连接虽然能维持，但加密是无效的，后续的通信会持续出错或断开。

💡 怎么区分这两种情况？

看你的 Nordic 设备串口日志：

  1. 如果日志输出了 Encryption enabled 或 Security update success，说明设备端配对加密成功，问题在抓包器配置
  2. 如果日志输出了 Pairing failed 或 Encryption rejected，说明设备端配对失败，STK不一致，需要修改安全配置

✅ 一句话总结

这张抓包是配对流程的收尾：要么是抓包器没有配置正确的密钥，无法解密加密包；要么是设备和手机的STK不一致，加密校验失败。

posted @ 2026-04-27 21:45  wzm888  阅读(80)  评论(2)    收藏  举报