23、BLE安全编码规范：输入验证、输出编码、会话管理、加密实现、错误处理

聊到BLE开发，很多人第一反应是配对上、数据收发上不出错就行。但说实话，真正让一个蓝牙设备变得“安全”的，往往是那些看起来不起眼的编码细节。我见过太多设备，协议栈选得挺好，加密算法也支持，结果因为代码里一个输入没校验，直接被攻击者用畸形包打穿。

这一章，我就把BLE安全编码里最核心的五个方面掰开揉碎讲清楚。你想想看，如果连输入验证都做不好，后面再强的加密也是白搭。

5.1 输入验证：别信任何外来数据

我在项目中遇到过最典型的案例：某款智能门锁，接收手机APP发来的开锁指令时，直接memcpy到一个固定大小的缓冲区。攻击者只要发一个超长的指令包，就能触发栈溢出，直接拿到代码执行权限。嗯，这就是典型的“信任一切”的后果。

BLE开发中，输入验证要覆盖这几个地方：

• GATT属性值长度校验：每次收到Write Request，先检查长度是否在预期范围内
• UUID合法性检查：别让攻击者传入0xFFFF这种保留值
• 连接参数范围限制：连接间隔、超时时间等，必须做上下限钳制
• 广播数据解析：AD Structure里的长度字段，一定要和实际数据长度比对

// 错误示范：直接信任长度
void on_write_req(uint8_t *data, uint16_t len) {
    memcpy(g_attr_value, data, len);  // 危险！len可能大于缓冲区
}

// 正确做法：先校验长度
void on_write_req(uint8_t *data, uint16_t len) {
    if (len > MAX_ATTR_SIZE) {
        return ATT_ERROR_INVALID_ATTRIBUTE_VALUE_LEN;
    }
    memcpy(g_attr_value, data, len);
}

5.2 输出编码：防止信息泄露

输出编码这块，很多人容易忽略。说白了，就是你在回复数据时，别把不该给的信息带出去。

我曾经调试一个BLE心率设备，发现它在回复错误码时，会把内部状态寄存器的值原样返回。攻击者通过不断触发错误，就能逆向出设备的固件版本、内存布局。这叫什么？这叫“侧信道信息泄露”。

输出编码的几个要点：

• 错误码要抽象：不要返回具体错误原因，统一返回“操作失败”
• 填充数据清零：回复包中未使用的字节，必须显式填0
• 日志输出脱敏：生产固件中，不要打印密钥、配对码等敏感信息
• 广播包内容精简：只广播必要的数据，不要暴露设备内部信息

5.3 会话管理：配对状态的正确维护

会话管理是BLE安全里最容易出bug的地方。你想想看，配对过程涉及多个状态：未配对、配对中、已配对、绑定。每个状态之间的转换，都必须严格校验。

我记得有一次分析一个智能灯泡的固件，发现它在配对完成后，没有清除临时密钥。结果攻击者只要在配对完成后的100毫秒内发送一个特定指令，就能用临时密钥重新加密通信。这就是典型的“会话状态机实现不严谨”。

会话管理的编码规范：

• 状态机要完整：每个状态都要定义合法的输入事件
• 超时处理：配对过程必须有超时机制，超时后自动回退到未配对状态
• 绑定信息保护：存储的长期密钥（LTK）必须加密保存
• 会话重置：断开连接时，必须清除所有临时会话数据

5.4 加密实现：别自己造轮子

加密这块，我的建议就一句话：永远不要自己实现加密算法。BLE协议栈已经提供了AES-CCM加密，直接用就好。

但“直接用”也有讲究。我见过有人直接从协议栈里取出加密后的数据，然后又自己加了一层XOR。问他为什么，他说“这样更安全”。其实恰恰相反，画蛇添足反而可能引入漏洞。

加密实现的正确姿势：

• 使用协议栈API：调用官方提供的加密接口，不要自己拼凑
• 密钥生成要随机：使用硬件随机数生成器，不要用rand()
• IV/Nonce管理：每个包都要使用不同的Nonce，避免重放攻击
• 加密范围要完整：确保整个payload都被加密，不要漏掉头部

// 正确：使用协议栈的加密接口
ble_status_t encrypt_packet(uint8_t *plaintext, uint16_t len, 
                            uint8_t *ciphertext) {
    // 使用BLE协议栈提供的AES-CCM加密
    return ble_encrypt(plaintext, len, ciphertext, &g_enc_ctx);
}

// 错误：自己实现加密
void my_encrypt(uint8_t *data, uint16_t len) {
    for (int i = 0; i < len; i++) {
        data[i] ^= 0xAA;  // 这叫异或，不叫加密
    }
}

5.5 错误处理：优雅地失败

错误处理是安全编码的最后一道防线。很多攻击之所以能成功，就是因为设备在出错时“反应过度”或“反应不足”。

我调试过一个BLE血糖仪，当收到非法指令时，它会直接复位。攻击者只要持续发送非法指令，就能让设备不断重启，实现拒绝服务攻击。这就是“反应过度”的典型。

错误处理的编码规范：

• 失败要安静：出错时不要打印详细错误信息到空中接口
• 状态要回退：出错后回到安全状态，不要停留在中间状态
• 资源要释放：异常路径中，确保所有分配的资源都被释放
• 重试要限速：连续失败后，增加重试间隔，防止暴力破解

知识体系总览

下面这张图，把BLE安全编码的五个核心维度串起来了。你可以把它当作开发时的检查清单。

这五个方面，说白了就是一套“防守思维”。你写每一行代码时，都要假设攻击者就在对面，正盯着你的每一个接口。只有把这种思维刻进骨子里，才能写出真正安全的BLE应用。