2. 嵌入式密码需求分析

密码库裁剪不是“把用不到的文件删掉”这么简单。真正决定裁剪边界的，是需求分析。对嵌入式系统而言，需求分析要同时回答四个问题：目标平台还剩多少资源、系统需要达到什么安全等级、产品必须满足哪些合规条款、以及设备实际运行在什么场景中。这四个维度共同决定“保留什么算法、保留哪些实现、砍掉哪些功能、如何配置参数”。如果跳过需求分析直接裁剪，常见后果是：算法能跑但过不了认证，或者通过了认证但 Flash 超限，或者功能齐全却在中断上下文中因动态内存分配而崩溃。

一、资源约束：先量化，再裁剪

资源约束是裁剪最直接的驱动力，必须量化到具体数字，而不是“资源紧张”这类模糊描述。需要量化的对象包括：

• Flash/ROM：存放算法代码、常量表（如 AES S 盒、SM4 系统参数、大数运算预计算表）、证书与密钥材料。
• RAM：运行时上下文、栈、堆、临时缓冲区。对称算法上下文通常几十到几百字节，RSA/ECC 大数运算可达数 KB。
• 栈空间：嵌入式任务栈常只有 1～4 KB，而某些大数运算或 ASN.1 解析会深递归，必须实测最坏栈深。
• CPU 主频与算力：决定能否承受非对称运算的耗时，是否需要硬件加速。
• 功耗与能量：电池供电设备需关注单次加密的能耗与唤醒时间。
• 存储寿命：频繁写密钥或日志会加速 Flash 磨损。

举例说明量化方法：某 Cortex-M0+ 设备，Flash 256 KB、RAM 32 KB、主频 48 MHz、无硬件密码加速。若仅需 TLS 客户端与设备身份认证，可保留 AES-128-GCM（约 6～10 KB 代码）、SHA-256（约 4～6 KB）、ECDHE/ECDSA 使用 secp256r1（约 15～25 KB），并砍掉 RSA、DH、MD5、SHA-1、DES/3DES、X.509 完整解析（改用预置证书或精简解析）。这样密码库总占用可控制在 40～60 KB，为应用留出余量。若强行保留 RSA-2048，仅大数运算与密钥解析就可能超过 30 KB，且 48 MHz 下单次签名可能达到数百毫秒，影响实时性。

二、安全等级：从威胁模型推导强度

安全等级不是越高越好，而是“匹配威胁模型”。需要明确：攻击者能物理接触设备吗？能读取 Flash 吗？能侧信道观测功耗/电磁吗？能发起网络中间人攻击吗？据此确定：

• 算法强度：对称密钥至少 128 位；哈希至少 SHA-256；非对称至少 256 位椭圆曲线或 2048 位 RSA（新设计优先 ECC）。
• 密钥保护：密钥是否必须存放在安全存储、是否需要防回读、是否使用 TRNG 生成。
• 抗侧信道：是否需要常数时间实现、掩码、随机化。
• 安全启动与信任根：是否要求从 BootROM 开始逐级验签。

裁剪时，安全等级决定“不能砍什么”。例如要求抗侧信道，就不能为了省空间砍掉常数时间实现而换回查表实现；要求安全启动，就必须保留验签算法与哈希，不能只留对称加密。

三、合规要求：把条款翻译成技术约束

合规要求往往以标准或法规形式出现，需要翻译成可执行的技术约束。常见来源包括：

• 商用密码：若产品在国内销售且涉及密码功能，需使用 SM2/SM3/SM4 等算法，并满足相关检测要求。
• 等保/密评：对密钥管理、算法合规、随机数质量提出要求。
• 行业规范：如车载可能涉及功能安全与信息安全并行要求；工控可能涉及 IEC 62443。
• 出口/国际认证：如 FIPS 140-3、Common Criteria，对算法实现、自检、角色分离有明确条款。

合规条款会直接改变裁剪目标。例如 FIPS 模式要求算法必须通过已知答案测试（KAT），则裁剪时不能删除自检代码；要求角色分离，则不能把密钥读写接口随意暴露给应用层。若产品只需国内合规，则优先保留 SM 系列算法，RSA/ECC 可作为可选。

四、典型应用场景：IoT、车载、工控的裁剪目标差异

不同场景对资源、安全、合规的权重不同，裁剪目标也不同：

• IoT 终端：资源极紧、成本敏感、数量大。裁剪目标通常是“最小可用密码集”：AES-GCM + SHA-256 + ECDHE/ECDSA（或 SM4-GCM + SM3 + SM2），砍掉证书链完整解析、砍掉不用的曲线与哈希，优先使用硬件加速或轻量实现。
• 车载：ECU 资源中等，但要求高可靠、低延迟、长生命周期，且需支持 OTA 安全升级与车内通信认证。裁剪目标：保留安全启动验签、SecOC 所需对称算法、OTA 包验签；算法选择需兼顾车规认证与供应链合规；通常保留 AES、SHA-256、ECC，并可能要求 SM 算法以符合国内要求。
• 工控：设备生命周期长、协议多样、现场维护困难。裁剪目标：优先保证协议兼容与长期可维护，保留 TLS/DTLS 所需算法集，保留密钥更新与回滚保护；可能仍需支持较老的算法以兼容既有设备，但应通过配置隔离，避免默认启用弱算法。

五、裁剪目标定义：从需求到配置清单

把上述四维分析收敛成一份可执行的裁剪目标定义，至少包含：目标平台资源上限、必须保留的算法与模式、必须删除的算法与功能、安全等级对应的实现要求、合规条款对应的自检与接口约束、以及场景相关的性能与功耗指标。下面给出一个示例配置清单（示例参数，非实测）：

目标平台：Cortex-M4，Flash 512 KB，RAM 128 KB，主频 80 MHz，含 AES 硬件加速
场景：工业网关，需 TLS 1.3 客户端 + 设备证书认证
合规：国内商用密码 + 等保二级
裁剪目标：
  保留：SM4-GCM、SM3、SM2（签名/验签）、SHA-256、AES-128-GCM（兼容）
  删除：DES/3DES、RC4、MD5、SHA-1、RSA、DH、DSA、完整 X.509 解析
  安全等级：128 位对称强度，密钥存于安全区，TRNG 生成
  资源上限：密码库 Flash ≤ 80 KB，RAM ≤ 16 KB，栈深 ≤ 2 KB
  性能：SM2 签名 ≤ 20 ms，SM4-GCM 吞吐 ≥ 5 Mbps
  自检：上电执行 SM3/SM4/SM2 KAT

这份清单就是裁剪的“验收标准”。后续选择密码库、配置编译选项、替换实现、做资源测量时，都以它为准。若测量结果超出上限，应回到需求分析调整优先级，而不是先删自检或降强度。