嵌入式系统硬件安全实践：TPM开发套件I2C/SPI集成与TSS软件栈应用

1. 项目概述：为什么嵌入式系统需要一个“保险柜”

如果你正在开发一个联网的智能设备，无论是智能门锁、工业网关还是车载终端，一个绕不开的核心问题就是：如何保护设备里的关键数据，比如用户的指纹模板、设备的唯一身份凭证、或者与云端通信的加密密钥？把这些敏感信息直接以明文形式存放在主控芯片的Flash里，无异于把家门钥匙挂在门把手上。这时，一个专用的硬件安全芯片——TPM（可信平台模块）——就扮演了“硬件保险柜”的角色。

Atmel（现为Microchip Technology的一部分）推出的TPM I2C/SPI开发套件，就是为嵌入式开发者打开这扇“安全之门”的钥匙。它不是一个简单的评估板，而是一个完整的实践平台，让你能在一个真实的硬件环境中，快速上手如何通过最常用的两种串行总线（I2C和SPI），将TPM芯片集成到你的嵌入式系统中，并实现从密钥生成、安全存储到数字签名、身份认证等一系列安全功能。简单说，它解决了“从理论到实践”的最后一公里问题：协议怎么连？命令怎么发？常见的坑在哪里？

我接触过不少项目，团队在方案设计阶段都知道安全很重要，也选了TPM芯片，但真到动手写驱动、调协议的时候，往往卡在I2C的时序或者SPI的模式配置上，更别提后续复杂的TSS（TPM软件栈）集成。这个套件最大的价值，就是把硬件接口、基础驱动、标准软件栈和典型应用案例打包给你，让你能聚焦在安全业务逻辑本身，而不是在底层通信的泥潭里挣扎。接下来，我就结合自己踩过的坑，带你拆解这个套件的核心玩法。

2. 套件核心组件与硬件连接解析

拿到开发套件，第一步不是急着上电，而是搞清楚你手里有哪些“积木块”，以及它们之间如何正确拼接。这个套件通常包含几个核心部分：

2.1 核心硬件模块拆解

1. TPM评估板：这是核心，上面搭载了Atmel/Microchip的TPM芯片（如AT97SC3205）。板上会引出芯片的所有关键引脚，最重要的是I2C和SPI的接口引脚。你需要像对待一颗独立的芯片一样去连接它。
2. 主板或接口板：套件通常会提供一块主板，上面可能集成了USB转I2C/SPI的桥接芯片（如ATMEL的微控制器），方便你通过USB连接电脑进行快速评估和调试。有时主板也自带一个ARM Cortex-M系列的主控MCU，用于模拟真实嵌入式主机的场景。
3. 线缆与跳线帽：用于连接和配置。特别注意跳线帽，它们决定了TPM芯片是通过I2C还是SPI与主机通信，以及I2C的从机地址选择（通过AD0， AD1引脚的电平决定）。

2.2 I2C与SPI连接方案选择

这是第一个关键决策点。两种总线各有优劣，选择哪种取决于你的主系统资源、通信速率和布线复杂度。

• I2C连接方案：

  • 引脚：只需要两根线——SDA（数据线）和SCL（时钟线）。这两根线都需要通过上拉电阻（通常4.7kΩ）拉到电源电压（如3.3V）。套件板上通常已集成，但如果你是自己布线到自定义主板，务必记得加上。
  • 地址：TPM的I2C从机地址是7位的。具体地址由芯片的AD0和AD1引脚电平决定。例如，当AD0=AD1=GND时，地址可能是0x29。你必须在主机驱动初始化时配置正确的地址。
  • 优势：节省引脚，布线简单，支持多主多从（虽然TPM场景多为单主单从）。
  • 注意事项：I2C是开漏输出，总线电容会影响通信速度。TPM的I2C速率通常支持到400kHz（快速模式）或1MHz（高速模式），但实际速率需根据布线质量和上拉电阻调整。一个常见的坑是上拉电阻过大，导致上升沿太慢，在高速通信时容易出错。如果通信不稳定，可以尝试减小上拉电阻值（如改为2.2kΩ），但要注意不要超过IO口的最大拉电流。

• SPI连接方案：

  • 引脚：需要四根线——SCK（时钟）、MOSI（主机输出从机输入）、MISO（主机输入从机输出）、CS（片选）。有些TPM芯片还支持中断引脚（IRQ）。
  • 模式：SPI有四种时钟模式（CPOL和CPHA的组合）。TPM芯片通常支持模式0（CPOL=0， CPHA=0）或模式3（CPOL=1， CPHA=1）。这是最容易出错的地方之一，必须查阅具体TPM芯片的数据手册确认。主机MCU的SPI配置必须与之严格匹配。
  • 优势：全双工，通信速率高（可达10MHz以上），时序简单稳定，抗干扰能力通常优于I2C。
  • 注意事项：SPI是点对点通信，每个从机需要独立的CS线。通信时，必须确保在数据传输开始前拉低CS，结束后拉高CS。SPI的时钟极性（CPOL）和相位（CPHA）配置错误，会导致读写的所有数据都是错的。

实操心得：对于初次集成，我强烈建议先从SPI模式入手。虽然多用两根线，但SPI的时序和调试比I2C直观得多。用逻辑分析仪抓取波形时，SPI的四个信号一目了然，很容易判断是主机没发数据还是从机没响应。而I2C一旦通信失败，需要排查主机、从机、上拉、干扰等多个因素，对新手不太友好。

3. 底层驱动开发与TSS软件栈集成

硬件连好了，接下来就是让软件“动”起来。这个过程分为两层：底层总线驱动和上层TSS软件栈。

3.1 编写与调试底层通信驱动

这一层的目标是实现一个最基本的函数：TPM_Transmit。它接收一个命令缓冲区，通过I2C或SPI发送给TPM芯片，然后读取响应缓冲区。

• I2C驱动要点：

  1. 起始与停止：严格按照I2C协议，每次传输以START条件开始，以STOP条件结束。
  2. 地址与读写位：发送7位从机地址+1位读写位（0写，1读）。例如，向地址0x29写数据，主机实际发送的字节是0x52（0x29 << 1 | 0）。
  3. TPM协议封装：TPM命令不是直接裸发数据。它有一个简单的帧结构：通常是2字节的帧头（标识帧长度），后面跟着实际的TPM命令包。你的驱动需要先发送帧头，再发送命令数据。读取响应时也是先读2字节的长度头，再根据长度读取剩余数据。
  4. 调试技巧：使用逻辑分析仪或示波器抓取SDA和SCL波形。首先确认START、地址、ACK、STOP等基本信号是否正确。然后检查发送的数据字节是否与你代码中组装的缓冲区一致。一个常见错误是字节序（Endianness）问题，TPM协议通常使用大端序（Big-Endian），而你的MCU可能是小端序，在组装长度字段时需要转换。

• SPI驱动要点：

  1. 模式与速率：根据数据手册正确配置SPI的CPOL、CPHA和时钟分频。初始调试时，建议先用较低的时钟速率（如1MHz），稳定后再提升。
  2. 片选控制：确保在整次TPM命令传输（包括发送和接收响应）期间，CS引脚保持低电平。不能在发送帧头和命令体之间拉高CS。
  3. 全双工与哑元读取：SPI是全双工的，主机在发送MOSI数据的同时，也会从MISO收到数据。在发送命令阶段，你收到的数据可能是无效的（FF或00），需要丢弃。在接收响应阶段，你需要持续发送时钟（可以发送0xFF或0x00作为哑元时钟）来驱动从机输出数据。
  4. 调试技巧：SPI调试相对简单。用逻辑分析仪同时抓取SCK、MOSI、MISO、CS四路信号。检查CS的拉低时机是否覆盖了整个事务。对照SCK时钟沿，检查MOSI上发出的数据是否与命令缓冲区匹配，MISO上返回的数据是否合理。

3.2 集成TSS（TPM Software Stack）

自己从零实现所有TPM命令（如创建密钥、签名、PCR扩展）是极其繁琐且容易出错的。因此，必须使用TSS。对于嵌入式系统，最常用的是tpm2-tss项目（现在常被称为tss2）。它是一个开源、符合TCG标准的软件栈。

集成步骤：

1. 移植或交叉编译：将tpm2-tss库移植到你的目标平台（如ARM Cortex-M）。这通常意味着为它编写一个底层的“传输抽象层”（TCTI）。幸运的是，tpm2-tss已经提供了许多后端，包括针对Linux SPI/I2C设备的后端。对于裸机或无操作系统的环境，你需要实现一个最简的TCTI层，其核心就是调用你上面写好的TPM_Transmit函数。
2. 配置与初始化：在应用程序中，初始化TSS上下文，并指定使用你实现的TCTI。之后，你就可以使用TSS提供的高级API了，例如Tss2_Sys_CreatePrimary来创建一个主密钥。
3. 资源管理：TPM内部资源（如密钥句柄、会话句柄）需要妥善管理。使用完务必通过API关闭或清空，防止资源泄漏。

踩坑实录：我曾在一个FreeRTOS项目里集成TSS，遇到了SPI通信偶尔出现乱码（FF）的问题。排查了很久，最终发现是任务调度和SPI DMA的冲突。高优先级任务打断了正在进行的SPI DMA传输，导致数据错乱。解决方案是，在调用TPM_Transmit函数进行关键通信期间，临时提升任务优先级或关闭中断，确保通信事务的原子性。这不是TPM或SPI协议的问题，而是嵌入式实时系统中常见的资源共享问题。

4. 核心安全功能实践与代码示例

驱动和软件栈都通了，我们就可以玩转TPM的核心功能了。下面通过几个关键场景，展示如何用代码实现。

4.1 场景一：安全密钥生成与存储

这是TPM最基础的功能。密钥在TPM内部生成，私钥永远不出TPM，只有公钥可以导出。

// 伪代码，基于 tpm2-tss API 风格 #include <tss2/tss2_sys.h> TSS2_RC create_and_load_rsa_key(TSS2_SYS_CONTEXT *sysContext, TPM2_HANDLE *keyHandle) { TPM2B_PUBLIC inPublic = {0}; TPM2B_SENSITIVE_CREATE inSensitive = {0}; TPM2B_DATA outsideInfo = {0}; TPML_PCR_SELECTION creationPCR = {0}; TPM2B_PUBLIC outPublic = {0}; TPM2B_CREATION_DATA creationData = {0}; TPM2B_DIGEST creationHash = {0}; TPMT_TK_CREATION creationTicket = {0}; TPM2B_PRIVATE outPrivate = {0}; // 1. 定义密钥模板：一个2048位的RSA签名密钥 inPublic.publicArea.type = TPM2_ALG_RSA; inPublic.publicArea.nameAlg = TPM2_ALG_SHA256; inPublic.publicArea.objectAttributes = TPMA_OBJECT_SIGN_ENCRYPT | TPMA_OBJECT_USERWITHAUTH | TPMA_OBJECT_SENSITIVEDATAORIGIN; inPublic.publicArea.authPolicy.size = 0; inPublic.publicArea.parameters.rsaDetail.keyBits = 2048; inPublic.publicArea.parameters.rsaDetail.exponent = 65537; inPublic.publicArea.unique.rsa.size = 256; // 2048/8 // 2. 敏感数据部分（这里为空，因为密钥由TPM内部生成） inSensitive.sensitive.data.size = 0; // 3. 调用创建命令 TSS2_RC rc = Tss2_Sys_CreatePrimary(sysContext, TPM2_RH_OWNER, // 在所有者层级下创建 &inSensitive, &inPublic, &outsideInfo, &creationPCR, keyHandle, // 输出：密钥句柄 &outPublic, &creationData, &creationHash, &creationTicket); if (rc != TPM2_RC_SUCCESS) { printf("CreatePrimary failed with error: 0x%x\n", rc); } return rc; }

这段代码创建了一个RSA主密钥。TPMA_OBJECT_SENSITIVEDATAORIGIN属性表明私钥由TPM内部生成，绝不会暴露。keyHandle是后续使用此密钥（如签名）的凭证。

4.2 场景二：基于PCR的平台完整性度量与认证

PCR（平台配置寄存器）是TPM用于存储完整性度量结果的寄存器。系统启动时，BIOS/U-Boot/OS会层层测量关键组件（如固件、引导程序、内核）的哈希值，并“扩展”到特定的PCR中。

// 伪代码：扩展一个度量值到PCR，并使用绑定到PCR的密钥进行签名 TSS2_RC extend_pcr_and_sign(TSS2_SYS_CONTEXT *sysContext, TPM2_HANDLE keyHandle) { TPM2B_DIGEST digestToExtend = {0}; TPML_DIGEST_VALUES digests = {0}; TPM2B_DATA qualifyingData = {0}; TPML_PCR_SELECTION pcrSelect; TPMT_SIG_SCHEME inScheme = {0}; TPM2B_ATTEST attest = {0}; TPMT_SIGNATURE signature = {0}; // 1. 模拟度量到一个文件或数据的哈希值 uint8_t measuredData[] = {...}; SHA256(measuredData, sizeof(measuredData), digestToExtend.buffer); digestToExtend.size = SHA256_DIGEST_SIZE; // 2. 扩展哈希值到PCR[8]（常用于OS引导度量） digests.count = 1; digests.digests[0].hashAlg = TPM2_ALG_SHA256; memcpy(digests.digests[0].digest.sha256, digestToExtend.buffer, SHA256_DIGEST_SIZE); Tss2_Sys_PCR_Extend(sysContext, 8, &digests, NULL); // 3. 创建一个PCR策略会话，要求PCR[8]为特定值时才允许使用密钥 // ... (此处省略策略会话创建的复杂代码) // 4. 使用密钥进行签名（如果PCR值不符，此步骤会失败） inScheme.scheme = TPM2_ALG_RSASSA; inScheme.details.rsassa.hashAlg = TPM2_ALG_SHA256; Tss2_Sys_Sign(sysContext, keyHandle, NULL, &digestToExtend, &inScheme, &attest, &signature, NULL); // 签名成功，证明当前平台状态（PCR值）符合预期 return TPM2_RC_SUCCESS; }

这个场景实现了“远程证明”的基石。服务端可以要求设备提供一段数据的签名，以及签名时PCR的值。服务端验证签名有效，且PCR值符合预期的“黄金配置”，从而确信设备运行在未被篡改的软件状态下。

4.3 场景三：加密存储与密封

TPM可以加密一小段数据（如一个对称密钥），并且将解密的权限与特定的PCR状态绑定，这称为“密封”。

// 伪代码：密封一个秘密到TPM TSS2_RC seal_secret_to_pcr(TSS2_SYS_CONTEXT *sysContext) { TPM2B_SENSITIVE_DATA secret = {0}; TPM2B_PUBLIC inPublic = {0}; TPM2B_SENSITIVE_CREATE inSensitive = {0}; // ... 初始化inPublic和inSensitive，指定密钥属性为“解密”和“固定父级” // 关键：在inPublic的authPolicy中，设置一个PCR策略，比如要求PCR[0,1,2,3]为特定值。 TPM2B_PRIVATE outPrivate = {0}; TPM2B_PUBLIC outPublic = {0}; // 准备要密封的秘密（例如一个AES-128密钥） uint8_t aes_key[16] = {...}; memcpy(secret.buffer, aes_key, 16); secret.size = 16; inSensitive.sensitive.data = secret; // 创建密封对象 Tss2_Sys_Create(sysContext, TPM2_RH_NULL, &inSensitive, &inPublic, ... , &outPrivate, &outPublic, ...); // outPrivate和outPublic就是“密封”后的对象，可以存储到非易失性存储器中。 // 只有当TPM的PCR处于指定状态时，才能成功加载（Load）并解密（Unseal）这个对象，恢复出原始的aes_key。 }

这个功能非常强大。例如，设备的全盘加密密钥可以被密封到TPM，只有当系统以合法方式启动（PCR值正确）时，TPM才会释放出这个密钥来解密磁盘。如果引导链被恶意修改，PCR值改变，密钥将永远无法被获取，数据也就得到了保护。

5. 调试技巧与常见问题排查指南

即使按照指南操作，在实际开发中你也一定会遇到各种问题。下面这个表格整理了我遇到的一些典型问题及排查思路，希望能帮你节省时间。

高级调试工具推荐：

• 逻辑分析仪：必备神器。Saleae Logic系列或国产的DSView搭配FX2LP套件都是性价比之选。用它抓取总线波形，是排查硬件通信问题的唯一可靠手段。
• tpm2-tools：在Linux主机上安装这套命令行工具。即使你的目标板是嵌入式系统，也可以先在x86 Linux上用tpm2-abrmd（资源管理器）和模拟TPM（如swtpm）或一块USB TPM开发板来熟悉命令和流程，验证你的思路是否正确。
• Wireshark：如果你使用tpm2-abrmd，它可以配置为将TCTI通信日志输出到pcap文件，然后用Wireshark查看，可以清晰看到每个TPM命令和响应的结构，对于理解协议层问题非常有帮助。

6. 从评估到量产：工程化考量

当你在开发套件上验证了所有功能后，要将其移植到真正的产品设计中，还需要考虑以下几个工程化问题：

6.1 硬件设计注意事项

• PCB布局：对于SPI高速通信（>10MHz），需要将TPM芯片尽量靠近主MCU，走线等长，避免过孔，并在时钟线两侧包地以减少干扰。对于I2C，虽然速率低，但也要注意走线远离噪声源（如开关电源、电机驱动）。
• 电源与去耦：TPM作为安全芯片，对电源质量敏感。必须在芯片的VCC引脚附近放置一个0.1uF的陶瓷去耦电容，并确保电源网络的稳定性。如果系统中有多个电源域，要确保TPM和主MCU的IO电平兼容。
• 复位电路：确保TPM的复位引脚有明确的上电复位和手动复位电路。在产品需要强制TPM回到已知状态时，一个硬件复位信号比软件命令更可靠。

6.2 软件架构与安全策略

• 分层设计：将TPM访问模块化。最底层是硬件抽象层（HAL），负责I2C/SPI读写。之上是TCTI适配层。再往上才是业务逻辑层（调用TSS API）。这样便于移植和测试。
• 密钥管理策略：提前规划好产品中需要哪些类型的密钥（背书密钥EK、存储密钥、签名密钥等），它们的层级关系如何，哪些是持久的，哪些是临时的。制定清晰的密钥生命周期管理策略。
• PCR使用规划：定义好你的“度量信任链”。PCR0-7通常由固件使用，PCR8-15留给操作系统。明确每个PCR扩展什么内容，并确保度量的代码本身是可信的。
• 错误处理与恢复：TPM操作可能因各种原因失败（电量不足、通信干扰、命令序列错误）。软件必须有健壮的错误处理机制，比如重试逻辑、状态回滚、以及明确的故障指示（如LED闪烁、日志记录）。

6.3 测试与认证

• 一致性测试：TCG提供了TPM2.0的一致性测试套件。在产品定型前，尽可能运行这些测试，以确保你的TPM集成符合规范。
• 侧信道攻击考量：对于高安全等级产品，需要考虑物理安全。虽然TPM芯片本身有防侧信道攻击的设计，但主MCU与TPM之间的通信线路可能成为攻击点。必要时，可以考虑对通信线路进行物理屏蔽，或使用带有加密总线的安全MCU。

从一块评估板到一个可靠的产品功能，中间隔着无数细节。这个Atmel TPM开发套件提供的是一条清晰的起跑线，它让你能快速验证想法的可行性。而真正的挑战，在于如何将这条起跑线上的原型，稳健地、安全地融入到你的整个产品体系中去。这个过程没有捷径，就是不断地测试、调试、优化，但每一次问题的解决，都让你对“嵌入式安全”这四个字有更深的理解。