硬件限制分析：MCU的Flash与RAM限制、EEPROM的擦写寿命、低功耗对密码算法的影响
做嵌入式密码实现，第一关不是算法本身，而是你手里的芯片到底有多「穷」。我早年接过一个项目，客户要求用一颗8毛钱的Cortex-M0做TLS握手，结果光证书解析就把RAM撑爆了。从那以后，我养成了一个习惯：动手写密码代码之前，先把芯片手册的Memory Map和电气特性表打印出来贴在桌上。
这一节我们就来聊聊，Flash、RAM、EEPROM和功耗这四个硬约束，到底怎么卡你的密码实现。
Flash与RAM：密码代码的「住房面积」
MCU的Flash和RAM通常以KB计，而不是MB。你想想看，一个AES-256的查表实现，光是S盒和逆S盒就要占掉512字节，再加上轮密钥扩展、状态矩阵、工作缓冲区……一个中等规模的密码库，Flash占用轻松超过20KB，RAM占用也要2-3KB。
我见过有人把OpenSSL的ARM版直接往STM32F103上搬，编译出来200多KB，连下载都报错。这不是写代码，这是自找麻烦。
核心矛盾：密码算法通常需要大查找表（如AES的T表）或大缓冲区（如RSA的大数运算），而MCU的Flash和RAM极其有限。你必须用「空间换时间」还是「时间换空间」做取舍。
具体来说，Flash限制影响的是：
- 代码体积——算法实现本身、密钥派生函数、随机数生成器、协议封装，每一行都占空间
- 常量表——S盒、逆S盒、轮常数、预计算素数、椭圆曲线参数
- 固件升级空间——OTA分区要预留，密码库不能把Flash吃光
RAM限制影响的是：
- 工作缓冲区——AES的128位状态、SHA-256的64字节块、RSA的大数数组
- 堆栈深度——密码函数调用链长，嵌套深，栈溢出是常见bug
- 临时密钥存储——密钥不能长期留在RAM里，但计算时必须有地方放
我个人的经验是：先算账，再动手。拿到芯片型号后，先列一张表：
| 资源项 | 典型值（以STM32F103C8为例） | 密码实现可用量 |
|---|---|---|
| Flash总量 | 64 KB | 约50 KB（留出Bootloader和协议栈） |
| RAM总量 | 20 KB | 约12 KB（留出OS和业务逻辑） |
| 密码库预估占用 | — | Flash 15-25 KB / RAM 2-4 KB |
如果算下来Flash只剩8KB，就别想着用mbedTLS全功能版了。老老实实手写AES-128 ECB，或者用硬件加密引擎。
我的一个小技巧：在编译时加 -Os 优化尺寸，然后用 size 命令看每个目标文件的.text/.data/.bss占用。哪个模块超标，就针对性替换成轻量实现。
EEPROM的擦写寿命：密钥存储的「隐形杀手」
EEPROM这东西，看起来很美——掉电不丢数据，按字节读写，方便存密钥。但它的擦写寿命通常只有10万次到100万次。你可能会说：「10万次够多了吧？」
嗯，我一开始也这么想。直到我遇到一个门禁项目，设备每刷一次卡就要更新一次密钥计数器，每天刷几百次。三个月后，EEPROM那个扇区就挂了。设备还能跑，但密钥校验永远失败——因为存储密钥的那几个字节已经无法正确写入。
这就是EEPROM擦写寿命带来的典型问题：
- 密钥更新频繁——每次更换密钥都要擦写EEPROM，寿命快速消耗
- 计数器/序列号——很多密码协议需要单调递增的计数器，每次操作都写一次
- 磨损不均衡——总是写同一个地址，其他地址还是新的，但那个地址已经报废
我曾经踩过的坑：把AES密钥直接存在EEPROM的固定地址，每次设备启动读一次。看起来没问题对吧？但设备做固件升级时，Bootloader会擦写那个扇区做参数存储。升级三次后，密钥字节就坏了。后来我改成：密钥写在EEPROM末尾，加上CRC校验，启动时校验失败就用默认密钥回退。
解决方案其实不复杂：
- 磨损均衡——把密钥分散写在多个扇区，轮流使用，而不是死磕一个地址
- 减少写次数——密钥不频繁更新的话，一次写入用十年
- 使用FRAM替代——如果成本允许，FRAM的擦写寿命是10^12次，基本不用考虑磨损
- 加校验——每次读EEPROM都做CRC或奇偶校验，发现损坏就触发密钥恢复流程
我个人习惯是：把密钥和配置参数分开存。密钥放在EEPROM的专用区域，只写一次（除非用户主动更换），配置参数放在另一个区域，允许频繁擦写。这样密钥区域的寿命几乎等于设备寿命。
低功耗对密码算法的影响：每一毫安都要算清楚
低功耗设备做密码运算，最头疼的不是算得慢，而是电流峰值。你想想看，一个AES-256加密，CPU全速跑几十微秒，电流从10μA瞬间跳到10mA。如果电池供电，这个电流尖峰可能导致电压跌落，系统复位。
我做过一个BLE门锁项目，用的是CR2032纽扣电池。AES加密时电流峰值达到15mA，电池内阻大，电压直接掉到2.0V以下，MCU掉电重启。后来加了100μF电容才稳住。
低功耗对密码算法的影响主要体现在三个方面：
| 影响因素 | 具体表现 | 应对策略 |
|---|---|---|
| 计算功耗 | 密码运算时CPU全速运行，电流峰值高 | 分时运算、降低主频、使用硬件加速器 |
| 待机功耗 | 密钥留在RAM中需要保持供电 | 密钥用完后立即擦除、使用备份寄存器 |
| 通信功耗 | 密码握手需要多次收发数据 | 减少握手次数、使用预共享密钥 |
说白了，低功耗场景下，你不能把密码算法当成「免费」的。每一次加密、每一次签名，都在消耗宝贵的电池容量。
我的实测数据：在nRF52832上，用软件实现AES-128加密一个16字节块，@64MHz，耗时约2μs，消耗约8μJ。如果设备每天加密100次，一年下来也就0.3mAh——几乎可以忽略。但如果是RSA-2048签名，一次就要消耗约50mJ，相当于AES加密的6000倍。所以低功耗设备尽量别用非对称密码，或者只在必要时用。
一张图看懂硬件限制与密码实现的博弈
下面这张图总结了Flash、RAM、EEPROM和低功耗四个维度对密码实现的影响，以及常见的权衡策略：
实战建议：如何快速评估硬件限制
拿到一个新项目，我一般按这个顺序做硬件限制评估：
- 查手册——确认Flash、RAM、EEPROM大小，以及EEPROM的擦写寿命（通常写在电气特性章节）
- 算余量——减去Bootloader、RTOS、协议栈、业务逻辑后，还剩多少给密码库
- 选算法——如果Flash余量 < 10KB，放弃mbedTLS，用手写AES或硬件引擎；如果RAM余量 < 2KB，避免RSA和ECDH
- 测功耗——用示波器抓密码运算时的电流波形，看峰值和持续时间，算平均功耗
- 定策略——根据结果决定：用软件还是硬件加速？密钥存EEPROM还是Flash模拟？要不要加磨损均衡？
特别提醒：不要相信芯片手册上的「典型值」。Flash和RAM的实际可用量往往比标称值少10%-20%，因为Bootloader、中断向量表、堆栈预留都会吃掉一部分。我习惯按标称值的70%做预算，留出安全余量。
嗯，硬件限制分析就聊到这里。记住一句话：密码实现不是算法竞赛，而是资源管理。把Flash、RAM、EEPROM和功耗这四个维度摸清楚，你的密码代码才能稳稳地跑在受限设备上，而不是三天两头出问题。