3、BLE安全协议栈：SM（安全管理器）层解析、LL（链路层）加密机制、ATT/GATT安全属性、密钥生成与分发
好，咱们今天聊点硬核的。BLE的安全协议栈，说白了就是一套“谁可以连、连上能干啥、数据怎么加密”的规则体系。很多开发者只调API，从没深究过底层，结果产品一上测试就翻车。我当年就吃过这个亏——一个智能门锁项目，配对流程看着没问题，结果被中间人攻击直接破防。嗯，从那以后，我把整个SM层和LL层啃了个透。
这一节，我会把SM层、LL加密、ATT/GATT安全属性、密钥分发这几个核心模块拆开揉碎。你跟着我的思路走，保证能建立起完整的BLE安全认知框架。
核心要点：BLE安全不是单一机制，而是SM（安全管理器）+ LL（链路层）+ ATT/GATT（应用层）三层协同的结果。任何一层出问题，整个安全体系就形同虚设。
3.1 SM层：配对与密钥协商的核心
SM层，全称Security Manager，是BLE安全的第一道关卡。它的职责说白了就两件事：配对和密钥分发。
配对流程有四种方式：Just Works、Passkey Entry、OOB（带外）、以及LE Secure Connections。我个人最常用的是Passkey Entry和OOB。为什么？Just Works虽然简单，但它不提供中间人攻击防护——你想想看，两个设备握手时没有任何验证，攻击者完全可以插一脚。
避坑指南：我曾经在一个医疗手环项目里用了Just Works，结果客户的安全审计直接亮红灯。后来改成Passkey Entry + 6位数字显示，才过审。记住：只要产品涉及敏感数据，就别偷懒用Just Works。
LE Secure Connections是蓝牙4.2引入的增强方案，使用ECDH（椭圆曲线Diffie-Hellman）进行密钥协商。相比传统方案，它提供了更强的中间人攻击防护。嗯，这里要注意：Secure Connections需要双方芯片都支持，否则会自动降级。
3.2 LL层加密机制：AES-CCM实战
链路层加密，用的是AES-128的CCM模式。CCM = CTR + CBC-MAC，既加密又做完整性校验。数据包结构里有个MIC字段（Message Integrity Check），就是干这个的。
我刚开始做蓝牙开发时，以为LL层加密是自动的——配完对就万事大吉。后来发现不对：LL层加密需要显式启动，通过LL_START_ENC命令触发。如果主设备不发这个命令，从设备就一直裸奔。
// LL层加密启动流程（伪代码）
// 1. 主设备发送 LL_START_ENC_REQ
// 2. 从设备回复 LL_START_ENC_RSP
// 3. 双方使用 LTK 计算 Session Key
// 4. 后续所有数据包使用 AES-CCM 加密
struct ll_enc_req {
uint8_t opcode; // 0x3E
uint8_t rand[8]; // 随机数
uint16_t ediv; // 加密多样性因子
uint64_t skdm; // 主设备会话密钥
};
// 注意：rand 和 ediv 用于生成 Session Key
// LTK 不直接传输，而是通过 rand + ediv 派生重要提醒：LL层加密只保护空口数据，不保护应用层。如果你的ATT数据本身没有额外加密，攻击者在芯片内部（比如通过调试接口）还是能读到明文。这是很多开发者容易忽略的点。
3.3 ATT/GATT安全属性：权限控制的艺术
ATT/GATT层定义了属性（Attribute）的访问权限。每个属性都有以下安全属性位：
| 属性位 | 含义 | 我的经验 |
|---|---|---|
| 读权限 | 是否需要加密/认证才能读 | 建议所有敏感特征值设为“加密读” |
| 写权限 | 是否需要加密/认证才能写 | OTA升级特征值必须“加密写+认证” |
| 通知/指示权限 | 是否需要加密通道才能接收通知 | 心率数据建议加密通知，防止被嗅探 |
| 认证要求 | 是否需要配对绑定才能访问 | 设备配置特征值必须绑定后才能操作 |
| 授权要求 | 是否需要应用层额外授权 | 高级功能建议加授权，防止越权调用 |
你想想看，如果某个特征值允许“无加密写”，攻击者只要扫描到你的设备，就能直接篡改数据。我在一个智能灯泡项目里就遇到过——攻击者通过未加密的写操作，直接把灯泡固件给改了。
3.4 密钥生成与分发：LTK、IRK、CSRK
BLE定义了三种核心密钥：
- LTK（Long Term Key）：长期密钥，用于LL层加密。128位，配对时协商生成，之后存储在两台设备中。
- IRK（Identity Resolving Key）：身份解析密钥，用于私有地址解析。防止设备被长期追踪。
- CSRK（Connection Signature Resolving Key）：连接签名解析密钥，用于数据签名，不加密但防篡改。
密钥分发发生在配对完成后的“密钥分发阶段”。主设备和从设备会交换各自的密钥。这里有个坑：密钥分发是单向的——主设备发自己的LTK给从设备，从设备也发自己的LTK给主设备。如果某一方不发送，另一方就得不到完整的密钥集。
实战经验：我调试过一个手环，配对后总是断连。抓包发现，从设备在密钥分发阶段没有发送IRK，导致主设备无法解析从设备的私有地址。每次重连时地址不匹配，直接断开。解决方案：确保从设备在配对完成后主动分发IRK。
密钥存储也是个大学问。LTK一旦泄露，攻击者可以解密所有历史通信。我建议：
- LTK存储在安全区域（如TEE或Secure Element）
- 不要以明文形式写入日志
- 固件升级时不要清除绑定信息（除非用户主动解绑）
好了，这一节的内容就到这里。SM层管配对和密钥，LL层管加密传输，ATT/GATT层管访问控制——三层各司其职，缺一不可。下一节我们会深入配对流程的细节，看看Just Works和Passkey Entry在抓包数据里到底有什么区别。