4、密码学基础：对称加密（AES）、非对称加密（RSA/ECC）、哈希函数（SHA-256）及在嵌入式中的资源约束
嵌入式安全通信协议的设计，其安全根基完全建立在密码学原语之上。在MCU、SoC等资源受限环境中，工程师不仅要理解算法原理，更需在安全强度、计算开销、功耗与代码/内存占用之间做出精准权衡。本章将聚焦三类核心密码学工具——AES对称加密、RSA/ECC非对称加密、SHA-256哈希函数，深入剖析其数学原理、工程实现要点及在嵌入式环境中的资源约束，帮助读者建立从算法选型到落地优化的完整认知框架。
4.1 对称加密AES：嵌入式数据加密的基石
核心原理
AES（Advanced Encryption Standard）是当前嵌入式领域应用最广泛的对称分组密码算法，其分组长度固定为128位，支持128/192/256位三种密钥长度。算法基于SPN（Substitution-Permutation Network）结构，通过10/12/14轮迭代的字节代换（SubBytes）、行移位（ShiftRows）、列混合（MixColumns）和轮密钥加（AddRoundKey）操作实现混淆与扩散。在嵌入式环境中，AES的硬件加速器（如STM32的CRYP外设、NXP的LTC模块）可显著降低CPU负载，软件实现则需关注查表法（T-table）与位切片（Bit-slicing）两种优化路径。
| 密钥长度 | 轮数 | 安全性等级 | 典型应用场景 |
|---|---|---|---|
| AES-128 | 10 | 足够（量子计算威胁下需关注） | IoT传感器数据加密、固件镜像加密 |
| AES-192 | 12 | 较高 | 工业控制、智能电网终端 |
| AES-256 | 14 | 最高 | 金融支付终端、医疗设备 |
判断方法与操作流程
在嵌入式项目中，选择AES实现方式需遵循以下决策流程：首先评估MCU是否集成硬件加密引擎，若有则优先使用硬件加速（如STM32L4系列通过CRYP外设实现AES-128/256，吞吐量可达MB/s级）；若无硬件加速，则需根据CPU主频和实时性要求选择查表法（适合Cortex-M4以上，每字节约20-50周期）或位切片法（适合Cortex-M0等低端内核，但代码量增加约30%）。操作流程上，需注意密钥存储安全——建议将密钥烧录于OTP区域或使用安全元件（SE）保护，避免明文密钥暴露在Flash中。
案例拆解：智能门锁通信加密
某智能门锁项目采用ESP32-C3（RISC-V内核，160MHz）作为主控，需与手机APP通过BLE通信。初始方案使用纯软件AES-128-CBC，实测加密1KB数据耗时2.3ms，导致BLE连接事件超时。分析发现，ESP32-C3内置AES硬件加速器但未启用。优化措施：①启用硬件AES引擎，配置为GCM模式；②将密钥存储于eFuse区域；③使用ESP-DSP库优化数据搬运。优化后加密耗时降至0.4ms，功耗降低55%，且增加了完整性校验能力。此案例表明，充分利用硬件加速器是嵌入式AES落地的关键。
4.2 非对称加密RSA与ECC：密钥交换与身份认证
核心原理
非对称加密使用公钥/私钥对，公钥用于加密或验签，私钥用于解密或签名。RSA基于大整数分解难题，密钥长度通常为2048/3072位，计算开销大；ECC基于椭圆曲线离散对数难题，在相同安全强度下密钥长度更短（256位ECC等效于3072位RSA），计算效率更高。在嵌入式环境中，ECC（尤其是Curve25519、secp256r1）已成为主流选择，广泛应用于TLS握手、固件签名验证和Secure Boot。
| 算法 | 密钥长度 | 等效安全强度 | 签名速度（Cortex-M4 @100MHz） | 验签速度 |
|---|---|---|---|---|
| RSA-2048 | 2048 bit | 112 bit | ~800ms | ~15ms |
| RSA-3072 | 3072 bit | 128 bit | ~3s | ~40ms |
| ECC-256 (secp256r1) | 256 bit | 128 bit | ~80ms | ~120ms |
| ECC-25519 (Curve25519) | 255 bit | 128 bit | ~50ms | ~90ms |
判断方法与操作流程
选型判断依据：若设备需与现有PKI体系兼容（如X.509证书链），则RSA仍是必要选项；若为新建系统且追求性能与功耗平衡，ECC是更优选择。操作流程上，ECC密钥生成需使用真随机数发生器（TRNG）确保私钥不可预测；签名操作需注意随机数k的唯一性，若k值重复将导致私钥泄露（如索尼PS3签名漏洞）。在嵌入式实现中，推荐使用mbedTLS或WolfSSL库，并启用硬件加速（如STM32的HASH外设配合ECC加速）。
案例拆解：车载ECU固件安全升级
某Tier1供应商为车规级ECU设计固件升级方案，要求验签时间小于100ms且支持OTA。初始方案采用RSA-2048验签，实测耗时180ms，超出要求。分析瓶颈：RSA模幂运算在TC277（TriCore 200MHz）上计算密集。优化方案：①改用ECC-256（secp256r1）签名，验签时间降至45ms；②将公钥存储于HSM（硬件安全模块）中，防止篡改；③采用双缓冲区设计，验签与Flash写入并行执行。最终方案满足要求，且Flash占用减少12KB。此案例说明，ECC在车规级场景中具有显著性能优势。
4.3 哈希函数SHA-256：数据完整性与消息认证
核心原理
SHA-256是SHA-2家族成员，输出256位摘要，具有单向性、抗碰撞性和雪崩效应。在嵌入式场景中，SHA-256主要用于：①固件完整性校验（Secure Boot）；②HMAC消息认证码（与密钥结合）；③数字签名中的哈希预处理。其实现基于Merkle-Damgård结构，将输入消息分块（512位）迭代压缩，每轮包含64次循环的位运算、模加和逻辑函数。
| 应用场景 | 输入数据 | 输出 | 典型性能（Cortex-M4 @100MHz） |
|---|---|---|---|
| 固件哈希校验 | 固件镜像（1MB） | 256位摘要 | ~25ms |
| HMAC-SHA256 | 通信报文（256B） | 256位MAC | ~0.1ms |
| 密钥派生（PBKDF2） | 密码+盐 | 派生密钥 | ~5ms/迭代 |
判断方法与操作流程
选择哈希函数时需考虑：①安全性需求——SHA-1已不推荐，SHA-256为最低安全基线；②硬件支持——多数MCU集成SHA-256硬件加速器（如STM32的HASH外设）；③内存占用——软件实现约2-4KB Flash，硬件加速则需额外驱动代码。操作流程上，Secure Boot的典型流程为：BootROM读取固件头部哈希值→计算整个固件的SHA-256摘要→与存储的参考值比对→若匹配则跳转执行。此过程需注意防回滚机制，防止攻击者降级固件版本。
案例拆解：LoRaWAN节点消息完整性保护
某LoRaWAN传感器节点使用STM32L0（Cortex-M0+，32MHz）上报环境数据，需对每个上行报文计算HMAC-SHA256。初始软件实现耗时8ms，导致发送周期从10s延长至12s。分析发现，Cortex-M0+无硬件哈希加速，且代码未优化。优化措施：①使用汇编级优化，将关键循环体改写为Thumb-2指令；②将消息填充与哈希计算流水化；③采用预计算密钥块（ipad/opad）减少重复计算。优化后HMAC计算耗时降至3.2ms，发送周期恢复至10s，电池寿命延长约15%。此案例展示了在低端MCU上通过代码优化实现高效哈希计算的可能性。
4.4 嵌入式资源约束下的算法选型与综合优化
核心原理
嵌入式密码学设计的核心矛盾是安全强度与资源消耗的平衡。资源约束包括：CPU算力（主频、MIPS）、内存（Flash/RAM）、功耗（mA级）、实时性（ms级响应）。选型原则：①批量数据加密优先选择AES-GCM（认证加密一体化）；②密钥交换与身份认证优先选择ECC（如ECDHE、ECDSA）；③完整性校验使用SHA-256或HMAC-SHA256；④密钥管理需结合硬件安全模块（HSM/SE）。
| 资源维度 | AES-128-GCM | ECC-256 | RSA-2048 | SHA-256 |
|---|---|---|---|---|
| Flash占用（软件实现） | 4-8 KB | 8-15 KB | 10-20 KB | 2-4 KB |
| RAM占用（运行态） | 0.5-1 KB | 1-2 KB | 2-4 KB | 0.3-0.5 KB |
| 典型功耗（@100MHz） | 5-10 mA | 15-25 mA | 30-50 mA | 3-8 mA |
| 实时性（处理1KB数据） | <1ms | N/A（用于握手） | N/A（用于握手） | <0.5ms |
判断方法与操作流程
综合选型流程：①明确安全需求等级（消费级/工业级/车规级/金融级）；②评估MCU算力与硬件加速能力；③计算各算法的资源占用与功耗预算；④进行安全风险评估（如侧信道攻击、故障注入）；⑤选择密码库（mbedTLS、WolfSSL、BearSSL）并配置裁剪。操作流程上，建议采用"混合密码系统"：使用ECC进行密钥协商，生成会话密钥后使用AES-GCM加密业务数据，同时使用HMAC-SHA256保证消息完整性。
案例拆解：智能电表安全通信模块设计
某智能电表项目采用NXP LPC55S69（双核Cortex-M33，150MHz），需实现DLMS/COSEM协议安全层。初始方案使用mbedTLS默认配置，Flash占用达120KB，超出可用空间。分析各算法占用：RSA-2048占45KB，AES占12KB，SHA-256占8KB。优化措施：①将RSA替换为ECC-256，Flash减少30KB；②启用mbedTLS的配置裁剪（MBEDTLS_ECP_DP_SECP256R1_ENABLED等宏），去除未使用的曲线；③使用硬件加速器（LPC55S69内置AES-256和SHA-2引擎），减少软件代码；④将密钥存储于TrustZone安全区。最终Flash占用降至68KB，握手时间从1.2s降至350ms，满足DLMS规范要求。此案例展示了系统级资源优化的完整路径。