二、密钥管理基本概念与术语
聊密钥审计之前，先把底层的概念理一理。很多团队一上来就做配置、跑扫描，结果连「密钥生命周期该有几个阶段」都说不清楚——那审计肯定过不了。
我习惯把密钥管理比作「钥匙串管理」。你家钥匙丢了，换个锁芯就行；可密钥一旦泄露，整条数据链路都得重来。所以，每个术语背后都是真金白银的风险。
2.1 密钥是什么？
密钥就是一个参数，配合加密算法完成加解密操作。说白了，算法是锁芯，密钥才是那把钥匙。PCI DSS 要求私钥永远不能以明文形式出现在任何存储里——包括内存。
核心定义：密钥是用于加解密、签名验签、MAC校验的对称或非对称秘密参数。密钥的保密性直接决定了数据的机密性。
举个例子：你用了 AES-256，算法本身是公开的，全世界都知道怎么算。但谁拿到了那个 256 bit 的 Key，谁就能解开密文。所以保护密钥就是保护一切。
2.2 密钥类型
先看最基础的分类。PCI DSS 里两种类型都会用到，但合规焦点不一样。
| 类型 | 特点 | 常见算法 | PCI 审计关注点 |
|---|---|---|---|
| 对称密钥 | 加密和解密用同一个密钥 | AES, 3DES, SM4 | 密钥传输加密、存储加密、脱敏数据保护 |
| 非对称密钥 | 公钥加密，私钥解密；或者私钥签名，公钥验签 | RSA, ECC, SM2 | CA 证书、TLS 握手、消息签名 |
我在项目中遇到过好几次这样的混淆：有人把 RSA 私钥直接写在配置文件里，理由是「这个服务只在内网跑」。嗯，内网也不等于安全——PCI DSS 不认这个。
2.3 密钥生命周期
密钥不是静态的。从产生到销毁，每个环节都有明确的合规要求。我个人习惯把生命周期画成一条流水线，方便跟安全团队对齐。
上面这张图看着简单，实际操作时很容易出问题。我踩过最深的坑是密钥归档——归档的密钥不能删除、不能继续用在活跃交易中，但必须保留用于历史数据解密。很多公司直接写个脚本把旧密钥移到冷存储，结果没有目录索引，审计时根本找不到哪个密钥对应哪段数据。
2.3.1 生成
密钥必须在符合 FIPS 140-2 或等国密标准的硬件/软件随机数生成器里产生。不能用 Math.random()——这玩意儿不满足熵源要求。
避坑：我曾经在渗透测试时发现某支付网关的密钥是用当前时间戳做种子生成的。破解它只需要知道大致生成时间，再穷举几毫秒就行。所以，一定要用合格的熵源。
2.3.2 分发与传输
密钥传输时必须加密。常见的做法是使用非对称加密的 TLS 通道传输对称密钥。PCI DSS 不允许直接通过明文邮件、FTP 发送密钥——听到没？SMTP 传输就是明文。
2.3.3 使用与存储
使用中的密钥应尽量放在HSM（硬件安全模块）或密钥保险库里，不要在应用代码里缓存明文密钥。我见过一个案例：开发为了方便，把主密钥写死在 Java 静态变量里，结果被一次堆转储全泄露了。
2.3.4 归档与销毁
归档密钥要加时间戳和用途标签。销毁则必须执行「密码学销毁」——光删文件不够，磁盘覆写或者直接物理销毁存储介质才行。PCI DSS 对销毁的要求是：密钥永不可恢复。
2.4 密钥长度与算法要求
PCI DSS 对密钥强度有硬性规定。下表是基于当前版标准（v4.0）的参考值：
| 算法 | 最小密钥长度 | 备注 |
|---|---|---|
| AES | 128 bit（推荐 256） | 3DES 已被禁用，2025年后不支持 |
| RSA | 2048 bit | 1024 bit 已不安全，禁止使用 |
| ECC | 224 bit（推荐 256） | P-256 是常见选择 |
| SM2 | 256 bit | 国密标准，等保环节需关注 |
你想想看，为什么 RSA 需要 2048 位，而 ECC 只要 256 位？因为数学结构不同。RSA 依赖大整数分解，ECC 依赖椭圆曲线离散对数 —— 破解难度远高于普通质因数分解。
实用建议：新项目尽量选 AES-256 + ECC P-256 组合，性能好且合规风险低。老项目如果还用 3DES，建议尽快迁移。
2.5 关键术语速查
下面这些术语在 PCI DSS 审计报告里频繁出现。记住它们，跟审计员交流时才不会卡壳。
- KEK（密钥加密密钥）——用来加密其他密钥的密钥。通常存储在 HSM 中，不许离开安全区域。
- DEK（数据加密密钥）——直接用来加密业务数据。KEK 再保护 DEK。
- 主密钥（Master Key）——层次最高的密钥，所有 KEK 和 DEK 最终由它派生或加密。主密钥丢失 = 数据全废。
- 密钥轮换（Key Rotation）——定期更换密钥，降低泄露后影响范围。PCI DSS 建议信用卡数据密钥至少 1 年轮换一次。
- 密钥版本（Key Version）——同一个密钥的多个代次。可以用时间戳或递增编号表示。
- 加密上下文（Crypto Context）——每个密钥的用途、算法、有效期、创建人等信息，审计员会要求你提供完整记录。
切记：审计员不会只看密钥是不是 AES 的。他们会问：「你的 KEK 存放在哪里？谁有权访问？轮换周期多久？」。这些问题全部要有文档和日志支撑。
2.6 一个小总结
密钥管理不是「配一把钥匙」那么简单。它涉及生成、分发、使用、存储、归档、销毁六大阶段，每个阶段都有严格的 PCI DSS 要求。概念和术语是基础，但也是审计最容易出漏洞的地方——很多人搞不清 KEK 和 DEK 的区别，导致密钥分层架构都写错了。
嗯，这一章先到这里。把概念吃透，后面聊密钥审计策略和HSM配置时才能跟上节奏。