4、配对阶段二：传统配对 vs LE Secure Connections

好，咱们接着聊配对阶段二。

如果说阶段一是「握手认识」，那阶段二就是「正式谈合作」了。这个阶段的核心任务只有一个：生成一个双方共享的密钥（LTK）。没有这个密钥，后续的加密通信就是空谈。

BLE 5.0 里，阶段二有两种走法：传统配对（Legacy Pairing）和LE Secure Connections。我当年刚接触蓝牙时，也搞不清这俩到底差在哪。后来踩了几个坑，才算真正理解。

4.1 传统配对：老路子，但还在用

传统配对是 4.0/4.1 时代的产物。它的核心机制是 TK（Temporary Key），一个临时密钥。

说白了，双方先约定好一个 TK，然后用这个 TK 去加密后续的交换过程，最终生成 STK（Short Term Key），再导出 LTK。

这里有个关键点：TK 怎么来的？

• Just Works：TK 直接设为 0。你没看错，就是全零。安全性？基本为零。
• Passkey Entry：一方显示一个 6 位数字，另一方输入。TK 就是这个数字。
• OOB（Out of Band）：通过 NFC 或其他带外方式交换 TK。

4.2 LE Secure Connections：新方案，更安全

到了 BLE 4.2，蓝牙 SIG 终于看不下去了，推出了 LE Secure Connections。到了 5.0，这已经是标配。

它的核心变化是：用 ECDH（椭圆曲线 Diffie-Hellman）密钥交换代替了 TK 机制。

具体流程是这样的：

1. 双方各自生成一对 ECDH 公私钥。
2. 交换公钥。
3. 用各自的私钥和对方的公钥，计算出共享的 DHKey。
4. 再用 DHKey 派生出 LTK。

你想想看，即使攻击者能监听所有通信，没有私钥他也算不出 DHKey。这就是非对称加密的魅力。

4.3 两种方式的对比

我整理了一个表格，方便你对照着看：

4.4 Numeric Comparison：LE Secure Connections 的杀手锏

LE Secure Connections 引入了一个新玩法叫 Numeric Comparison。这玩意儿在传统配对里是没有的。

流程是这样的：

• 双方各自计算一个 6 位数字的确认值。
• 显示在屏幕上。
• 用户比对两个数字是否一致。
• 如果一致，确认；否则取消。

为什么这能防中间人攻击？因为攻击者虽然能转发数据，但他无法伪造确认值——他没有私钥。用户只要看到两边数字一样，就说明通信没有被篡改。

4.5 实际开发中的选择建议

嗯，这里要注意，不是所有场景都能用 LE Secure Connections。你得看实际情况：

• 如果设备只支持 BLE 4.0/4.1：没得选，只能用传统配对。
• 如果设备支持 BLE 4.2+：优先用 LE Secure Connections。
• 如果设备没有显示屏：LE Secure Connections 下只能用 Just Works（虽然它也用 ECDH，但缺少用户确认环节，抗中间人能力有限）。
• 如果设备有显示屏和按钮：上 Numeric Comparison，这是目前最安全的方案。

4.6 小结

传统配对和 LE Secure Connections，说白了就是「老办法」和「新办法」的区别。老办法简单但漏洞多，新办法安全但要求高。

我个人习惯是：只要条件允许，一律上 LE Secure Connections + Numeric Comparison。如果设备实在没有显示能力，那就用 Just Works，但一定要在应用层做额外的安全加固（比如加一层应用层加密）。

下一节，咱们会深入讲讲 密钥派生的具体算法，看看 LTK 到底是怎么从 DHKey 里算出来的。到时候我会带你看一段实际的代码实现。