2. 低功耗设备与密码学基础

在讨论密码性能优化之前，必须先建立对“低功耗设备”这一运行载体的准确认识。低功耗设备并不是单一形态，而是一类以电池寿命、能量采集能力或散热上限为硬约束的计算平台。典型代表包括：以 Cortex-M0+/M4 为核心的 BLE 传感器节点、带硬件安全模块的智能门锁、NB-IoT 水表/气表、可穿戴心率带，以及采用 RISC-V 内核的无线标签。它们的共同特征是主频低（常见 8～64 MHz）、SRAM 小（8～256 KB）、Flash 有限（64 KB～1 MB），且往往没有操作系统或只运行 RTOS。

从架构上看，这类设备通常由四个部分构成：计算核心（MCU 内核与协处理器）、存储层次（Flash、SRAM、可选外部存储）、密码加速单元（AES 引擎、TRNG、PKA 公钥加速器）以及通信与电源域（射频、DC-DC/LDO、时钟源）。密码运算的能耗并不只发生在 CPU 上，而是分布在这几个模块之间：CPU 取指与运算消耗动态功耗，Flash 读取带来访问能耗，SRAM 保持与刷新产生静态功耗，射频收发则是峰值功耗的主要来源。因此，优化密码性能本质上是在计算、存储、外设与通信之间重新分配能量预算。

功耗来源可以按“是否与密码运算直接相关”来划分。直接来源包括：算法本身的运算量（如 AES 轮数、ECC 点乘次数）、数据搬运（DMA 或 CPU 拷贝）、密钥调度与随机数生成。间接来源包括：时钟树翻转、外设常开、唤醒次数、以及为等待密码结果而延长的射频开启时间。一个常被忽视的事实是：射频开启 1 ms 的能耗，可能相当于 MCU 全速运行数十毫秒。因此，密码优化的目标往往不是单纯“算得快”，而是“尽快算完并关闭射频”。

密码算法按用途可分为三类：对称加密（AES、ChaCha20）、非对称加密与密钥交换（ECC、RSA、ECDH）、哈希与消息认证（SHA-256、HMAC、Poly1305）。在低功耗设备上，这三类算法的能耗特征差异极大。以常见的 Cortex-M4 @ 48 MHz 为例，AES-128 加密 16 字节数据，纯软件实现约需 2000～4000 个时钟周期，而带 AES 硬件引擎时仅需约 50～100 个周期，能耗可降低一个数量级。ECC P-256 点乘在纯软件下需要数百万个周期，即使有 PKA 加速器，也通常在数万周期量级。SHA-256 对 32 字节数据的哈希约需 1000～2000 周期。这些数量级差异决定了：对称加密适合频繁小数据，非对称加密只用于会话建立或签名，哈希用于完整性校验。

性能指标不能只看“速度”。在低功耗语境下，应同时关注四个维度：延迟（单次运算耗时，影响射频开启窗口）、能量（单次运算消耗的 μJ 或 mJ，决定电池寿命）、吞吐率（单位时间可处理的数据量，影响批量场景）、资源占用（Flash/RAM 开销，决定能否放入小容量 MCU）。例如，一个 BLE 温度传感器每 10 秒上报一次，每次需 AES-CCM 加密 20 字节。若软件 AES 耗时 3 ms、电流 8 mA，则单次能耗约 3 ms × 8 mA × 3.3 V ≈ 79 μJ；若硬件 AES 耗时 0.1 ms、电流 6 mA，则单次能耗约 2 μJ。按每天 8640 次上报计算，两者年能耗差异可达数百焦耳，直接决定纽扣电池能否撑过五年。

在算法分类的基础上，还需要理解“性能指标如何随参数变化”。以 AES 为例，密钥长度从 128 位增加到 256 位，轮数从 10 轮增至 14 轮，软件实现耗时约增加 40%，硬件引擎耗时增加通常小于 20%。ECC 的曲线选择影响更大：P-256 与 Curve25519 在软件实现上周期数接近，但后者在常数时间实现上更友好，侧信道防护开销更低。哈希算法中，SHA-256 与 SHA-512 在 32 位 MCU 上，后者因 64 位运算模拟而显著更慢，通常不用于低功耗设备。

实际工程中，选择密码算法与实现方式时，建议按以下顺序判断：先确认安全需求（加密、认证、签名、密钥交换），再评估数据量与频率，然后对照 MCU 是否具备对应硬件加速单元，最后用“单次能耗 × 每日次数”估算电池预算。若硬件加速不可用，则优先选择软件实现成熟、常数时间友好、RAM 占用低的算法，如 ChaCha20-Poly1305 在无 AES 引擎的平台上往往比 AES-CCM 更高效。若硬件加速可用，则应尽量让数据走 DMA 通道，减少 CPU 搬运，并在运算完成后立即关闭外设时钟。