3、SM2密钥生成：在TEE里把钥匙造结实

密钥生成，是所有密码学操作的起点。你想想看，如果钥匙本身就不安全，后面再怎么加密、签名，都是白搭。SM2的密钥对生成，说白了就是算出一对满足椭圆曲线关系的整数——私钥是个随机大数，公钥是私钥乘以基点。道理不复杂，但落地到TEE环境里，门道就多了。

我个人习惯把密钥生成分成三个层面来看：数学原理、工程实现、安全边界。咱们一个一个聊。

3.1 密钥对生成的数学原理

SM2使用的是256位素域上的椭圆曲线，参数是国密标准里定死的。生成密钥对就两步：

1. 选一个随机数 d，范围在 [1, n-2] 之间，n是基点G的阶。
2. 计算公钥 P = d * G，G是标准基点。

就这么简单？嗯，数学上确实就这两步。但这里有个坑——d 必须真随机，不能有任何偏差。我在项目中遇到过有人直接用C语言的rand()生成私钥，结果被侧信道攻击一把薅走。你想想看，rand()的周期才多大？2^32都不到，暴力枚举都能给你扫出来。

公钥计算用的是标量乘法，也就是点乘。这个运算在普通CPU上大概几毫秒，但在TEE里，因为资源受限，可能会慢一些。不过没关系，密钥生成通常是一次性的，慢点也能接受。

3.2 在TEE内生成SM2密钥对的安全优势

为什么非要在TEE里生成密钥？直接在普通操作系统里生成不行吗？

我跟你讲个真实案例。有一次我帮客户做安全审计，发现他们的密钥生成流程是这样的：应用层调用OpenSSL生成密钥对，然后把私钥写到文件里。你猜怎么着？私钥文件权限是644，任何进程都能读。更离谱的是，内存里的私钥还会被swap到磁盘上，一抓一个准。

在TEE里生成密钥，优势是结构性的：

安全维度	普通环境	TEE环境
私钥可见性	操作系统、其他进程可读	仅TEE内部可见，外部无法访问
内存保护	可能被swap到磁盘	内存加密，防物理读取
侧信道防护	依赖软件实现	硬件隔离+恒定时间实现
持久化安全	依赖文件系统权限	密封存储，绑定TEE身份

说白了，TEE给密钥生成提供了一个"黑盒子"。私钥从出生到死亡，都在这个黑盒子里，外面的人连看都看不到。我曾经在Intel SGX上做过测试，即使操作系统被攻破，攻击者也拿不到TEE enclave里的私钥——除非他物理拆芯片。

3.3 随机数生成器的安全要求

随机数生成器，是密钥生成的命门。SM2私钥的强度，100%取决于随机数的质量。如果随机数能被预测，那整个密码体系就形同虚设。

我记得有一次，某个厂商的TEE方案用了硬件随机数生成器，但没做健康测试。结果那颗芯片的TRNG在低温下输出全是0xAAAAAAAA，生成的私钥全是固定模式。嗯，这事儿后来成了行业笑话。

在TEE里，随机数生成器必须满足以下要求：

• 真随机性：必须基于硬件熵源，不能只用软件伪随机。TEE通常有专用的TRNG外设。
• 后处理：原始熵源可能有偏差，需要通过SHA-256或SM3进行去偏和扩展。
• 健康测试：每次生成前都要做在线自检，比如重复计数测试、自适应比例测试。
• 抗预测性：即使攻击者知道部分熵源输出，也无法预测后续输出。
• 恒定时间：随机数生成过程不能有数据依赖的分支或时序变化。

具体到SM2密钥生成，随机数的长度是256位，但实际需要的熵至少是256位。我建议使用双倍长度的随机数，然后通过SM3哈希截断到256位。这样即使硬件熵源有微小偏差，也能被哈希函数抹平。

下面是一个简化的密钥生成流程图，展示了TEE内SM2密钥对生成的核心流程：

这个流程看起来简单，但每一步都有坑。比如健康测试，不能只做一次，要持续监测。我曾经在项目中加了一个定时器，每10秒触发一次TRNG自检，一旦发现熵源异常，立即熔断密钥生成接口。

还有一个容易被忽略的点：随机数生成器的初始化向量。TEE启动时，TRNG需要一段"预热"时间，才能输出高质量随机数。我建议在TEE初始化阶段预留至少100ms的预热时间，期间生成的随机数直接丢弃。

最后说一句，密钥生成完成后，私钥一定要用TEE的密封存储机制保存。密封密钥通常绑定TEE的度量值，也就是说，只有同一个TEE镜像才能解开。这样即使攻击者拿到了密文，在其他设备上也解不开。