别再死记硬背了！用一张图+代码示例，彻底搞懂蓝牙BLE配对的6种SMP流程
蓝牙BLE安全配对实战图解：6种SMP流程与核心算法拆解
每次看到蓝牙协议栈里那些晦涩的安全管理协议（SMP）文档就头疼？别担心，今天我们用工程师的思维来重新解构这个"安全黑匣子"。扔掉那些让人昏昏欲睡的文字说明，我将带您用一张决策树状图和可运行的代码示例，把BLE配对的6种SMP流程变成可视化的技术拼图。
1. SMP协议的本质：安全握手的三重奏
想象两个陌生人在嘈杂的咖啡馆交换机密文件。他们需要：1）确认对方身份 2）建立加密通道 3）安全传输内容——这正是SMP协议的三个核心阶段。在BLE世界里，这个流程被标准化为：
- 能力协商阶段：设备间交换安全参数（就像出示身份证）
- 密钥生成阶段：通过密码学舞蹈产生临时或长期密钥（相当于约定加密规则）
- 密钥分发阶段：在加密通道中传递身份识别等敏感信息（实际文件传递）
# 简化的SMP状态机伪代码示例 class SMPStateMachine: def __init__(self): self.state = "IDLE" def handle_event(self, pdu): if self.state == "IDLE" and pdu == "PAIRING_REQUEST": self.start_pairing() elif self.state == "FEATURE_EXCHANGE": self.negotiate_algorithm(pdu.io_capabilities) # 其他状态处理... def start_pairing(self): print("启动30秒超时计时器") self.timer = threading.Timer(30.0, self.timeout_handler) self.timer.start()关键提示：所有SMP交互都在固定的L2CAP信道0x0006上进行，MTU大小取决于是否支持LE Secure Connections（65字节 vs 23字节）
2. 配对流程决策树：六种路径全景图
决定SMP走向的三个关键参数：
- 安全连接支持：LE Legacy Pairing 或 LE Secure Connections
- IO能力：键盘/显示屏/两者皆无
- OOB支持：是否使用带外认证
这些参数的组合形成了著名的六种配对方式：
| 配对类型 | 适用场景 | 安全等级 | 典型用例 |
|---|---|---|---|
| Just Works | 无输入输出设备 | ★☆☆☆☆ | 蓝牙遥控器配对电视 |
| Passkey Entry | 一方有键盘，一方有显示屏 | ★★★☆☆ | 手机配对智能锁 |
| OOB | 支持NFC等近场通信 | ★★★★☆ | 高端耳机快速配对 |
| Numeric Comparison | 双方都有显示屏 | ★★★★★ | 两个手机互相认证 |
| Passkey Entry (SC) | 安全连接下的密码输入 | ★★★★★ | 医疗设备安全配对 |
| OOB (SC) | 安全连接下的带外认证 | ★★★★★ | 企业级IoT设备部署 |
graph TD A[开始配对] --> B{支持LE Secure Connections?} B -->|是| C[LE Secure Connections] B -->|否| D[LE Legacy Pairing] C --> E{IO能力与OOB} D --> F{IO能力与OOB} E -->|双方显示| G[Numeric Comparison] E -->|一方输入一方显示| H[Passkey Entry SC] E -->|OOB可用| I[OOB SC] F -->|无输入输出| J[Just Works] F -->|一方输入一方显示| K[Passkey Entry] F -->|OOB可用| L[OOB]3. 密码学引擎室：核心算法函数详解
3.1 Legacy Pairing的加密工具箱
在传统配对中，这几个函数扮演着关键角色：
c1函数：用于生成确认值
def c1(k, r, preq, pres, iat, rat, ia, ra): p1 = preq + pres + bytes([iat]) + bytes([rat]) + ia + ra p2 = ia + ra + bytes([rat]) + bytes([iat]) + pres + preq temp = xor_128(r, p1) return aes_128(k, aes_128(k, temp) ^ p2)s1函数：生成短期密钥STK
def s1(k, r1, r2): # 拼接r1的高64位和r2的低64位 r_combined = (r1 & 0xFFFFFFFFFFFFFFFF0000000000000000) | (r2 & 0x0000000000000000FFFFFFFFFFFFFFFF) return aes_128(k, r_combined)
技术细节：Just Works模式下TK=0，Passkey Entry模式下TK是6位数字（000000-999999），OOB模式下TK是预共享的128位随机数
3.2 Secure Connections的升级装备
安全连接引入了更强大的椭圆曲线密码学（P-256曲线）和这些新武器：
f4函数：用于配对确认
def f4(u, v, x, z): message = u + v + z return aes_cmac(x, message)f5函数：生成LTK和MacKey
def f5(dhkey, n1, n2, a1, a2): t = aes_cmac(b"salt", dhkey) # salt是固定值"蓝牙SMP" part1 = aes_cmac(t, b'\x00' + b'btle' + n1 + n2 + a1 + a2 + b'\x00\x01\x00') part2 = aes_cmac(t, b'\x01' + b'btle' + n1 + n2 + a1 + a2 + b'\x00\x01\x00') return part1, part2 # MacKey, LTK
4. 实战案例：从协议到代码的完整映射
让我们以最常见的Just Works配对为例，看看协议栈中实际发生了什么：
特征交换：
# Master发送Pairing Request pairing_req = { 'io_cap': IO_CAP_NO_INPUT_NO_OUTPUT, 'oob_flag': OOB_AUTH_NOT_PRESENT, 'auth_req': AUTH_REQ_BONDING } # Slave回复Pairing Response pairing_res = { 'io_cap': IO_CAP_NO_INPUT_NO_OUTPUT, 'oob_flag': OOB_AUTH_NOT_PRESENT, 'auth_req': AUTH_REQ_BONDING }认证阶段（TK=0）：
# 双方计算并交换Confirm值 m_confirm = c1(tk=0, m_rand=os.urandom(16), preq=pairing_req_bytes, pres=pairing_res_bytes, iat=0, rat=0, ia=master_addr, ra=slave_addr) # 交换随机数后验证 if local_confirm != peer_confirm: raise SMPAuthenticationError("Confirm值不匹配")密钥生成：
# 生成STK用于加密链路 stk = s1(tk=0, s_rand=slave_rand, m_rand=master_rand) # 后续在加密通道中交换LTK等长期密钥 ltk = generate_ltk() # 通常使用硬件随机数生成器
在开发中遇到的经典问题：Confirm值校验失败？检查地址类型（0=公共地址，1=随机地址）和字节序问题；STK生成失败？确认随机数是否正确传递和拼接。