📚 课程目录第4章密钥管理基础

第四章：密钥管理基础——对称、非对称与哈希

做RBAC审计，绕不开密钥。你权限边界画得再漂亮，密钥一泄露，全白搭。我这些年被叫去救火的审计项目，十有八九都跟密钥管理粗放有关。这一章咱们把三种基础工具说透——对称密钥、非对称密钥、哈希函数。搞清楚它们的原理和适用场景，后面讲密钥生命周期和审计策略才站得住脚。

4.1 对称密钥：一把钥匙开一把锁

对称密钥，顾名思义，加密和解密用的是同一个密钥。就像你家的门锁，一把钥匙既能锁门也能开门。

核心流程：

发送方用密钥K对明文进行加密，得到密文。
密文通过网络传输。
接收方用同样的密钥K解密，还原明文。

我在项目里见过最典型的对称算法是AES。当年给一个金融核心系统做审计，他们所有数据库连接串都用AES-256加密存储在配置文件里。当时我就问了句：“密钥放哪？”结果对方指着同一台服务器的环境变量……嗯，加密倒是没毛病，可密钥跟密文放一块，跟没锁门有什么区别？

算法	密钥长度	典型用途	备注
AES	128/192/256位	数据加密、文件加密	目前最广泛
DES	56位	历史遗留	已不安全，别用
3DES	112/168位	兼容场景	性能差，逐渐淘汰

    关键认知：对称加密快，适合大批量数据。但密钥分发是个大坑——你如何安全地把密钥交给对方？如果通过网络传，传密钥的通道本身就得加密，死循环。

4.2 非对称密钥：公钥私钥，各司其职

非对称密钥解决了密钥分发的问题。每个参与方有一对密钥：公钥公开，私钥自己藏好。公钥加密的数据只有对应的私钥能解，反过来私钥签名的东西，公钥能验。

举个实际场景：

你要向一个RBAC系统上传一份用户权限变更申请。系统给你它的公钥，你用公钥加密申请文件。文件传输过程中被截了，对方没有私钥，解不开。到你拿到系统私钥的那头，才解密处理。反过来，如果你用自己私钥签名了一份文件，系统用你的公钥验证签名，就能确认文件确实是你发的——这就是数字签名。

我曾经踩过的坑：有次审计发现一个支付网关的公钥直接硬编码在JavaScript前端代码里。前端用这个公钥加密用户密码后再传给后端。乍一看没问题吧？但前端代码任何人都能看，公钥本就可公开，这倒不是关键。问题是他们用公钥加密的是密码明文，可公钥加密的密文，只要攻击者拿到了发送时的网络包，虽然解不开密码，但他可以重放这个密文，模拟登录。正确做法应该是用HTTPS+哈希加盐，而不是前端公钥加密。细节咱们后面章节讲。

算法	密钥长度	典型用途	性能
RSA	2048/4096位	加密、数字签名、密钥交换	慢，适合小数据
ECC（椭圆曲线）	256位（等价RSA 3072）	移动端、IoT、区块链	快，密钥短
DSA/ECDSA	同上	数字签名专用	不能加密

说到这我想起一个细节：非对称加密很慢，所以实际应用中极少直接用它加密大文件。你想想看，一个10GB的日志文件用RSA加密，要算到猴年马月？所以真正的做法是——混合加密：用非对称加密交换对称密钥（比如通过TLS握手），然后对称加密后续所有数据。

4.3 哈希函数：单向不可逆，防篡改

哈希不是加密。它没有密钥，也不能解密。它的核心价值是完整性校验和指纹生成。

一个合格的哈希函数得满足三个特性：

单向性：从哈希值反推原始输入，理论上不可行。
抗碰撞：很难找到两条不同消息，哈希值相同。
雪崩效应：输入改动一个bit，输出的哈希值天差地别。

我在RBAC审计里最常用哈希的地方是校验权限策略文件的完整性。比如你定义了一组JSON格式的权限策略，发布前计算一次SHA-256哈希，存到数据库。每次加载策略时再算一次，跟存的值对比。如果文件被篡改哪怕一个空格，哈希都对不上，直接告警。

算法	输出长度	状态	推荐吗？
MD5	128位	已被破解	不推荐
SHA-1	160位	碰撞攻击可行	不推荐
SHA-256	256位	安全	✅ 强烈推荐
SHA-3	可配置	新一代	✅ 用于前沿系统

一个小技巧：存储用户密码时，千万别直接用哈希——要用加盐哈希。每次用户注册，随机生成一个盐值（至少16字节），跟密码拼在一起再哈希。这样一来，即使用户的密码是“123456”，每个用户的哈希值也不一样。我见过老系统直接存MD5(密码)，彩虹表一秒破解，惨不忍睹。

4.4 三种工具的关系与典型组合

说实话，现实中的系统不会只用一种。它们各司其职，配合使用：

对称密钥：扛起数据传输和存储加密的主力，速度快。
非对称密钥：负责密钥交换、数字签名、身份认证，解决信任起点。
哈希函数：验证数据有没有被改过，或者给密码、签名生成指纹。

你想想看，HTTPS协议就是三者的教科书式组合：先通过非对称密钥（RSA/ECC）和证书完成握手和密钥交换，生成临时的对称会话密钥（AES），然后用对称密钥加密所有HTTP流量，过程中还用哈希函数（SHA-256）做消息完整性校验。三个工具缺一不可。

    审计要点：做RBAC密钥权限边界审计，你首先得搞清楚系统里这三种工具分别用在什么地方、密钥存在哪里、谁有权限接触密钥。比如：对称密钥一般由密钥管理系统（KMS）统一托管；非对称密钥的私钥要存硬件安全模块（HSM）或安全飞地；哈希用的盐值也不能硬编码。这些边界一旦模糊，就是安全隐患。

4.5 边界审计中绕不开的问题

做RBAC密钥权限边界审计，我习惯先问几个问题：

谁有钥匙？ 对称密钥的存储位置、访问控制列表（ACL）是否合理？私钥是否只在HSM里生成和运算？
钥匙怎么来的？ 密钥分发过程有没有审计日志？是否使用了安全的密钥交换协议（如ECDH）？
钥匙过期了怎么办？ 密钥轮换策略、旧密钥销毁流程是否落地？
哈希用对了没？ 密码存储是否加盐？消息完整性校验是否使用了强哈希（如SHA-256）？有没有还在用MD5或SHA-1的角落？

我曾经在一个遗留系统中发现：他们的RBAC策略文件签名还在用SHA-1，而且签名用的私钥居然是2048位RSA，但私钥明文存在共享文件服务器上，任何人都能读。更离谱的是，他们用同一个密钥对既做签名又做加密。这违反了密码学最基本的原则——密钥用途分离。签名用的私钥和加密用的私钥应该完全不同。一个泄露了，另一个还能保得住。审计报告里我直接标了“严重”。

好了，这一节讲到这里。对称、非对称、哈希，三种工具就像螺丝刀、扳手和锤子——各有各的用法，用错了地方不但不管用，还容易砸着自己的脚。记住它们的差异，后面讲密钥生命周期管理时你就能快速判断：什么地方该用对称、什么地方该用非对称、什么地方牵涉到哈希校验。审计边界才能画得准。