3. TPM2.0软件栈：TSS架构、ESAPI与SAPI、FAPI高层接口、TCTI传输层
好，咱们进入TPM2.0的软件栈部分。说实话，很多初学者一上来就被TSS（TPM Software Stack）的架构图吓住了——层数太多，接口太杂。我当年第一次看的时候也懵了，心想这玩意儿怎么这么绕？
但你别急。咱们一层层剥开，你会发现它其实很清晰。说白了，TPM芯片是硬件，你写应用不可能直接操作硬件寄存器吧？中间就需要一套软件栈来帮你做翻译、做封装、做调度。这就是TSS存在的意义。
3.1 TSS整体架构：分层解耦
TPM2.0的软件栈，我习惯把它看成“洋葱模型”。从最底层的硬件，到最顶层的应用，一共四层：
- TCTI（TPM Command Transmission Interface）：传输层，负责把命令发出去、把响应收回来。
- SAPI（System API）：系统API，直接对应TPM2.0规范里的命令，粒度最细。
- ESAPI（Enhanced System API）：增强型系统API，在SAPI基础上加了会话管理和参数加密。
- FAPI（Feature API）：高层接口，面向业务场景，封装了常见操作。
你想想看，这四层就像你写网络程序时的Socket、HTTP库、RESTful接口、SDK——越往上越省心，越往下越灵活。
核心原则：上层接口依赖下层接口，但下层不依赖上层。你可以跳过中间层直接调用底层，但代价是你要自己处理更多细节。
我画了一张图，帮你把这几层的关系理清楚：
3.2 TCTI传输层：最底层的“信使”
TCTI是整条链路的基石。它的职责很简单：把序列化后的TPM命令字节流发出去，再把响应字节流收回来。至于底层走的是什么通道——是/dev/tpm0字符设备、是模拟器socket、还是网络TPM——TCTI不管，它只负责“传”。
我记得有一次做嵌入式项目，TPM芯片是通过SPI总线连接的。标准的TCTI实现只支持LPC和I2C，SPI得自己写。嗯，那段时间我几乎把TCTI的源码翻了个底朝天。
实战经验：调试TCTI层时，最常用的手段是“抓包”。你可以在TCTI层插入一个日志回调，把每次发送的命令和收到的响应都打印出来。我曾经靠这个手段，抓到一个厂商固件里命令头长度字段算错了的bug。
TCTI的典型实现方式：
| TCTI类型 | 底层通道 | 适用场景 |
|---|---|---|
| 设备TCTI | /dev/tpm0 或 /dev/tpmrm0 | 本地硬件TPM |
| 模拟器TCTI | TCP socket（localhost:2321） | 开发调试、CI测试 |
| 网络TCTI | TCP socket（远程IP） | 远程TPM、云TPM |
| 自定义TCTI | SPI/I2C/USB等 | 嵌入式、特殊硬件 |
3.3 SAPI：直接操作TPM命令的“硬核”接口
SAPI是TPM2.0规范最忠实的映射。规范里定义了100多个命令，SAPI几乎一个不落地都暴露出来了。你用SAPI，本质上就是在拼装TPM命令缓冲区。
举个例子，你想用SAPI创建一个RSA密钥：
// SAPI方式创建RSA密钥（伪代码）
TPM2B_PUBLIC inPublic;
TPM2B_SENSITIVE_CREATE inSensitive;
TPM2B_DATA outsideInfo;
TPML_PCR_SELECTION creationPCR;
// 填充参数...（此处省略20行结构体赋值）
TPM_RC rc = Tss2_Sys_Create(
sysContext, // SAPI上下文
parentHandle, // 父密钥句柄
&inSensitive, // 敏感数据
&inPublic, // 公钥模板
&outsideInfo, // 外部信息
&creationPCR, // PCR选择
&outPrivate, // 输出私钥
&outPublic, // 输出公钥
&creationData, // 创建数据
&creationHash, // 创建哈希
&creationTicket // 创建票据
);
看到了吗？一个Create命令，参数列表长得吓人。我刚开始用SAPI的时候，光填这些结构体就花了大半天。但好处是——你完全掌控了每一个细节。
注意：SAPI不帮你管理会话（Session）。如果你需要授权会话或加密会话，得自己调用StartAuthSession、手动处理nonce和HMAC。这也是为什么后来有了ESAPI。
3.4 ESAPI：给SAPI穿上“铠甲”
ESAPI在SAPI外面包了一层，主要干了三件事：
- 自动会话管理：你不需要手动创建和销毁会话，ESAPI帮你搞定。
- 参数加密：敏感参数（比如口令、私钥）在传输过程中自动加密。
- 审计日志：可以记录每次命令的执行情况。
说白了，ESAPI就是SAPI的“安全增强版”。如果你做的是安全敏感的应用，我建议直接用ESAPI。我自己在做一个金融级远程证明方案时，就全部基于ESAPI——因为SAPI手动管理会话太容易出错了。
同样的创建密钥操作，用ESAPI写起来清爽很多：
// ESAPI方式创建RSA密钥（伪代码）
ESYS_TR parentHandle = ESYS_TR_RH_OWNER;
ESYS_TR keyHandle;
TPM2B_PUBLIC inPublic = { .size = 0, .publicArea = {
.type = TPM2_ALG_RSA,
.nameAlg = TPM2_ALG_SHA256,
.objectAttributes = (TPMA_OBJECT_SIGN_ENCRYPT |
TPMA_OBJECT_USERWITHAUTH |
TPMA_OBJECT_SENSITIVEDATAORIGIN),
.authPolicy = { .size = 0 },
.parameters.rsaDetail = { .symmetric = { .algorithm = TPM2_ALG_NULL },
.scheme = { .scheme = TPM2_ALG_RSASSA,
.details.rsassa.hashAlg = TPM2_ALG_SHA256 },
.keyBits = 2048,
.exponent = 0 },
.unique.rsa = { .size = 0 }
}};
TSS2_RC rc = Esys_Create(
esysContext,
parentHandle,
ESYS_TR_PASSWORD, // 自动处理授权
ESYS_TR_NONE,
ESYS_TR_NONE,
&inPublic,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
);
你发现没？ESAPI版本少了手动处理会话的步骤，参数也精简了。这就是“增强”的含义——不是功能增强，而是易用性和安全性增强。
3.5 FAPI：面向业务场景的“傻瓜式”接口
FAPI是TSS里最上层的接口。它不再暴露TPM命令的细节，而是提供“我要做什么”的语义。比如：
- 创建密钥：Fapi_CreateKey
- 密封数据：Fapi_Seal
- 远程证明：Fapi_Quote
- 密钥加载：Fapi_LoadKey
每个操作背后，FAPI自动帮你处理了密钥路径、授权策略、会话管理、甚至PCR选择。你只需要告诉它“我要用哪个密钥，做什么事”。
我的建议：如果你不是在做TPM底层库开发，或者你的项目周期紧，直接用FAPI。80%的远程证明场景，FAPI完全够用。只有当你需要定制化策略、或者性能调优时，才考虑下沉到ESAPI或SAPI。
FAPI还有一个很贴心的设计——它使用JSON格式的配置文件来管理密钥和策略。你可以把密钥的路径、算法、用途都写在JSON里，运行时加载就行。这大大降低了代码的耦合度。
// FAPI创建密钥示例（伪代码）
char *keyPath = "/HS/SRK/myAttestKey";
char *policyPath = ""; // 空字符串表示无策略
TSS2_RC rc = Fapi_CreateKey(
fapiContext,
keyPath, // 密钥路径
"", // 父密钥路径（空=SRK）
policyPath, // 策略路径
"sign, decrypt", // 密钥用途
TPM2_ALG_RSA, // 算法
2048, // 密钥长度
NULL // 回调
);
你看，一行调用就创建了一个可用于签名和解密的RSA密钥。这在SAPI里得写上百行代码。
3.6 如何选择：FAPI vs ESAPI vs SAPI
很多学员问我：“老师，我到底该用哪一层？”我的回答是——看你的场景和团队能力。
| 场景 | 推荐接口 | 理由 |
|---|---|---|
| 快速原型、PoC验证 | FAPI | 开发效率最高，代码量最少 |
| 标准远程证明方案 | FAPI + ESAPI | FAPI做主体逻辑，ESAPI处理特殊策略 |
| 定制化安全策略 | ESAPI | 需要精细控制会话和授权 |
| TPM固件/驱动开发 | SAPI + TCTI | 需要直接操作命令和传输层 |
| 性能极致优化 | SAPI + 自定义TCTI | 跳过所有中间层，直接发命令 |
避坑指南：我曾经在一个项目里，团队为了“灵活”全部用SAPI开发。结果光会话管理的bug就修了两周。后来我强制切换到FAPI + ESAPI组合，开发效率提升了3倍，而且安全性反而更高——因为ESAPI帮我们堵住了很多手动管理会话的漏洞。
3.7 TCTI的扩展：从本地到网络
最后聊一下TCTI的扩展能力。标准的TCTI只支持本地设备，但实际项目中，你可能会遇到需要远程访问TPM的场景——比如云服务器上的虚拟TPM，或者物联网网关上的集中式TPM。
这时候就需要自定义TCTI。我记得有一个项目，需要把TPM命令通过MQTT协议传到云端执行。我们就在TCTI层做了封装：本地应用调用FAPI，FAPI走ESAPI，ESAPI走SAPI，SAPI走自定义的MQTT TCTI，命令通过MQTT broker转发到云端的TPM模拟器上。
整个链路对上层应用完全透明。这就是分层设计的好处——你只需要替换最底层的TCTI，上面的代码一行都不用改。