第2章核心概念

2、核心概念：配对(Pairing)、绑定(Bonding)、加密(Encryption)、鉴权(Authentication)

好，咱们直接进入正题。这四个词——配对、绑定、加密、鉴权——是 BLE 安全体系的基石。很多新手容易搞混，觉得它们是一回事。其实不然。

我打个比方你就明白了：配对是“握手认识”，绑定是“存下名片”，加密是“说悄悄话”，鉴权是“验明正身”。各有各的活，缺一不可。

配对，说白了就是两个蓝牙设备第一次见面时，互相交换能力信息、协商安全参数的过程。它本身不加密数据，只是为后续的加密和鉴权做准备。

我个人习惯把配对分成三个阶段：

第一阶段：能力交换——双方告诉对方“我能做什么”。比如支不支持 MITM 保护、有没有输入输出能力（键盘、显示屏、NFC 等）。
第二阶段：密钥生成——根据第一阶段的能力，双方协商出一个临时密钥（TK，Temporary Key），然后派生出短期密钥（STK，Short Term Key）或长期密钥（LTK，Long Term Key）。
第三阶段：传输密钥——把生成的密钥分发给对方，用于后续加密。

重点来了：配对完成后，如果设备没有执行绑定操作，那么一旦断开连接，所有密钥都会丢失。下次再连，还得重新配对。

我在项目中遇到过一个问题：某款智能门锁每次开锁都要重新配对，用户体验极差。后来一查，就是代码里没做绑定，只做了配对。嗯，这个坑我踩过。

绑定是配对的“后续动作”。它把配对过程中生成的长期密钥（LTK）、身份解析密钥（IRK）等信息，永久存储在设备本地。

为什么要绑定？你想想看，如果每次连接都要重新配对，那蓝牙耳机岂不是每次都要重新输入 PIN 码？太反人类了。

绑定后，设备再次连接时，可以直接使用存储的密钥进行快速加密，这个过程叫“重新连接”（Reconnection），不需要再走一遍完整的配对流程。

概念	存储内容	生命周期
配对	临时密钥（STK）	仅当前连接有效
绑定	长期密钥（LTK）、IRK、CSRK 等	永久存储，跨连接有效

我的建议：如果你的产品是消费类设备（如手环、耳机），一定要做绑定。否则用户会骂娘的。工业场景下，有些一次性连接设备反而可以不绑定，省去存储开销。

加密是 BLE 安全的核心目的之一。它确保数据在无线传输过程中，即使被截获，也无法被解读。

BLE 5.0 使用 AES-128 加密算法，基于 CCM 模式（Counter with CBC-MAC）。这个算法同时提供加密和完整性校验，一举两得。

加密的流程大致是这样：

// 伪代码示例：加密过程
session_key = AES_128(LTK, SKRand);
encrypted_data = AES_CCM_encrypt(session_key, plaintext, nonce);

注意：加密只保护数据内容，不保护数据长度和时序。攻击者仍然可以通过分析数据包长度或时间间隔来推断信息。这叫侧信道攻击，我后面会专门讲。

我曾经调试过一个 BLE 心率设备，发现数据偶尔解密失败。折腾了两天，最后发现是双方使用的 nonce（一次性随机数）不同步导致的。加密这东西，差一个 bit 都不行。

鉴权，就是验证对方身份的真实性。在 BLE 里，鉴权通常和加密一起出现，但它们是两回事。

举个例子：加密保证数据只有你能看，但鉴权保证跟我说话的人真的是你，而不是冒充的。

BLE 5.0 支持两种鉴权方式：

鉴权的核心在于“密钥验证”。配对过程中，双方会交换一个确认值（Confirm Value），这个值是基于 TK 和随机数计算出来的。如果双方计算出的确认值一致，说明它们持有相同的 TK，身份验证通过。

一句话总结：配对是过程，绑定是结果，加密是手段，鉴权是保障。四者配合，才能构建一个安全的 BLE 连接。

最后，分享几个我在实际项目中遇到的坑，希望能帮你少走弯路：

坑一：只加密不鉴权——数据是加密了，但谁都能连。攻击者可以冒充合法设备，虽然看不懂数据，但可以发送伪造指令。我曾经见过一个智能灯泡，就是这种设计，结果被人用来整栋楼闪灯。
坑二：绑定信息不加密存储——LTK 存在 Flash 里，明文。如果设备被物理破解，密钥直接暴露。我建议至少用设备唯一 ID 做一次 XOR 混淆。
坑三：忽略 MITM 保护——很多开发者觉得“我的产品不需要那么高安全”，结果被中间人攻击搞到崩溃。尤其是 IoT 设备，一旦被中间人控制，后果很严重。
坑四：随机数生成器太弱——BLE 安全大量依赖随机数。如果随机数可预测，整个加密体系就形同虚设。我见过某芯片的硬件随机数生成器，复位后前 10 次生成的随机数竟然是一样的……

好了，这四个核心概念就讲到这里。下一章我会深入讲解配对的具体流程和密钥派生算法，到时候咱们再细聊。