4. TEE内部密钥生命周期：密钥生成、密钥存储、密钥使用、密钥销毁的安全要求
密钥在TEE里不是个静态的东西。它从生到死，每个阶段都有严格的安全要求。我见过不少项目，密钥算法选得挺强，结果在生命周期管理上出了漏洞——说白了，就像你家大门用了最好的锁，结果钥匙随便扔在门口垫子下面。
这一节，咱们就把密钥的四个阶段掰开揉碎讲清楚。
4.1 密钥生成：根必须正
密钥生成是生命周期的起点。这个阶段如果出了问题，后面再怎么加固都没用。
核心要求：真随机数 + 硬件熵源
TEE内部的随机数生成器（TRNG）必须依赖硬件物理熵源，比如芯片上的热噪声、环形振荡器抖动。绝对不能拿软件伪随机数生成器（PRNG）来生成密钥——我在项目中遇到过有人图省事，直接用标准库的rand()去生成设备密钥，结果同一批次设备的密钥居然有规律可循，嗯，那场面相当尴尬。
密钥生成的安全基线：
- 必须使用TEE提供的硬件TRNG接口
- 生成过程中不允许将密钥明文暴露到REE侧
- 生成后立即写入安全存储，不留临时副本
- 支持密钥派生（KDF），避免直接使用根密钥
我个人习惯，在生成设备根密钥（Device Root Key）时，还会额外做一次「混合熵源」校验——把硬件TRNG的输出和芯片唯一ID（如OTP中的UID）做一次HMAC，确保即使TRNG出现极端故障，密钥也不会退化为全零或固定值。
4.2 密钥存储：锁进保险柜
密钥生成之后，就得找个地方存起来。TEE里的密钥存储，跟普通文件存储完全是两码事。
存储层级：
| 层级 | 存储介质 | 典型用途 | 安全强度 |
|---|---|---|---|
| L0 | OTP / eFuse | 根密钥、芯片身份密钥 | 最高（物理不可篡改） |
| L1 | TEE安全内存（SRAM） | 会话密钥、临时派生密钥 | 高（掉电即失） |
| L2 | TEE安全存储（RPMB/加密Flash） | 持久化密钥、证书私钥 | 中高（加密+完整性保护） |
存储阶段的关键约束：
- 密钥必须以密文形式存储，加密密钥本身由硬件绑定的根密钥保护
- 存储区域必须与REE完全隔离，TEE侧CPU的MMU会阻止REE访问
- 每次读取密钥时，需要做完整性校验（比如GCM的认证标签）
- 密钥存储区应具备防侧信道攻击能力——我曾经见过一个方案，密钥存储区的读取时间跟密钥值相关，结果被时序分析攻破
⚠️ 特别注意：千万不要把密钥明文写进日志或调试接口。我在审计一个TEE方案时，发现厂商在调试阶段把设备私钥通过串口打印出来了，量产时忘了关——这相当于把保险柜密码贴在了保险柜门上。
4.3 密钥使用：用完即走
密钥被拿出来用的时候，是最容易出问题的阶段。你想想看，密钥在内存里是活的，各种操作都在访问它。
使用阶段的安全要求：
- 最小权限原则：每个TA（可信应用）只能访问它自己的密钥，不能跨TA访问
- 操作隔离：密钥的运算（签名、加密、解密）必须在TEE内部完成，密钥明文不得离开TEE边界
- 使用计数：对一次性密钥（如OTP令牌密钥），使用后立即失效
- 上下文绑定：密钥使用时应绑定会话ID或操作上下文，防止重放攻击
举个例子，SM2签名操作在TEE里的典型流程是这样的：
// 伪代码：TEE内部SM2签名流程
1. TA发起签名请求，传入消息哈希和密钥句柄
2. TEE内核校验TA是否有该密钥的使用权限
3. 从安全存储中解密密钥到安全内存（临时）
4. 硬件密码引擎执行SM2签名运算
5. 返回签名值给TA
6. 立即擦除安全内存中的密钥明文
注意第6步——用完就擦，一秒都不多留。我调试过一个性能问题，发现密钥在内存里驻留了太久，虽然加了锁，但理论上增加了被侧信道攻击的窗口期。
💡 我的经验：在密钥使用阶段，建议引入「密钥老化」机制。如果一个密钥被频繁使用，超过一定阈值后自动触发重新派生。这样即使某个会话密钥被泄露，影响范围也有限。
4.4 密钥销毁：死要见尸
密钥销毁往往是被忽视的一环。很多人觉得「不用了删掉就行」，但在TEE里，销毁比生成更讲究。
销毁的三种场景：
- 正常销毁：密钥到期、设备退役、用户注销
- 应急销毁：检测到物理攻击、TEE完整性被破坏
- 安全销毁：防止通过残留数据恢复密钥
销毁操作的技术要求：
| 要求项 | 说明 |
|---|---|
| 覆写次数 | 至少覆写3次（全0、全1、随机数），NIST建议7次 |
| 存储介质 | Flash/RPMB需要执行物理擦除命令，不能只删文件 |
| 缓存清理 | 同时清除CPU缓存、TLB、寄存器中的残留 |
| 日志清理 | 确保密钥从未被记录到任何持久化日志中 |
| 原子性 | 销毁操作不可中断，防止部分擦除导致密钥可恢复 |
我曾经遇到过一个问题：设备在做OTA升级时，旧密钥需要销毁。结果销毁流程被异常断电打断，密钥只擦了一半。重启后，TEE发现密钥校验失败，直接变砖了。后来我们加了一个「两阶段销毁」——先标记为待销毁，确认后再执行物理擦除，中间状态可恢复。
⚠️ 避坑指南：销毁操作一定要有「证明」。也就是说，销毁完成后，TEE应该能向外部证明该密钥确实已被销毁。这在合规审计中非常关键，尤其是金融级别的TEE方案。
4.5 生命周期全景图
下面这张图把四个阶段串起来了。你可以把它当作TEE密钥管理的检查清单。
这张图里我特意加了一个逆向箭头——密钥销毁后，在某些场景下（比如设备重置或密钥轮换）需要重新生成。这不是循环，而是生命周期管理的闭环。
4.6 小结
密钥生命周期管理，说白了就是四个字：管生、管存、管用、管死。每个阶段都有对应的技术手段和安全约束，漏掉任何一个环节，整个TEE的安全信任链就可能断裂。
我个人习惯在做TEE方案设计时，先把生命周期画出来，然后逐个阶段做威胁建模。你会发现，很多安全漏洞其实就藏在阶段转换的边界上——比如密钥从存储到使用的加载过程，或者从使用到销毁的清理过程。这些边界，才是真正需要下功夫的地方。