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

4. SM4密钥管理：生成、存储、分发

密钥管不好，加密就等于没锁。我个人习惯把它分成三段来看：密钥怎么来的、放哪儿安全、怎么安全交给对方。这三步只要有一个环节出问题，整个接口加密就白搭。下面我们一个一个聊。

  核心原则：SM4的密钥长度固定128位（16字节），整个生命周期都要保证其机密性、完整性和可用性。

4.1 密钥生成：别用随机数糊弄自己

SM4的密钥就是128位随机比特。但你想想看，如果随机数质量不好，攻击者可以用字典猜出来。我早年见过一个项目，直接用Math.random()生成密钥，结果密钥重复率奇高——那等于没加密。

正确做法是用密码学安全的随机数生成器。Java里用SecureRandom，Python用secrets._bytes(16)，Go用crypto/rand。这里给个Java示例：

// 生成SM4密钥（16字节）
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import org.bouncycastle.jce.provider.BouncyCastleProvider;

Security.addProvider(new BouncyCastleProvider());
KeyGenerator kg = KeyGenerator.getInstance("SM4", "BC");
kg.init(128); // 密钥长度128位
SecretKey key = kg.generateKey();
byte[] keyBytes = key.getEncoded();  // 16字节

小技巧：生产环境中可以定期从硬件安全模块（HSM）或密钥管理服务（KMS）获取随机种子，避免纯软件随机源在容器启动时熵不够。

4.2 密钥存储：明文存？你是认真的吗

密钥生成之后第一件事——存起来。我见过最离谱的操作是把密钥写死在配置文件里，还提交到Git仓库。嗯，那简直是开门揖盗。

存储层次上，我习惯按安全等级分三类：

内存级：运行时只存在于进程堆栈，用完立即擦除。可以用Arrays.fill(keyBytes, (byte)0)清零。
文件级：加密后存文件，解密的密钥由KMS或密码派生。
硬件级：放入HSM、TEE（如Intel SGX）或专用安全芯片。API和接口签名必须走硬件内部运算，密钥永不出设备。

实际接口项目中，最常用的是方案二：把SM4密钥用另一个主密钥加密后存数据库或配置文件。解密时再从KMS拿到主密钥。结构大概这样：

// 示例：密钥加密存储（伪代码）
byte[] sm4Key = ...;                    // 原始SM4密钥
byte[] masterKey = kms.decrypt("master-key-id");        // 从KMS获取主密钥
byte[] encryptedSm4 = aesGcmEncrypt(masterKey, sm4Key); // 用主密钥加密SM4密钥
// 存储 encryptedSm4 到配置文件或数据库字段

这里要注意，主密钥的访问权限必须严格控制。我曾经遇到过存储层权限过大，一个开发就能读到加密后的密钥文件，然后他再用代码里硬编码的主密钥解密……所以主密钥的生命周期管理比SM4密钥本身更关键。

⚠ 禁则：不要将密钥直接写在代码、配置文件、环境变量或日志中。不要用《SM4 Key》这种变量名。日志框架可能会把异常栈中的字节数组打印出来。

4.3 密钥分发：怎么安全地让别人拿到你的密钥

接口通信需要两方持有相同密钥。怎么把密钥从一方安全传递给另一方？说白了，有三种主流方式：

方式	原理	适用场景	风险点
离线分发	人工拷贝（U盘、加密邮件、面对面）	内部系统、小规模部署	传输过程可能被截获；管理成本高
在线协商（密钥交换协议）	使用SM2非对称加密或DH变种在线协商SM4密钥	互联网接口、动态连接	需要PKI或证书；中间人攻击需防范
密钥中心（KDC）	第三方可信中心下发会话密钥	大型分布式系统	单点故障；KDC本身需高安全

接口开发中最常见的是**在线协商**。比如用SM2公钥加密SM4密钥发给对方，对方用私钥解密得到密钥。流程大致这样：

服务端生成SM2密钥对，公钥发给客户端（可以内嵌在SDK或通过CA证书传递）。
客户端生成SM4密钥，用服务端公钥加密，发回服务端。
服务端用私钥解密，双方都持有相同的SM4密钥。
以后通信全部用该SM4密钥做对称加解密。

你可以把这种做法理解为“先通过非对称加密握手，再使用对称加密传输”。SM4的速度比SM2快几十倍，接口一旦建立就不需要频繁做非对称运算了。

  经验之谈：我参与过一个物联网项目，设备端无法联网获取密钥。最后采用离线分发：工厂生产时写入每个设备的唯一SM4密钥，并记录序列号，服务端维护密钥库。每次设备上线用序列号索引密钥。这种方式要防物理克隆，所以还要配合设备身份认证。

4.4 密钥轮换：别一把钥匙用到老

密钥用久了，被泄露的风险会累积。我个人建议接口的SM4密钥每24小时或每100万次调用轮换一次。具体周期看业务敏感度。轮换策略有两种：

主动轮换：服务端主动生成新密钥，通知客户端更新。适用于长连接场景，需要协商新密钥。
被动轮换：每次请求携带密钥版本号，服务端根据版本号查找当前有效的密钥。旧密钥在过期后从数据库标记删除。

被动轮换更灵活，我常用它。数据库里存一张密钥表：

-- 密钥表结构示例
CREATE TABLE sm4_keys (
    key_id      INT PRIMARY KEY AUTO_INCREMENT,
    key_version VARCHAR(16) NOT NULL UNIQUE,   -- 例如 "v20240301_001"
    key_data    VARBINARY(64) NOT NULL,        -- 用主密钥加密后的SM4密钥
    created_at  DATETIME DEFAULT CURRENT_TIMESTAMP,
    expires_at  DATETIME,                      -- 过期时间
    status      TINYINT DEFAULT 1             -- 1有效 0禁用
);

客户端请求时带上X-Key-Version: v20240301_001，服务端根据版本号获取解密后的SM4密钥，完成加解密。密钥过期后自动失效，防止旧密钥被滥用。

注意：轮换期间可能存在新旧密钥同时有效的窗口期。要保证旧的密钥在过期后的一小段时间内仍然可以解密历史数据，具体做法是允许服务端同时持有两个版本——当前版本和新版本。解密时优先用当前版本，失败时尝试上一个版本。

4.5 避坑清单

最后总结几条我踩过的坑，你写代码时多留个心眼：

密钥重复：用相同种子初始化随机数生成器，生成两个一模一样的密钥。我曾经压测时忘了重置SecureRandom，结果所有实例的密钥都相同。排查了半天。
密钥日志泄露：异常处理时把byte[]直接toString，会打印类似[B@15db9742，但如果你转成了Hex再打印，密钥就明文落盘了。
密钥硬编码在反向代理：Nginx配置里直接写SM4密钥，运维同学一查配置就看到了。应该用加密存储+运行时解密。
忘记清理内存：使用完密钥后，除非JVM自动GC，否则byte[]可能长期留在堆里。显式清零是个好习惯。
密钥版本号未校验：客户端传了一个过期或伪造的版本号，服务端没校验就直接用了，导致加密失效。任何版本号都要查表校验状态。

密钥管理没有银弹，但只要把生成、存储、分发、轮换四个环节都做到位，SM4接口的安全性就能上一个台阶。下次我们聊SM4的填充模式——这一块儿很容易在兼容性上栽跟头。