对称密钥的生成与SDK集成

各位好，欢迎来到第3章。前面我们聊了密钥生命周期管理的整体框架，那是张地图。现在，咱们要开始走真正的第一步了——生成那把锁。

对称密钥的生成，听起来不就是调个随机数吗？其实这里头坑不少。我个人习惯把“生成”拆成两件事：熵的质量和算法的选择。今天的SDK，既然要集成到别人的系统里，就得同时扛住这两关。

先搞清楚核心标准

做SDK，第一件事就是选定你支持的算法和密钥长度。别贪多，别乱搭。我见过一些SDK，为了兼容性，把DES都留着了。说实话，这只会让安全审计直接亮红灯。

下面这张表，是我在项目里经常用来对标的“安全三件套”：

算法	推荐密钥长度（位）	SSP 建议
AES	128 / 256	128 bit 足够商用，256 bit 可过国密合规
ChaCha20	256	移动端或资源受限环境优先
SM4（国密）	128	国内合规必选

你想想看，为什么我不推荐192位？不是不能用，是这种长度在实际落地上特别尴尬。我曾经在一个项目中，因为客户指定了192位，导致所有的硬件加速卡都要单独写一层适配层，纯属给自己找麻烦。

真随机 VS 伪随机：你的种子安全吗？

对称密钥的本质是一串随机字节。但“随机”这两个字，在工程上分三六九等。

• 真随机数（TRNG）：从物理噪声中提取。靠谱，但慢。硬件里有，普通服务器需要靠外设。
• 密码学安全伪随机数（CSPRNG）：用一个种子做迭代。速度极快，前提是种子必须真随机。

在SDK里，我建议你这样选：

• 如果是在桌面端或移动端，直接调操作系统的 CSPRNG 接口：/dev/urandom（Linux）、CryptGenRandom（Windows）、SecRandomCopyBytes（iOS）。
• 如果是在云端或嵌入式设备，优先使用硬件安全模块（HSM）或可信执行环境（TEE）提供的随机数接口。

// Java 示例：通过 SecureRandom 生成 AES 256 位密钥
import javax.crypto.KeyGenerator;
import java.security.SecureRandom;

public class SymmetricKeyGenerator {
    public static byte[] generateAESKey() throws Exception {
        KeyGenerator keyGen = KeyGenerator.getInstance("AES");
        // 这里的关键：让 SecureRandom 使用操作系统的真随机种子
        SecureRandom secureRandom = new SecureRandom();
        keyGen.init(256, secureRandom);
        return keyGen.generateKey().getEncoded();
    }
}

代码很短，对吧？但注意那个 SecureRandom 的默认构造。不同的 JVM 实现可能默认不靠谱。我在项目中遇到过一次，某国产 JVM 的 SecureRandom 居然回退到了伪随机模式。后来我们把种子源显式指定为 NativePRNGBlocking 才解决。

HKDF：SDK 里的“万能钥匙”

很多时候，我们不直接生成密钥，而是从一个“主密钥”推导出多个“子密钥”。这就涉及密钥派生函数（KDF）。

在对称密钥场景里，我强烈推荐 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）。为什么要用它？因为单纯的哈希或简单的 HMAC 推导很容易产生结构化的密钥，容易侧信道攻击。HKDF 的“提取-展开”两步法，说白了就是把熵摊平、摊均匀。

SDK 里怎么集成？别自己实现 HKDF 算法，直接用标准库。比如 Java 平台的 javax.crypto 里没有直接封装 HKDF，但 Bouncy Castle 或者 JDK 17 以后的 SecretKeyFactory 都能做。

// Java 使用 Bouncy Castle 实现 HKDF 派生
import org.bouncycastle.crypto.generators.HKDFBytesGenerator;
import org.bouncycastle.crypto.params.HKDFParameters;
import org.bouncycastle.crypto.digests.SHA256Digest;

public class HKDFDerivation {
    public static byte[] deriveKey(byte[] inputKeyMaterial, byte[] salt, int length) {
        HKDFBytesGenerator hkdf = new HKDFBytesGenerator(new SHA256Digest());
        HKDFParameters params = new HKDFParameters(inputKeyMaterial, salt, null);
        hkdf.init(params);
        byte[] derivedKey = new byte[length];
        hkdf.generateBytes(derivedKey, 0, length);
        return derivedKey;
    }
}

SVG：对称密钥生成与派生流程图

SDK 集成：API 设计的几个坑

刚才的流程图已经说明了技术路径。现在咱们落地到 API 设计上。

你想想看，一个生成的密钥，如果直接以 byte[] 的形式返回给上层使用方，那就是裸奔。万一被日志或者异常堆栈 dump 出来，后果不堪设想。我在第一次做 SDK 时，就把密钥指针暴露出去了，被安全同事骂了一顿。

正确的做法，是提供一个不透明的密钥句柄（Key Handle）。内部加密存储，对外只暴露一个引用 ID。

// Go 示例：返回不透明的密钥句柄
type KeyHandle struct {
    id   string
    data []byte // 实际密钥，内部持有，不暴露
}

func GenerateAESKey() *KeyHandle {
    key := make([]byte, 32)
    _, err := rand.Read(key) // crypto/rand
    if err != nil {
        panic("entropy source failure")
    }
    // 内部加密存储逻辑...
    return &KeyHandle{
        id:   generateUUID(),
        data: key,
    }
}

这样设计的好处是：外部只能通过句柄 ID 使用这个密钥，无法直接读取内存。内存泄漏的风险小了很多。

测试用例：验证你生成的密钥

密钥生成完了，你总得测一下吧？光测“能跑”不够，得测“安全”。

• 统计随机性测试：简单做法，对生成的 1024 个密钥做汉明重量分布测试。理论上不应该有显著偏差。
• 重复性测试：在同一个 JVM 生命周期内，生成 1 万次，确保没有一次密钥重复。如果出现了，你的熵源有问题。
• HKDF 向量测试：RFC 5869 里提供了标准的 test vector。一定要跑通。

// Python 测试伪代码：HKDF 向量验证
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes

def test_hkdf_vector():
    ikm = bytes.fromhex("0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b")
    salt = bytes.fromhex("000102030405060708090a0b0c")
    info = bytes.fromhex("f0f1f2f3f4f5f6f7f8f9")
    length = 42
    expected = bytes.fromhex("3cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865")
    hkdf = HKDF(algorithm=hashes.SHA256(), length=length, salt=salt, info=info)
    assert hkdf.derive(ikm) == expected

有一次，我在升级 SDK 依赖时发现，新版本的密码库在 MacOS M1 芯片上对 HKDF 的实现有一个整数溢出 bug。如果不是提前跑了这里写的向量测试，那上线后出的密钥就全错了。所以，测试向量是护身符。