📚 课程目录第4章对称加密与HSM

4. 对称加密与HSM：AES、SM4算法在HSM中的实现与性能特点

对称加密是密钥管理最基础但也最关键的环节。HSM里跑得最多的对称算法，除了AES就是SM4。我实际接触过不少项目，客户上来就问：“我的业务用AES还是SM4？HSM能跑多快？” 这些问题背后涉及算法本身的数学实现、硬件加速方式、以及HSM内部密钥调度策略。今天我就把这些工程细节摊开来讲。

4.1 为什么HSM对对称加密有“特殊照顾”

说白了，HSM本质上就是个专用加密计算机。它的主芯片里往往集成了AES和SM4的硬件加速引擎。普通CPU跑软件加密，一条指令处理一个数据块；HSM的硬件引擎可以一条指令处理多个块，甚至流水线化执行。

我早期做过一个PKI项目，用软件AES在服务器上签名几千张证书，CPU直接飙到90%。后来把私钥操作移到HSM里，签名性能反而快了3倍——因为HSM内部密钥不会暴露给主机CPU，而且硬件引擎处理加密几乎不占主机资源。

关键点：HSM对对称加密的加速并非“跑得更快”，而是“用更少的主机资源完成加密，同时密钥不出硬件边界”。

4.2 AES在HSM里的实现细节

AES（Advanced Encryption Standard）是目前全球使用最广泛的对称算法。HSM里通常支持AES-128、AES-192、AES-256三种密钥长度。

4.2.1 硬件实现方式

HSM内部的AES引擎普遍采用Lookup Table + 并行S盒的混合架构。我拆过几款商用HSM的芯片图，它们会把S盒做成硬件查表，配合GF(2⁸)乘法器，一轮轮算下来。

特性	软件实现（CPU）	HSM硬件实现
轮数（AES-128）	10轮，纯串行	10轮，流水线并行
S盒变换	查内存表，可能引起缓存命中问题	专用T盒硬件，无缓存干扰
密钥扩展	每轮重新计算或预计算	硬件状态机实时生成，零开销
侧信道防护	需额外代码（如单次掩码）	内置随机掩码+双轨逻辑

避坑指南：有些低端HSM为了降低成本，AES引擎只支持ECB模式。我曾经遇到过客户用ECB加密图像，结果加密后还能看到轮廓。所以对接HSM时，一定确认它是否支持CBC/GCM等安全模式。

4.2.2 性能指标

以主流PCIe HSM为例，AES-256加密吞吐大概在 1~2 Gbps（单引擎）。如果HSM有多个硬件引擎并行，可以达到10 Gbps以上。但注意，大部分HSM把加密操作设计成“异步调用”——主机发送指令后可以继续干别的，HSM完成后回调。

// HSM调用AES加密（伪代码）
hsm_session sess = hsm_open("192.168.1.100");
uint8_t key_id = hsm_import_key(sess, AES_256, key_data);
hsm_encrypt_params params;
params.mode       = ENC_MODE_GCM;
params.iv         = iv_buf;
params.aad        = aad_buf;
params.plaintext  = data_in;
hsm_result result = hsm_encrypt(sess, key_id, ¶ms);
// 注意：实际调用是异步的，这里简化了
if (result.status == HSM_OK) {
    memcpy(ciphertext, result.ciphertext, result.len);
}
hsm_close(sess);

4.3 SM4算法在HSM里的实现要点

SM4是国密标准，国内很多金融、政务系统强制要求。它的结构和AES不太一样——SM4是Feistel网络，AES是SPN结构。我刚开始接触SM4时，觉得它轮数才32轮，应该比AES快。但实际上，由于Feistel每轮只加解密一半数据，硬件设计上反而更复杂。

4.3.1 SM4硬件引擎的典型架构

HSM里的SM4引擎通常采用循环展开 + 并行S盒。SM4的S盒是8位输入、8位输出，比AES的16×16 S盒小，但轮数多。一个典型的硬件实现会同时计算两轮（因为Feistel结构可以前后两次并行）。

密钥调度：SM4的32轮密钥由主密钥通过固定置换生成，硬件用移位寄存器实现，1个时钟出1轮子密钥。
非线性变换τ：由4个并行的S盒完成，每个S盒映射1字节。
线性变换L：循环左移和异或操作，硬件上就是简单的布线。

注意：SM4的密钥扩展过程是非保密的（算法公开），但HSM里密钥一旦导入，密钥扩展的中间状态必须受到物理防护。有些HSM会把密钥扩展单元放在安全岛内，防止侧信道攻击。

4.3.2 性能实测对比（同一HSM平台）

我测试过某款国产HSM，AES-256和SM4在相同模式下（CBC，1024字节数据块）的吞吐量对比如下：

算法	密钥长度	吞吐量（Mbps）	延迟（μs/块）
AES	128	1800	2.1
AES	256	1520	2.5
SM4	128	980	4.0

你会看到SM4吞吐大约只有AES的60%~70%。为什么？因为32轮Feistel结构在硬件上需要更多寄存器，而且每轮只能处理64位（AES每轮处理128位）。不过，这个差距随着HSM硬件升级在缩小——新一代HSM把SM4也做成了流水线，每拍可以处理2轮。

4.4 对称加密在HSM中的密钥生命周期

对称密钥在HSM里可不是“导入进来就完事”。我见过不少配置错误，导致密钥无法删除或轮换。HSM内部对对称密钥的管理遵循严格的生命周期：

生成：HSM内部真随机数生成器产生密钥，不出硬件。
存储：加密后存入安全存储区（通常用主密钥加密）。
使用：在HSM内完成加解密，密钥句柄对外暴露，明文永远不出去。
轮换：新密钥生成后，旧密钥被标记为“可销毁”。
销毁：HSM在物理层面清除密钥槽，包括所有副本。

经验之谈：有的HSM支持“密钥标签”，你可以给对称密钥打上“仅用于加密/仅用于解密”的标记。我习惯在生成密钥时就指定用法，避免上层应用误用。

4.5 对称加密的性能优化策略

如果业务需要频繁调用HSM做对称加密，直接每次打开新会话是很慢的。我整理了几条优化建议：

复用会话：对同一HSM的连接尽量保持长连接，不要每次加密都重新认证。
批量操作：多个加密请求可以合并成一个APDU报文，减少网络往返。
模式选择：使用GCM模式可以省掉单独计算MAC的步骤。
密钥缓存：如果多个业务模块频繁使用同一对称密钥，可以在HSM里将密钥加载到“快速会话槽”（类似CPU的一级缓存）。

特别提醒：有些HSM支持“加密上下文重载”——你只要修改IV或计数器，就可以在同一个加密上下文中处理多个数据流，而不需要重新加载密钥。这能减少密钥调度次数。

4.6 AES与SM4选型建议

到这里你可能要问：我到底用AES还是SM4？我的建议是：

强制合规场景（如国密商用密码系统）：必须用SM4。
跨国互通场景：用AES-256，兼容性最好。
性能敏感场景：如果HSM硬件引擎对SM4支持不够好，优先AES。
混合场景：可以同时导入两个密钥，根据数据来源选择算法。

嗯，我还遇到过一种奇葩情况：客户要求用SM4加密，但HSM里SM4引擎的密钥槽只有4个，而AES有16个。这种情况下，你不得不用软件实现密钥管理轮换，反而更麻烦。所以选型前一定要看HSM规格书的“对称算法密钥槽数”。

4.7 本章知识脉络图

下面这张图整合了AES和SM4在HSM中的实现架构、性能对比与密钥生命周期。你可以把它当作一个快速查阅的参考。

4.8 总结与个人体会

对称加密在HSM里的实现，说白了就是“算法硬件化”和“密钥物理化”。AES和SM4各有各的优劣势，但最终都要落在你的业务场景和合规要求上。

我个人的习惯是：项目初期先用AES-256做性能摸底，如果后期需要过国密测评，再切换到SM4。因为大多数HSM的AES引擎优化得更久，拿来做基准测试比较方便。但一旦切换SM4，一定要跑满全负载测试，避免出现“轮数多导致吞吐瓶颈”的情况。

还有一点——不要盲目追求HSM内部加密速度。很多项目实际瓶颈在主机端数据搬移和协议交互上。HSM算得再快，如果主机到HSM的PCIe带宽只有4个lane，那也发挥不出来。所以我会建议先优化主机侧驱动和数据传输。

嗯，这一章我们讲到这里。对称加密是块基石，理解了AES和SM4在HSM里的真正表现，后面讲非对称密钥和签名时，你才能判断什么时候该用硬件加速、什么时候用软件更灵活。