电池供电的物联网设备做身份认证，最纠结的就是功耗账：一次认证多花几十毫安时，一年下来可能就是续航从十八个月掉到十二个月的差别。这篇从工程角度梳理低功耗认证流程的优化思路，涉及的量级估算基于典型安全认证芯片的公开参数。
先算清楚功耗花在哪
一次完整的认证交互，功耗大头通常不在密码运算，而在这几处：
主控唤醒时间。从休眠到完成认证，主控全速运行的时间越长越费电。优化方向是压缩交互轮次、减少主控等待。
无线收发。如果认证要走网络，射频收发一次的能耗往往是密码运算的几十倍。本地能完成的认证，绝不上云。
非对称运算。ECC/SM2签名比对称运算耗电高一个量级。签名次数能少则少。
五个可落地的优化手法
会话复用，别每次全握手。 设备与云端首次完成完整认证后，缓存会话票据；后续重连用简化流程恢复会话，跳过证书交换和非对称验签。对每天多次唤醒上报的设备，这一项能省掉大部分认证开销。
用对称运算承担高频认证。 首次认证建立信任后，派生会话密钥，后续的数据完整性校验改用SM4/AES这类对称算法做MAC。对称运算在这类安全芯片上是微安级、毫秒级，和非对称运算不是一个功耗量级。
认证与业务合并发送。 把认证响应和业务数据打包在一次射频交互里发出去，避免"认证一次收发、数据再一次收发"的双重开销。
管好安全芯片的功耗档位。 安全芯片工作电流和休眠电流差距很大。以JC100为例，工作模式约1mA，最小工作模式400μA，休眠小于200μA。认证间隙及时让芯片进休眠，按需唤醒，长周期下来差距可观。
本地决策，云端兜底。 配件认证、门锁鉴权这类场景，认证完全可以在本地主机和安全芯片之间闭环，只有异常事件才上报云端。射频一次都不开，功耗自然最低。
一个量化直觉
粗略估算：一次"取随机数+SM2签名+回传"的芯片侧操作，总耗时约百毫秒量级、电流毫安级，单次能耗在微瓦时级，对一枚纽扣电池来说几乎可以忽略；真正要精打细算的是主控唤醒时长和射频交互次数。优化的优先级应该倒过来：先砍射频，再砍主控时间，最后才轮到密码运算本身。
低功耗和安全不矛盾，矛盾的只是不加设计的堆砌。把认证流程按能耗拆开看一遍，优化点自然就浮出来了。
