1. 密码算法移植概述
各位同学好，我是老周。做嵌入式安全这行十几年了，今天咱们聊聊密码算法移植。
很多人一听到「移植」两个字，就觉得是简单的复制粘贴。把桌面端的 AES 代码拷过来，改改编译选项，不就完事了？
嗯，我以前也这么想过。直到有一次，一个看似跑通的 SM4 算法，在 ARM Cortex-M3 上加密出来的结果跟预期完全不一样。查了三天，最后发现是字节序对齐的问题。从那以后，我再也不敢小看移植这件事了。
1.1 什么是密码算法移植
说白了，密码算法移植就是把一个平台上能跑的密码算法，搬到另一个平台上，还能正确、高效地跑起来。
举个例子：你在 PC 上用 OpenSSL 写了个 AES-256 加密程序，现在要把它放到一个只有 64KB Flash、8KB RAM 的物联网芯片上。这不只是改个编译器的事。
移植涉及几个层面：
- 接口层：API 调用方式、参数传递规则
- 计算层：大数运算、查表操作、位运算的实现
- 存储层：密钥存储、中间变量、栈空间的分配
- 安全层：侧信道防护、故障注入防护
核心观点：移植不是搬运，是适配。每个目标平台都有自己的脾气，你得顺着它来。
1.2 为什么需要移植
你可能会问：直接用现成的密码库不行吗？
行，但很多时候不行。我遇到过几种典型场景：
- 硬件受限：MCU 只有几十 KB 内存，标准库根本塞不进去
- 性能要求：某些场景需要实时加解密，通用库太慢
- 合规需求：国密算法（SM2/SM3/SM4）在通用库中支持不完善
- 安全增强：标准实现没有抗侧信道攻击的能力
- 成本控制：去掉不需要的算法，只保留必要的，节省 Flash 空间
| 场景 | 典型平台 | 移植难点 |
|---|---|---|
| 物联网终端 | Cortex-M0/M4 | RAM 极小，无操作系统 |
| 智能卡 | Java Card / Native | 指令集特殊，资源极度受限 |
| FPGA 软核 | MicroBlaze / Nios II | 无硬件乘法器，需软件模拟 |
| 安全芯片 | SE 专用内核 | 需硬件加速器协同 |
我的经验：做移植前，先搞清楚目标平台的「三围」——Flash 大小、RAM 大小、主频。这三个数字决定了你能用什么算法、怎么优化。
1.3 移植的挑战
移植这件事，看着简单，坑不少。我踩过的坑，列几个典型的：
- 字节序问题：大端小端搞反，加密结果全错。我曾经在调试一个 RSA 签名时，发现签名验不过，最后发现是字节序没转换。
- 对齐访问：有些 ARM 内核不支持非对齐访问，一读就 HardFault。你想想看，一个 memcpy 就能解决的问题，查了整整一天。
- 栈空间不足：标准库的 RSA 签名需要几 KB 的栈，你的 MCU 总共才 8KB RAM，一调用就栈溢出。
- 性能瓶颈：软件实现的椭圆曲线点乘，在 72MHz 的 MCU 上可能要跑几百毫秒，业务层根本等不了。
- 安全漏洞：移植过程中不小心引入了时序侧信道，密钥可能被远程破解。
避坑指南：我曾经把一个开源的 AES 实现移植到某款国产 MCU 上，测试时一切正常。量产一万台后，发现部分设备解密失败。查到最后，是编译器优化等级不同导致查表数据被放到了错误的内存区域。所以，移植后的测试一定要覆盖不同优化等级。
1.4 移植的机遇
挑战多，机会也多。做好移植，你能获得：
- 性能提升：针对特定平台优化后，速度可能比通用库快 5-10 倍
- 代码精简：只保留需要的算法，Flash 占用减少 60% 以上
- 安全可控：可以加入定制的防护措施，比如随机延时、掩码技术
- 成本优势：用低端芯片完成高端芯片才能跑的任务
说白了，移植能力是嵌入式安全工程师的核心竞争力之一。你想想看，能在一个 32MHz、16KB RAM 的芯片上跑通 ECC 签名，这本身就是一种技术壁垒。
1.5 知识体系总览
这一章的内容比较多，我画了张图，帮你理清思路：
1.6 本章小结
密码算法移植，说白了就是让算法在目标平台上「活」起来。它不只是技术活，更是个细致活。
我个人习惯把移植分为四个阶段：分析、实现、测试、优化。每个阶段都有各自的坑，后面几章我会一个一个拆开来讲。
记住一句话：移植前多花一小时分析平台特性，移植后能省十小时调试时间。这是我在无数次踩坑后总结出来的教训。
给新手的建议：第一次做移植，选一个简单的对称算法（比如 AES-128）练手。先跑通，再优化。别一上来就搞 ECC 或 RSA，容易劝退。