📚 课程目录第2章密码学基础回顾

密码学基础回顾

说实话，做HSM和KMS集成这件事，最绕不开的就是密码学基础。很多人一听到“密码学”三个字就觉得头大，觉得那是数学家干的事。但我做了这么多年安全集成，我的体会是：你不需要成为密码学家，但必须搞明白那些基础概念是怎么串起来的。

为什么？因为HSM和KMS本质上就是帮你管好这些密钥和算法的工具箱。你要是连用的工具都不了解，那出了问题根本无从下手。我在项目里见过不少团队，配置了半天突然发现加密性能上不去，最后排查下来，是算法选错了。

好，咱们把这部分基础过一遍。

对称加密 vs 非对称加密

这两个概念就像钥匙和锁的关系。理解它们，是理解整个密钥体系的第一步。

对称加密，说白了就是一把钥匙同时管开锁和关锁。加解密用的是同一个密钥。优点是快，特别快。AES-256在硬件加速下，每秒能处理几十GB的数据。

  典型算法：
  AES（高级加密标准）—— 现在最主流，密钥长度128/192/256位
SM4（国密）—— 国内商用密码标准，128位密钥
3DES —— 老古董了，我建议新项目别碰

非对称加密，则是公钥加密、私钥解密。或者反过来，私钥签名、公钥验签。私钥自己留着，公钥发出去。这样就不用在网络上传输私钥，解决了密钥分发的问题。

但代价呢？慢。比对称加密慢几百到几千倍。RSA-2048签名每秒大概就几千次，而AES加密每秒能跑几百万次。所以实际系统里，几乎没有人直接用非对称加密去加密大量数据。

我之前有个项目，客户想把所有数据库字段都用RSA加密。我一看方案就摇头——这性能死定了。最后改成用RSA加密AES密钥，再用AES去加密数据，问题就解决了。

注意：非对称加密的密钥长度远比对称加密长。RSA至少2048位，ECC推荐256位（安全等级约等于AES-128）。不要为了省存储空间用短密钥，那是给攻击者留后门。

对称加密 vs 非对称加密对比
特性	对称加密	非对称加密
密钥数量	加解密共用1个密钥	公钥+私钥，2个
性能	极快，适合大量数据	慢，仅适合小数据或密钥交换
密钥分发	困难，需要安全通道	公钥可公开，私钥自留
典型长度	128-256位	2048位(RSA) / 256位(ECC)
主要用途	数据加密、批量加密	密钥交换、数字签名、证书

你想想看，如果两个系统之间要加密通信，最简单的方式就是用对称加密。但问题来了——双方怎么拿到同一个密钥呢？这就需要非对称加密来帮忙。实际场景里，我们通常用非对称加密来传递对称密钥，这就是混合加密。HTTPS就是这么干的。

哈希函数与数字签名

哈希函数不负责加密数据，它负责给数据做个“指纹”。无论你的数据是1KB还是1TB，哈希函数都会给你一个固定长度的输出。而且只要数据改了一个比特，哈希值就会完全不一样。

我在整合HSM时，经常用哈希函数来做完整性校验。比如，我们要确认一个固件有没有被篡改，就计算它的SHA-256哈希值，和官方公布的对比一下。这是一个很有效的验证手段。

常用哈希算法：

SHA-2族（SHA-256 / SHA-384 / SHA-512）—— 目前工业标准
SM3（国密）—— 输出256位，国内合规场景必选
SHA-1 —— 已不推荐，有碰撞攻击风险

数字签名，则是哈希函数的应用之一。过程是这样的：用私钥给数据的哈希值做签名，别人用公钥验签。这样就能保证——数据确实是私钥持有者签发的，而且签名后没被人动过。

我之前遇到过一个坑：有同事在签名时直接签了整个文件（几百MB），结果性能惨不忍睹。我跟他讲，你先算哈希，再给那32字节的哈希值签名，效果完全一样，速度快了几百倍。这就是典型的“不懂原理吃大亏”。

密钥分层模型

好，这部分是我认为在整个HSM和KMS集成里最重要的一节。很多人把密钥管理搞复杂了，其实就是没理解分层模型。

密钥分层模型，说白了就是一个“用高级密钥保护低级密钥”的树形结构。最顶层的密钥由硬件（HSM）保护，永远不会以明文形式离开安全边界。下面的密钥由上层密钥加密存储，需要时解密使用。

最常见的三层模型是这样的：

根密钥（Root Key / Master Key） —— 存在HSM或安全硬件里，永不离开。用于加密下一层的主密钥。
主密钥（Key Encryption Key, KEK） —— 由根密钥加密存储。用于加密数据密钥。
数据密钥（Data Encryption Key, DEK） —— 由主密钥加密存储。真正用来加密业务数据的密钥。

重要原则：任何时候，HSM外都不允许出现根密钥的明文。如果根密钥泄露，整棵密钥树都得重建。我之前在项目里见过有人把根密钥备份到磁盘上——这是在给自己挖坑。

为什么用分层模型？我总结几个核心原因：

减少HSM交互次数 —— 根密钥在HSM内，加解密KEK需要过一次HSM。但DEK只需要KEK保护，KEK可以在应用内存中缓存（经加密形式），减少吞吐瓶颈。我之前测过一个场景，不用分层模型的时候，HSM每秒只能处理几百次加密；用了分层模型之后，DEK可以本地缓存复用，吞吐量直接上万。
密钥轮换灵活 —— 只需要重新加密KEK或DEK，不需要动根密钥。根密钥可以用好几年，但DEK可以根据安全策略每天轮换一次。
权限分离 —— 根密钥管理员和业务密钥管理员可以是不同的人。HSM里可以设多角色，谁管根密钥，谁管KEK，谁只能使用DEK，都能精细控制。

我在实际部署里，一般会建议客户把根密钥放在HSM的安全域里，再配一份紧急备份到另外一台HSM。主密钥可以存到数据库，但必须是被根密钥加密过的密文。数据密钥则直接存在业务服务器本地，甚至可以在内存里缓存起来。

这样做的好处很明显：即使数据密钥被窃取，攻击者拿到的只是一堆密文。没有HSM里的根密钥，他根本解不开。我之前在金融行业项目里落地这套方案，合规审查一次通过。

实战中的选择

讲完这些，我觉得有必要给一张实用的对照表。很多团队在选算法的时候会犹豫，到底用RSA还是ECC？对称密钥用128还是256？这里我根据自己的经验给个建议：

密钥选型建议
场景	推荐算法	密钥长度	原因
数据传输加密	AES-GCM	256位	带认证加密，防篡改
密钥交换/传递	ECDH / RSA-OAEP	256位(ECC) / 2048位(RSA)	性能+安全综合最优
数字签名	ECDSA / SM2	256位	签名短，性能好
完整性校验	SHA-256 / SM3	256位输出	安全余量充足
存储加密	AES-XTS	256位	磁盘加密专用模式

避坑提示：我曾经在项目里犯过一个低级错误——用AES-ECB模式加密多块数据。结果相同的明文块产生了相同密文，被安全审计直接点了名。记住：ECB模式不安全，CBC或GCM才是正确选择。

嗯，这里要特别注意一点：密码学算法本身只是个工具。真正决定系统安全性的，是你怎么管好这些密钥。这也是为什么HSM和KMS这么重要——它们帮你把“怎么管”这件事自动化、标准化了。

你在实际设计时，脑子里始终要有那张分层模型的图。根密钥在哪？谁能用？密钥怎么轮换？备份怎么做？这些想清楚了，集成也就完成了一半。