电池类设备低功耗安全握手方案设计与优化实战

1. 项目概述与核心痛点

1.1 为什么“安全握手”会成为电池类设备的头号难题

做硬件这么多年，我最怕的不是功能做不出来，而是功能做出来了，设备却活不过一个冬天。电池类智能设备，从蓝牙门锁、温湿度传感器到智能穿戴，几乎都绕不开同一个矛盾：要在极低的功耗预算里，完成一次足够安全、足够可靠的通信握手。

打个比方，这就像让一个守门员在电量只剩 5% 的手机上，既要省电，又要在 200 毫秒内完成身份验证、密钥协商、数据校验三个动作，还得防着有人伪造门禁卡混进来。传统设备可以放开膀子跑，电池设备不行，每 1mA 的电流都可能是压垮续航的最后一根稻草。

我自己踩过最深的一个坑，是在做一款电池供电的智能门锁时遇到的问题。当时固件里用了标准的 TLS 握手，安全是安全了，但一次完整的握手要消耗将近 15mA 的峰值电流，持续 800 多毫秒。结果就是，一颗 CR2032 纽扣电池原本能撑一年，实际只撑了 7 个月。从那时起我才真正意识到：在电池类设备上，安全握手从来不是“能不能实现”的问题，而是“如何在预算内实现”的问题。

1.2 低功耗与安全握手之间的天然矛盾

先说清楚，为什么低功耗和安全握手是一对天生的冤家。

安全握手的本质，是双方在建立通信前完成三件事：身份认证、密钥协商、完整性校验。这三件事背后都是计算。计算就要消耗电流，而电池设备最缺的就是电流。更麻烦的是，通信本身也要耗电——射频发射的瞬间电流往往是全系统最高的。

低功耗设计的核心思想，是“能不工作就不工作，能少工作就少工作”。设备大部分时间处于休眠状态，电流低到微安级别，只在需要通信时被唤醒，完成数据传输后再立刻睡回去。

这两者撞在一起就很尴尬：安全握手需要足够的计算资源和通信时间，而低功耗要求尽可能减少计算和通信。如果设计不当，一场握手就能吃掉设备一周的休眠电量。

真正成熟的低功耗安全握手方案，不是在这两者之间找平衡点，而是从架构上同时满足两者的需求。我会在下面几个章节里，把我实际用过的方案、踩过的坑、优化过的参数全部摊开来讲。

2. 整体设计思路与方案选型

2.1 常见低功耗安全握手方案盘点

市面上能用的方案不算少，但真正适合电池类设备的没几个。我把主流路线梳理了一遍，方便大家对号入座。

第一种，标准 TLS/DTLS 握手。这是最“正统”的方案，安全性经过大规模验证，代码库成熟。但对电池设备太不友好了，握手流程里的证书链验证、随机数交换、多轮往返通信，随便哪一个环节都是耗电大户。实测在 Cortex-M0+ 内核、主频 48MHz 的 MCU 上跑标准 DTLS 握手，最坏情况耗时超过 1 秒，峰值电流 20mA 以上。除非你有足够大的电池，否则别碰。

第二种，预共享密钥加 AES 加密。这是目前电池类设备最主流的选择。设备出厂时烧录一个唯一密钥，握手时只需要一次通信，双方用预共享密钥生成会话密钥，配合 AES-CCM 或 AES-GCM 完成认证和加密。整个过程计算量小，通信次数少，非常适合资源受限场景。

第三种，基于物理不可克隆函数的方案。利用芯片制造过程中产生的物理差异生成唯一指纹，不需要在设备里存储密钥，防物理拆解能力很强。但这套方案对芯片有特殊要求，不是每颗 MCU 都支持，而且算法库不通用，适合安全等级要求极高的场景，比如支付终端。

第四种，轻量级认证协议，比如对 HMAC 或 CBC-MAC 进行简化。这类方案的好处是代码量极小，但设计难度很高，如果协议设计者对密码学理解不够，很容易引入中间人攻击或重放攻击风险。我不太建议自己发明协议，行业内已经有大量案例证明“自研认证协议”最后都成了安全漏洞重灾区。

我自己最终采用的是第二套方案，预共享密钥加 AES-CCM。原因很直接：一是 MCU 资源占用小，二是一次握手就能完成认证和密钥协商，三是行业内已经有成熟的实现可以参考。

2.2 一次握手的耗能模型拆解：钱花在哪里

做低功耗设计，你不能大概估计“应该挺省电”，你得把每一毫秒、每一微安都算清楚。我习惯在项目开始时先建一个耗能模型，把所有参与者的能耗加起来，看看预算够不够。

一次完整的安全握手，能耗主要由三部分组成：

射频发射能耗。这是大头中的大头。以 nRF52832 为例，0dBm 发射功率下，发射电流约 5.3mA，发射时间取决于数据包长度。蓝牙 4.2 的数据包，一个 20 字节的握手请求包，实际空中时间约 200 微秒。虽然时间很短，但电流高，折算下来单次发射能量约 1.06 微库仑。

射频接收能耗。接收状态下电流约 5.8mA，接收窗口通常比发射窗口长，因为要监听对方的响应。如果握手需要两个往返，接收时间轻松超过 1 毫秒。

计算能耗。以 AES-128-CCM 为例，在带硬件加密引擎的 MCU 上，加密一个 16 字节的数据块只需几个微秒，电流约 2mA，能量消耗几乎可以忽略。但如果 MCU 不带硬件加解密单元，用软件实现 AES，耗时可能达到几十毫秒，电流 6mA 以上，这就不能忽视了。

我做一个简单的换算。假设设备每天唤醒 50 次，每次都做一次安全握手，单次握手消耗 3 毫库仑能量。一天的握手总能耗约 150 毫库仑。而一颗 220mAh 的锂电池，总电量约 792 库仑。如果只算握手能耗，设备可以用 14 年。但加上休眠漏电、传感器采集、数据上报等开销，真实续航会大幅缩水。这也是为什么握手方案再小，也要抠细节的原因——每一项节省都在给整机续航做贡献。

2.3 选型时最容易忽略的三个硬指标

很多初学者选方案时只看“支持 AES”“支持 DTLS”，忽略了一些更底层的指标。我梳理了三个最容易踩坑的硬指标。

第一个是 MCU 是否带硬件加密引擎。同样跑 AES-128-CCM，带硬件引擎的 MCU 和纯软件实现的差距是数量级的。我曾经在 STM32L0 系列上对比过：硬件引擎只需 12 微秒完成一次块加密，而软件实现需要 320 微秒。别小看这 300 微秒的差距，握手过程中可能要做几十次块加密，多出来的时间意味着 MCU 要在高频状态停留更久，电流自然更高。

第二个是射频芯片的启动时间。很多低功耗蓝牙芯片在休眠后重新进入收发状态需要时间，从几百微秒到几毫秒不等。这个时间看似不长，但射频电路在这个阶段的电流往往很高。选芯片时一定要看数据手册里的 TX/RX settle time，越小越好。

第三个是随机数生成器是否够快。安全握手需要随机数做 nonce，如果 MCU 的随机数生成器需要等待外部熵源积累才能产生足够随机的值，等待期间 MCU 也是醒着的，也在耗电。我见过有人用软件伪随机种子替代，结果被重放攻击打穿，这个便宜不能占。

3. 核心细节解析与实操要点

3.1 低功耗状态机设计：从“常驻监听”到“按需唤醒”

在开始写握手代码之前，首先要解决一个更基础的问题：设备怎么知道自己该握手了？

很多低功耗设备失败在状态机设计上。如果设备一直保持射频接收状态，等主机来连接，功耗必然高。正确做法是让设备进入深度休眠，只用极低功耗的定时器或外部中断唤醒。

我常用的状态机是：

• 深度休眠态（Sleep）：MCU 进入 STOP 模式或 Standby 模式，电流典型值在 1-3 微安。此时射频模块完全关闭，只有一个低频时钟或 GPIO 中断在待命。
• 唤醒态（Wake-up）：定时器溢出或外部事件触发，MCU 开始启动，时钟切换到高速晶振，电流爬升到 3-5mA。
• 握手态（Handshake）：射频模块上电，执行安全握手流程，电流峰值可能到 10-20mA。
• 工作态（Working）：握手成功后，按业务需求采集数据并上报，电流根据传感器不同而不同。
• 回归休眠态（Back to Sleep）：所有任务完成后，保存现场，关闭外设，回到深度休眠。

这里有个关键细节：状态切换之间的“过渡时间”最容易耗电。比如从深度休眠到唤醒态，如果 MCU 的时钟稳定时间很长，系统会在中间状态停留很久，电流虽然不是最高，但时间拉长了，总能耗反而上升。选 MCU 时一定要看数据手册里的“Wake-up time from low-power mode”，这个指标直接决定了状态切换的能耗。

3.2 安全握手的报文格式设计

既然选用预共享密钥加 AES-CCM 方案，握手报文的设计就不能随意。我见过不少项目直接在数据包里塞一个加密字段就完事，结果缺少防重放保护，被攻击者抓包重放直接攻破。

一个我目前在用的紧凑报文结构是这样的：

• 设备 ID（2 字节）：全局唯一的设备标识，用于主机识别设备身份。
• 随机数（8 字节）：每次握手时由设备端重新生成，防止重放攻击。这个随机数必须来自硬件真随机数生成器，不能用伪随机替代。
• 时间戳（4 字节）：可选的，但如果有时间同步能力，加入时间戳可以进一步缩短随机数长度。没有时间同步就老老实实用 8 字节随机数。
• 密文（16 字节）：AES-CCM 输出的密文，内容是设备状态、会话密钥请求等关键信息。
• 消息认证码（4-8 字节）：AES-CCM 自带的完整性校验码，确保报文没有被篡改。

整个报文长度控制在 40 字节以内。在蓝牙 4.2 的 20 字节 MTU 限制下，可能需要拆包或使用扩展数据包。在蓝牙 5.0 及以上，可以用 255 字节的扩展广播包或连接事件，一次就能发完。

这里的核心取舍是随机数和消息认证码的长度。随机数越长越安全，但报文越长，射频发射时间越长，功耗越高。8 字节随机数配合 4 字节消息认证码，在多数物联网场景下已经足够。如果设备生命周期内握手次数不多，这个长度可以再压缩。

3.3 基于 nRF52 系列的硬件配置参考

一直讲理论没意思，放一套我实测过的硬件配置供参考。这套配置用 nRF52832 做蓝牙通信，STM32L071 做主控，电池是 220mAh 锂电池。实际量产的设备，续航从初版的 7 个月提升到了 14 个月以上。

主控 STM32L071 的关键配置：

• 系统时钟：握手期间使用 32MHz 高速时钟，休眠前切换到 32.768kHz 低速时钟。不能一直跑高速时钟，即使是在等待握手响应的间歇期，也要把时钟降下来。
• 低功耗模式：握手完成后进入 STOP 模式，配合 RTC 定时器唤醒，唤醒后直接进握手流程。RTC 唤醒时间误差控制在 50ppm 以内，避免频繁的时钟校准增加功耗。
• ADC 外设：采集电池电压用，只在工作态开启。不要用轮询方式检测电压，用定时器触发单次转换，转完立刻关闭 ADC 电源。
• 硬件 AES：STM32L0 系列自带 AES 硬件加速，这部分必须用起来，软件 AES 的功耗代价太大。

蓝牙 nRF52832 的关键配置：

• 广播间隔：200ms 可连接广播，这个值可以根据业务实时性要求调整。广播间隔越长越省电，但主机扫描到设备的时间越长。200ms 是一个兼顾功耗和发现时延的经验值。
• 发射功率：0dBm。在室内复杂环境下，-20dBm 可能导致连接不稳定，4dBm 功耗上升明显。0dBm 是大多数场景下的甜点。
• 连接事件间隔：30ms。握手需要在连接事件里快速交换数据，间隔太短会频繁唤醒射频模块，太长会导致握手延迟被拉长。
• 从机延迟：0，握手过程不启用从机延迟，保证每次连接事件都能快速响应。

这组参数在蓝牙信号 -70dBm 以上时，一次握手的平均功耗约为 8mA 持续 50ms，换算成能量约 0.4 毫库仑。加上传感器采集和数据上报，整机平均电流能做到 30 微安以下。

4. 实操过程与核心环节实现

4.1 硬件平台搭建与低功耗模式初始化

第一步，先搭好最小系统。主控用 STM32L071，射频模块用 nRF52832，两者之间通过 SPI 通信。为什么不用主控直接集成蓝牙？因为产品后续可能更换不同协议栈的射频芯片，独立的射频模块方案更灵活。

主控侧初始化代码核心是配置低功耗模式。直接贴一段实用代码：

void enter_stop_mode(uint32_t wakeup_time_ms) { // 关闭不必要的外设时钟 __HAL_RCC_GPIOA_CLK_DISABLE(); __HAL_RCC_GPIOB_CLK_DISABLE(); // 保持必要引脚为输出低电平，避免悬空漏电 HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); // 配置RTC定时唤醒 RTC_AlarmTypeDef alarm = {0}; alarm.AlarmTime.Seconds = wakeup_time_ms / 1000; alarm.AlarmMask = RTC_ALARMMASK_ALL; HAL_RTC_SetAlarm_IT(&hrtc, &alarm, RTC_FORMAT_BIN); // 进入STOP模式 HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI); // 唤醒后重新配置系统时钟 SystemClock_Config(); }

这段代码里有两个细节值得注意。第一，进入 STOP 模式前必须关闭所有不必要的外设时钟，否则外设漏电会把休眠电流拉高。第二，唤醒后必须重新配置系统时钟，因为 STOP 模式会丢失高速时钟配置，如果忘记重新初始化，后续代码跑在低速时钟上，功耗和时序全部失控。

射频模块 nRF52832 的初始化也有讲究。SDK 默认的初始化流程会打开很多默认服务，我们需要精简到只保留必要的外设：

void ble_init(void) { ret_code_t err_code; // 关闭不需要的协议栈特性，减少RAM和功耗 ble_enable_params_t ble_enable_params; memset(&ble_enable_params, 0, sizeof(ble_enable_params)); err_code = sd_ble_enable(&ble_enable_params); APP_ERROR_CHECK(err_code); // 配置广播参数，间隙200ms，不可连接广播 ble_gap_adv_params_t adv_params; memset(&adv_params, 0, sizeof(adv_params)); adv_params.type = BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED; adv_params.interval = MSEC_TO_UNITS(200, UNIT_0_625_MS); adv_params.timeout = 0; // 不自动停止广播 err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &adv_params); APP_ERROR_CHECK(err_code); // 设置发射功率为0dBm sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV, m_adv_handle, 0); }

这里的广播类型选择很关键。很多新手会选不可连接广播，因为可以在广播数据里直接携带信息，省去建立连接的功耗。但不可连接广播无法完成双向认证握手，只能单向发送数据。对于需要安全握手的场景，必须用可连接广播，在连接事件里完成双向认证。

4.2 安全握手的核心代码实现

接下来是整篇文章最核心的部分：安全握手的具体实现。我以 STM32L071 主控侧的逻辑为例。

整个握手流程分为四步：

第一步，设备端生成随机数并启动计时器。

void handshake_start(void) { // 从硬件RNG获取8字节随机数 uint8_t nonce[8]; HAL_RNG_GenerateRandomNumber(&hrng, (uint32_t *)&nonce[0]); HAL_RNG_GenerateRandomNumber(&hrng, (uint32_t *)&nonce[4]); // 保存到握手上下文 handshake_ctx.nonce_len = 8; memcpy(handshake_ctx.nonce, nonce, 8); // 记录起始时间，用于后续的超时判断 handshake_ctx.start_tick = HAL_GetTick(); // 通过SPI发送握手请求给nRF52832 spi_transmit_handshake_request((uint8_t *)&handshake_ctx, sizeof(handshake_ctx)); }

注意这里用两次 HAL_RNG_GenerateRandomNumber 拼接 8 字节随机数，因为 STM32L0 系列的硬件 RNG 一次生成 32 位随机数。有些人图省事用伪随机替代，这在安全握手里是致命的。攻击者一旦预测出 nonce，就能构造重放报文绕过认证。

第二步，射频模块发送握手请求，等待主机响应。

void ble_handshake_timeout_handler(void) { // 等待主机响应，超时时间500ms if (HAL_GetTick() - handshake_ctx.start_tick > HANDSHAKE_TIMEOUT_MS) { // 超时后进入休眠，等待下一次唤醒 enter_stop_mode(BACKUP_WAKEUP_INTERVAL_MS); } }

第三步，收到主机响应后，用预共享密钥解密并验证。

bool handshake_verify(uint8_t *rx_data, uint16_t rx_len) { // 解包：设备ID + 随机数(8) + 密文(16) + MAC(8) if (rx_len != 2 + 8 + 16 + 8) { return false; } // 检查设备ID是否匹配 if (memcmp(rx_data, &g_device_id, 2) != 0) { return false; } // 检查随机数是否与请求一致，防止重放 if (memcmp(rx_data + 2, handshake_ctx.nonce, 8) != 0) { return false; } // 用预共享密钥解密 uint8_t plaintext[16]; uint8_t key[16] = {0x00, 0x01, 0x02, ...}; // 出厂烧录的唯一密钥 struct AES_ctx ctx; AES_init_ctx(&ctx, key); AES_ECB_decrypt(&ctx, rx_data + 2 + 8); memcpy(plaintext, rx_data + 2 + 8, 16); // 验证MAC，这里用AES-CMAC实现 uint8_t mac[8]; AES_CMAC(key, rx_data, 2 + 8 + 16, mac, 8); if (memcmp(mac, rx_data + 2 + 8 + 16, 8) != 0) { return false; } // 握手成功，提取会话密钥 memcpy(handshake_ctx.session_key, plaintext, 16); return true; }

很多人会忽略随机数回显验证这一步，只验证 MAC。但随机数回显是防重放的第一道防线——攻击者录下上一次握手的报文，原样重发，如果系统不检查随机数新鲜性，直接就会通过。虽然 MAC 也能起到一部分防重放作用，但显式的随机数回显更直观、更可靠。

第四步，握手成功后切换通信数据加密。

void handshake_complete(void) { // 使用会话密钥替换预共享密钥 memcpy(g_current_key, handshake_ctx.session_key, 16); // 重置会话计数器 g_packet_counter = 0; // 进入正常数据收发流程 data_transfer_loop(); }

4.3 关键参数的计算与选择过程

参数设置的依据，我必须展开讲清楚，方便你根据自己的项目做调整。

握手超时时间为什么定 500ms？这个值等于主机扫描设备的最大间隔（这里是 200ms）加重试次数（2 次）再加上安全余量。如果主机扫描间隔是 100ms，超时时间可以缩短到 300ms。超时时间太长，设备在等待阶段耗电多；太短，可能因为主机调度问题误判超时，导致握手失败率上升。

广播间隔为什么定 200ms？主机侧扫描窗口通常设为 20-30ms，扫描间隔设为 100-200ms。从概率上讲，200ms 的广播间隔与 150ms 的扫描间隔相遇的概率约 90%。如果你的业务允许更长的发现时延，可以把广播间隔放宽到 500ms甚至 1 秒，功耗能显著降低。

发射功率为什么用 0dBm？根据自由空间路径损耗公式，2.4GHz 频段下，10 米距离的信号衰减约 60dB。如果接收灵敏度是 -90dBm，0dBm 发射功率在 10 米外还能剩 -60dBm 左右的余量，链路余量 30dB，足够应对室内多径衰落了。实测在普通住宅环境下，穿一堵墙没有问题。

4.4 nRF52 侧关键配置与 Flutter 应用层注意事项

搜热词的时候看到有人在问“Flutter 低功耗蓝牙 iOS 有问题嘛”，这个问题我太有发言权了。Flutter 在 iOS 上的低功耗蓝牙支持，最大的坑在于 iOS 系统的后台模式限制和 CoreBluetooth 的状态管理。

先说结论：Flutter 的 flutter_blue_plus 插件在 iOS 上基本可用，但有几个坑：

第一个坑是 iOS 不允许 App 在后台长时间扫描或广播。如果你的设备需要在后台保持 BLE 连接，必须在 Info.plist 里声明 UIBackgroundModes 包含 bluetooth-central 和 bluetooth-peripheral，否则 App 一旦进入后台，蓝牙活动会被系统挂起，握手流程直接中断。

第二个坑是 iOS 的 MTU 协商和 Android 不同。Android 侧默认 MTU 是 23 字节，iOS 通常是 185 字节。如果你在 Android 上开发时没有适配大 MTU，报文长度超过 20 字节就无法发送。我建议在握手流程开始时，先主动请求一个较大的 MTU，比如 247 字节，再执行握手，避免报文被截断。

第三个坑是 Flutter 的连接状态回调在 iOS 上存在延迟。iOS 的 didDisconnect 回调经常比实际断开晚几百毫秒甚至几秒。如果你的握手流程依赖连接状态切换触发超时控制，建议用应用层的握手计时器，不要依赖系统回调。

下面这段 Flutter 代码我实测可以稳定完成 BLE 连接和握手请求发送：

Future<bool> secureHandshake() async { final bluetooth = FlutterBluePlus.instance; // 连接设备，超时10秒 await bluetooth.connect(device, timeout: Duration(seconds: 10)); // 获取服务与特征 final services = await device.discoverServices(); final service = services.firstWhere((s) => s.uuid == ServiceUuid.handshake); final characteristic = service.characteristics .firstWhere((c) => c.uuid == CharacteristicUuid.secure); // 请求大MTU，避免报文截断 await bluetooth.requestMtu(247); // 构造握手请求 final request = buildHandshakeRequest(); // 写入握手请求 await characteristic.write(request, withoutResponse: false); // 等待响应并解析 final response = await characteristic.read(timeout: Duration(seconds: 2)); return parseHandshakeResponse(response); }

注意请求大 MTU 后，有些 Android 设备会要求你重新发现服务，因为 MTU 变化后特征列表可能刷新。实测在 Android 10 以上设备，请求 MTU 后必须调用一次 discoverServices，否则后续读写会报 GATT_ERROR。这个坑我花了一个下午才定位到。

5. 常见问题与排查技巧实录

5.1 握手耗电过高，一测电流就打脸

这个问题的出现频率极高。很多工程师信心满满地把设备拿去测功耗，结果发现平均电流比设计值高了十倍。

我总结的排查顺序如下：

第一步，先量休眠电流。断开所有外部连接，让设备进入深度休眠，用万用表微安档测整机电流。如果休眠电流超过 10 微安，优先排查 GPIO 悬空、外部上拉电阻漏电、LDO 静态功耗这三样。最常见的是 GPIO 悬空导致输入浮空，电流从 MCU 引脚直接漏到地。解决办法是在休眠前把所有 GPIO 设置为模拟输入或输出低电平。

第二步，再量唤醒瞬间的电流波形。用示波器电流探头或低功耗电流分析仪捕捉从唤醒到休眠的完整电流曲线。重点看是否有额外的“毛刺”电流。我遇到过一次，原因是 SPI 片选引脚在休眠前没有拉高，导致射频模块一直处于片选状态，电流凭空多了 5mA。

第三步，检查射频模块的启动时间。很多蓝牙芯片从 sleep 到 TX/RX 就绪需要一段时间，如果代码里在启动射频模块前没有等待其就绪，会出现信号发不出去，然后重试，进一步抬高功耗。在协议栈日志里查看连接事件处理时间，如果超过预期值，多半是射频启动参数配置问题。

5.2 握手偶尔失败，重试逻辑越写越复杂

有时不是功耗问题，而是握手稳定性问题。我遇到过的情况是：十次握手有九次成功，一次失败。失败的原因通常不是安全逻辑，而是时序碰撞。

典型案例：主机在广播间隔的窗口期扫描设备，设备在此时正好发起连接请求，但主机正处于休眠，连接建立失败。解决方法是把广播间隔抖动一下，避免设备和主机的扫描节奏形成固定的相位关系。

另一个典型案例是握手响应超时。设备发出握手请求后，主机在 2 秒内没有响应。排查后发现是主机的 GATT 写入响应回调没有正确触发，导致设备一直等待。这种情况不是修改设备逻辑能解决的，需要在主机侧加超时重试。重试策略我建议用指数退避：第一次等待 500ms，第二次 1 秒，第三次 2 秒，最多三次。不要用固定间隔频繁重试，会把设备功耗拖垮。

5.3 安全校验总是不通过：随机数与 MAC 的坑

这个坑是最隐蔽的。安全校验失败时，先看随机数匹配是否通过。如果不通过，就要怀疑设备是否重复使用了相同的随机数。我曾在量产固件中发现，硬件 RNG 在刚上电时会有一段输出序列质量不稳定的时期，如果此时调用 RNG，生成的随机数可能重复或可预测。解决办法是在初始化时预留熵积累时间，或者多次读取 RNG 结果做混合校验。

如果随机数匹配通过但 MAC 校验失败，优先检查通信过程中数据包是否被拆包重装。我遇到过一个问题：因为 MTU 限制，握手报文被拆成两个包发送，接收端在重组时使用了不同字节序，导致 MAC 校验失败。增加一个统一的字节序转换工具函数，在报文封装和解析时调用，能避免这类问题。

还有一个容易忽略的坑：AES-CMAC 和 AES-CCM 都要求密钥长度固定为 16 字节，如果预共享密钥在烧录时使用了变长字符串，加密时会自动补齐或截断，导致握手双方使用的实际密钥不一致。我一直坚持在固件里对密钥做哈希处理，统一转成 16 字节定长格式。

5.4 常见问题速查表

5.5 一块电池用一年：实测续航数据复盘

最后放一组实测数据。我用同一套硬件方案做了两版固件，第一版没有做低功耗优化，第二版按本文的方法完成优化。在相同使用场景下：每天唤醒 50 次，每次握手加数据上报，配备 220mAh 锂电池。

休眠电流从 12 微安降到 2.8 微安，是续航提升的最大功臣。这部分的优化主要是关闭了射频模块的独立供电轨，以及重新配置了所有 GPIO 的电平状态。

单次握手功耗从 18mA 降到 8mA，主要归功于把软件 AES 换成硬件 AES，以及压缩了报文长度。加密耗时从原来的 320 微秒降到了 14 微秒，几乎可以忽略不计。报文长度从 57 字节压缩到 40 字节，射频发射时间缩短了约 30%。

关于续航，我个人在实际操作中的体会是：低功耗安全握手的优化，永远不是单点突破，而是全链路的系统工程。每一微安、每一毫秒的节省，都需要在设计初期就考虑进去，等产品做完了再回来抠功耗，代价会大得多。如果你正准备做电池类智能设备的通信方案，建议从立项第一天就把安全握手的功耗预算列入需求文档，而不是等到联调阶段才想起这回事。

这套优化方法后续还可以扩展到更多场景，比如把单次握手升级为批量握手机制——设备一次唤醒完成多次数据交换，进一步摊薄握手的固定开销。或者引入动态安全等级，在电量充足时使用更强的认证算法，在低电量时切换到更轻量的模式，在不牺牲安全底线的前提下延长续航。方向很多，但核心思路不变：在功耗、安全、体验之间找到最适合产品定位的那个平衡点。