4. TEE内部密钥层次结构：设备密钥、身份密钥、会话密钥、应用密钥的层级关系与用途

密钥管理是TEE安全体系的基石。说白了，如果密钥本身都保护不好，那TEE就是个空壳子。我这些年做TEE方案，见过太多因为密钥层次设计不合理导致的安全事故。今天咱们就聊聊TEE内部的四层密钥体系。

这四层密钥，从底层到上层分别是：设备密钥、身份密钥、会话密钥和应用密钥。它们像一座金字塔，底层保护上层，上层依赖底层。

核心原则：每一层密钥只做自己该做的事，绝不越权。设备密钥永远不出TEE硬件边界，身份密钥只在认证时使用，会话密钥用完即焚，应用密钥按需生成。

设备密钥是所有密钥的根。它通常在芯片制造阶段被写入硬件熔丝（eFuse）或一次性可编程存储器（OTP）中。每台设备都有唯一的设备密钥，而且一旦写入，物理上就无法读取。

我参与过一个项目，客户想把设备密钥存到文件系统里。我当时就急了——这等于把保险柜钥匙挂在门上。设备密钥必须满足三个条件：

我的经验：设备密钥的派生过程一定要加盐。我曾经见过一个方案直接用设备密钥加密数据，结果所有设备都用同一个算法，一旦密钥被逆向工程，整个产品线全废。正确的做法是用HKDF或类似算法，结合设备ID、厂商ID等信息做派生。

身份密钥由设备密钥派生而来，用于向外界证明「我是谁」。它通常是一对非对称密钥（比如ECDSA或RSA），私钥在TEE内部生成并保护，公钥可以安全地对外发布。

你想想看，远程服务器怎么知道跟你通信的是一个真实的TEE，而不是一个模拟器？靠的就是身份密钥。TEE会用身份密钥的私钥对挑战值签名，服务器用公钥验证签名。这个过程叫远程认证（Remote Attestation）。

身份密钥的生命周期管理很重要。我记得有一次，客户的产品需要更换身份密钥，但原来的密钥已经用于大量设备的认证。我们不得不设计一套密钥轮换协议，新旧密钥并行运行三个月才完成切换。

会话密钥是临时协商出来的对称密钥，用于保护一次通信会话。它的特点是：生命周期极短，用完就销毁。

为什么需要会话密钥？因为非对称加密太慢了。你想想看，每次传输数据都用身份密钥的私钥加密，性能根本扛不住。所以实际做法是：先用身份密钥做认证，然后协商一个临时的会话密钥，后续通信都用这个会话密钥做对称加密。

会话密钥的协商过程通常基于ECDH或类似协议。TEE和远程服务器各自生成临时密钥对，交换公钥，然后各自计算出共享密钥。这个共享密钥就是会话密钥。

我曾经踩过的坑：有一次我们没做会话密钥的完美前向安全性（PFS）。结果三个月后，攻击者拿到了服务器的长期私钥，把之前所有记录的会话都解密了。从那以后，我坚持所有会话密钥协商必须支持PFS，每次会话都生成新的临时密钥对。

应用密钥是最上层的密钥，直接服务于具体的业务场景。比如支付应用需要签名密钥，DRM应用需要解密密钥，身份认证应用需要存储密钥。

应用密钥由上层密钥（通常是会话密钥或身份密钥）派生或加密保护。每个应用可以有多个密钥，每个密钥用于不同的目的。

我个人习惯把应用密钥分成三类：

应用密钥的管理要遵循最小权限原则。每个应用只能访问自己的密钥，不能跨应用访问。我记得有个项目，两个应用共用了同一个密钥，结果一个应用被攻破，另一个也跟着遭殃。从那以后，我坚持每个应用必须有独立的密钥空间。

关键设计原则：应用密钥的生成必须绑定应用身份。也就是说，同一个TEE上的不同应用，即使使用相同的派生算法，得到的密钥也不同。这可以通过在派生时加入应用ID作为输入参数来实现。

说了这么多理论，咱们看看实际流程是什么样的。假设一个TEE应用需要与远程服务器建立安全通信：

这个流程看起来简单，但每个环节都有坑。比如在派生应用密钥时，一定要用HKDF而不是简单的哈希。我曾经见过直接用SHA256(会话密钥 || 应用ID)做派生的方案，结果因为输入长度不够，导致密钥空间严重缩小。

我的建议：使用标准的密钥派生函数，比如HKDF-extract-then-expand。输入参数至少包括：源密钥、上下文信息（应用ID、用途标签）、随机数（如果需要）。输出长度根据实际需求选择，AES-256就输出32字节。

好了，这四层密钥的关系和用途就讲到这里。记住一句话：底层保安全，上层保灵活。设备密钥是根，身份密钥是门面，会话密钥是桥梁，应用密钥是工具。每一层都有自己的职责，别让它们越界。