密钥管理基础：对称密钥、非对称密钥、密钥存储与轮换策略

聊到密钥权限审计SDK，咱们得先搞清楚底层的密钥管理是怎么回事。你想想看，所有权限校验、签名验签、越权检测，根基都在密钥上。密钥管不好，上层安全就是空中楼阁。今天我就把对称密钥、非对称密钥、存储和轮换这几个核心点，掰开了跟你讲透。

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

对称密钥，说白了就是加密和解密用同一把钥匙。我在早期做嵌入式SDK时，用的就是AES-128。效率高，适合大数据量加解密。但有个致命问题：密钥怎么安全地交给对方？

对称算法常见的有：

• AES（Advanced Encryption Standard）：目前最主流。密钥长度128、192、256位。我建议你项目里至少用AES-256。
• SM4：国密标准，国内政企项目必用。结构和AES类似，但算法细节不公开（嗯，其实是公开的，只是商用密码管理局管控）。
• DES/3DES：老古董了。DES密钥太短（56位），现在已经能被暴力破解。我见过某些老旧系统还在用，赶紧迁移吧。

非对称密钥：一对钥匙各司其职

非对称密钥，核心是一对密钥：公钥公开，私钥自留。公钥加密的数据只能用私钥解密，反过来私钥签名可以用公钥验真。这解决了对称密钥分发时的信任难题。

常见的非对称算法：

• RSA：经典但慢。密钥长度至少2048位。我在项目中常用于数字签名和密钥交换，但从不拿它加密大量数据。
• ECC（椭圆曲线）：用更短的密钥达到同等安全强度。256位的ECC相当于3072位的RSA。适合移动端SDK，密钥体积小，运算速度也快。
• SM2：国密ECC算法。国内新系统基本都要求支持。我建议做国内市场的SDK，SM2是必选项。

对称 vs 非对称：怎么选？

我的经验是：不选边，结合用。非对称用于密钥协商和身份认证，对称用于实际数据加密。比如HTTPS就是这样做的：握手阶段用RSA或ECC交换对称密钥，后续通信全部用AES加密。

密钥存储：安全的第一道防线

密钥放哪里？这是个老问题。我见过直接把密钥硬编码在代码里的——嗯，逆向工程师看一眼就知道你在想什么。

安全的存储方式，按安全等级排个序：

1. 硬件安全模块（HSM）：最顶配。密钥根本不出硬件，所有运算在HSM内部完成。金融、CA系统标配。价格也好看，一台几万到几十万。
2. 安全芯片/可信执行环境（TEE）：手机里的SE、TEE就是干这个的。Android的KeyStore、iOS的Secure Enclave。我建议SDK的签名私钥必须走这里。
3. 操作系统密钥存储：Windows的DPAPI、macOS的Keychain、Linux的Keyutils。相对安全，但依赖系统安全。
4. 加密后的配置文件：实在没条件，至少把密钥混淆加密后再存到本地文件。密钥分散存储，别放在一起。我用一个简单的方案：密钥分段，一部分存配置，一部分由用户输入推导。

密钥轮换策略：不要一把钥匙用到底

密钥轮换，说白了就是定期换钥匙。为什么？密钥用久了，泄漏风险累积。而且一旦泄漏，攻击者可以用它解密旧数据。我的原则是：最小有效期。

常见的轮换策略：

• 时间驱动轮换：比如每90天换一次。我在项目里是设自动告警，到期前通知管理员。
• 事件驱动轮换：每次有重大变更——比如密钥疑似泄漏、人员离职、系统升级——立刻换。别等到出事再换，那时候已经晚了。
• 版本化管理：每个密钥必须有版本号。旧版本的密钥只用于解密旧数据，不能用于新加密。这样能控制暴露面。

轮换时要注意：

• 确认所有依赖该密钥的系统都更新完毕，再停用旧密钥。
• 保留旧密钥一段时间（我一般留2个周期），防止还有数据需要解密。
• 记录密钥生命周期：创建时间、启用时间、轮换时间、销毁时间。审计时要查的。

避坑指南：我踩过的坑，你别再踩

曾经有一次，我接手一个老旧系统的密钥迁移工作。原系统直接把DES密钥明文写在配置文件中，还沾沾自喜说「没人知道这个配置文件的路径」——结果攻击者通过一个目录遍历漏洞找到了它。整个数据保护形同虚设。所以，密钥的安全不能依赖「没人知道」，必须依赖算法和存储机制本身。

还有一个常见坑：轮换时忘记标记旧密钥的状态。某次我上线新密钥后，发现数据库里还有一批数据用的是旧密钥加密。旧密钥已经被标记为废弃，结果解密失败，数据救不回来。从那以后，我强制要求：旧密钥至少保留2个轮换周期，只解密，不加密新数据。

嗯，密钥管理就聊到这儿。这些基础打牢了，后面讲权限审计SDK的越权检测时，你才能理解密钥在其中的角色。记住：所有安全策略，最后都要落到密钥的生成、分发、存储、使用和销毁这五个环节上。