简介这份PDF聚焦RISC-V安全扩展与可信执行环境以OpenTitan开源安全核为信任根结合STM32MP1双核SoC阐述TEE搭建方法。内容面向嵌入式安全开发、物联网设备固件设计及可信启动研究人员从RISC-V安全扩展、OpenTitan架构入手逐步拆解硬件连接、固件移植、AES/RSA加密实现、SPI通信与安全机制配置并给出性能测试结果与工业物联网、智能家居、医疗设备等应用分析。资源共30页为单个PDF文档压缩包体积1.94MB支持目录跳转与大纲定位文字图表完整清晰。文档附有硬件初始化、加密算法、通信接口等代码示例便于读者对照实践。浏览/学习人数57适合具备一定嵌入式基础、希望了解可信执行环境工程化落地的读者作为参考资料。1. 可信执行环境不一定非要做在主控芯片内部把可信执行环境做进主控芯片内部是 TrustZone 这类方案的基本思路但它有一个天然约束信任根和主应用放在同一颗硅片上一旦 SoC 的物理防护或固件漏洞被突破整个隔离边界会一起垮掉。更稳妥的路线是把信任根独立出来用一颗专门的 RISC-V 安全芯片承担密钥管理、固件度量和安全启动主控只负责业务逻辑。OpenTitan 是目前少数开源到硅级的安全芯片设计而 STM32MP1 的双核架构又正好提供了清晰的隔离边界。把这两者组合起来可以在工业物联网、边缘网关这类对安全等级有硬性要求的嵌入式场景里搭出一个既透明又可审计的可信执行环境。这套方案的工程量不小但每一步的坑基本都是已知的值得拆开讲清楚。2. RISC-V 安全扩展与 OpenTitan 信任根设计2.1 分级特权与 PMP可信执行环境的两个地基RISC-V 没有像 ARM TrustZone 那样把安全状态直接做成架构特性而是靠分级特权模式和物理内存保护PMP两个机制组合出隔离能力。特权模式分 M、S、U 三级机器模式管硬件初始化和安全监控监督模式跑操作系统内核用户模式跑应用程序。可信执行环境的做法通常是把安全监控器放在 M 模式普通操作系统放 S 模式应用放 U 模式通过模式切换时的异常入口来隔离敏感操作。PMP 是 RISC-V 里更关键的那一层。它允许在硬件层面给物理内存区域配置读、写、执行权限而且这种配置不依赖操作系统的配合即使 S 模式下的内核被攻破也无法越过 PMP 的物理限制。OpenTitan 的 Ibex 处理器实现了 PMP 规范下面这段代码展示了如何在 M 模式下把一个外部 Flash 区域配置为可读可写可执行并加锁。#define PMP_CFG_R (0x1 0) #define PMP_CFG_W (0x1 1) #define PMP_CFG_X (0x1 2) #define PMP_CFG_TOR (0x1 3) #define PMP_CFG_L (0x1 5) void pmp_protect_region(uint32_t start, uint32_t end) { uint32_t pmpaddr (end 2); // pmpaddr 存的是物理地址右移两位 uint32_t pmpcfg PMP_CFG_TOR | PMP_CFG_R | PMP_CFG_W | PMP_CFG_X | PMP_CFG_L; asm volatile(csrw pmpaddr0, %0 :: r(pmpaddr)); asm volatile(csrw pmpcfg0, %0 :: r(pmpcfg)); }这里有几个必须注意的参数细节。TOR 模式下 pmpaddr 寄存器保存的是区域结束地址区域起始地址由前一个 PMP 条目决定所以第一个条目的起始地址默认为 0x0。地址右移两位是因为 pmpaddr 的粒度是 4 字节。加了 L 锁定位之后这条 PMP 配置在当前特权模式下无法再被修改直到系统复位这防止了运行中被篡改的可能。实际配置时还要注意区间对齐PMP 的 NAPOT 模式对对齐要求更严格TOR 相对宽松但起始和结束地址必须落在 4 字节边界上。2.2 OpenTitan 的硬件信任根构成OpenTitan 不是一颗现成芯片而是一个开源的硅信任根设计目标是把安全芯片的设计完全开放出来。它的核心模块大致可以分为四类模块功能在 TEE 中的角色Ibex 处理器32 位 RISC-V 核支持 M 模式和 PMP执行安全固件管理安全状态OTBN大数运算加速器加速 RSA/ECDSA 签名验证OTP一次性可编程存储存放根密钥、生命周期状态、设备唯一 IDKMAC / AES / SHA密钥派生与对称哈希加速数据加密、启动度量、会话密钥生成这套组合里最有价值的是生命周期控制器。芯片从出厂到量产到部署要经过 RAW、TEST、DEV、PROD、RMA 等状态每个状态之间的跳转都有严格限制。比如从 PROD 状态退回 DEV 状态需要物理访问和特定授权这能防止攻击者把芯片调回开发模式重新读取密钥。在可信执行环境设计里生命周期状态直接决定了信任根的可信程度状态机一旦被绕过其他安全机制都失去意义。2.3 OpenTitan 安全启动链路OpenTitan 的启动过程是分阶段验证的片上 ROM 先执行ROM 验证 ROM_EXT 的签名ROM_EXT 再验证后续的 Boot Services 镜像。每一级只信任上一级给出的测量结果形成一条完整的信任链。ROM 本身在流片时固化无法修改所以是整个信任链的锚点。这给嵌入式开发带来的直接变化是主控芯片的固件不再由自己验证自己而是把验签动作交给独立的 RISC-V 安全核完成。STM32MP1 的 FSBL 镜像签名公钥存放在 OpenTitan 的 OTP 里每次启动时 OpenTitan 先检查外部 Flash 里的 FSBL 镜像哈希和签名验证通过才允许 A7 核执行。即使主控上的 Linux 被完全拿下攻击者也拿不到根密钥因为密钥只存在于 OpenTitan 内部主控侧的软件永远接触不到。3. STM32MP1 异构多核的安全边界与 SPI 通信设计3.1 A7 与 M4 的职责切分STM32MP1 的异构双核架构在可信执行环境下需要明确分工。Cortex-A7 具备 MMU 和虚拟内存能力适合运行 Linux 和 OP-TEE负责业务逻辑和运行时敏感计算Cortex-M4 是实时核负责与传感器、执行器直接交互不跑完整操作系统降低攻击面。OpenTitan 在这套体系里既不是主 CPU 也不是实时控制器而是安全协处理器只在需要密钥操作、启动度量、固件认证时被调用。这里容易犯的错误是把所有安全操作都塞给 OpenTitan。它的 Ibex 核性能有限跑 RSA-2048 验签虽然有 OTBN 加速但频繁的对称加解密如果全走 SPI 通道吞吐率会非常难看。合理的做法是OpenTitan 只做低频但高价值的操作密钥派生、签名验证、启动度量运行时的大量对称加密由 STM32MP1 侧处理密钥材料通过安全会话从 OpenTitan 获取。3.2 SPI 接线与硬件资源分配STM32MP1 与 OpenTitan 之间最常见的通信方式是 SPI四根线加一根中断线就能跑起来。硬件连接时有一个容易被忽略的细节OpenTitan 的 SPI 从机接口通常支持的最高时钟频率在 10MHz 到 20MHz 之间而 STM32MP1 的 SPI 主机可以跑到更高频率。直接配置最高速率会导致通信不稳定常见做法是先跑 1MHz 确认信号完整性再逐步提升。硬件资源分配上要专门给 OpenTitan 留一路中断输入用于异步通知 A7安全操作完成。这个中断要接到 STM32MP1 的 EXTI 控制器上并且在 Linux 设备树中配置为专用的中断号。如果和普通 GPIO 中断混用高负载下会丢失安全事件排查起来非常痛苦。3.3 通信协议设计SPI 通信不能只发裸数据需要定义一套简单的请求应答协议。我一般会定义一个固定长度的命令头结构如下typedef struct { uint8_t magic; // 固定 0x5A用于帧同步 uint8_t cmd; // 命令码0x01 获取状态0x02 密钥派生0x03 签名验证 uint16_t length; // 数据域长度大端序 uint32_t crc32; // 整个帧的校验值 } ot_cmd_header_t;每个命令的应答也遵循同一套帧结构A7 发送命令后进入等待状态OpenTitan 处理完成后通过中断通知 A7 读取应答。为什么要加 crc32因为 SPI 在高速率下偶发位翻转的概率不低而安全芯片通信如果出现静默错误后果比性能下降严重得多。帧同步靠 magic 字段完成接收方发现 magic 不对就丢弃并重新同步。3.4 主控侧 SPIDEV 通信代码在 Linux 侧通过内核的 spidev 驱动发送命令是最直接的方式。int fd open(/dev/spidev0.0, O_RDWR); if (fd 0) { perror(open spidev); return -1; } uint8_t mode SPI_MODE_0; uint32_t speed 1000000; // 1MHz先跑稳再提速 ioctl(fd, SPI_IOC_WR_MODE, mode); ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, speed); uint8_t tx[8] {0x5A, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; uint8_t rx[8] {0}; struct spi_ioc_transfer tr { .tx_buf (unsigned long)tx, .rx_buf (unsigned long)rx, .len sizeof(tx), .speed_hz speed, .delay_usecs 0, .bits_per_word 8, }; ioctl(fd, SPI_IOC_MESSAGE(1), tr);这段代码里值得说明的是 spi_ioc_transfer 结构体的参数speed_hz 可以单独指定本次传输的速率不必和设备树里的 max-speed-hz 完全一致delay_usecs 表示两次传输之间的延时在 OpenTitan 处理应答前给一个小的延时可以减少忙等的时间bits_per_word 不设的话默认是 8 位。实际操作中SPI_MODE_0 和 SPI_MODE_3 都可能遇到取决于 OpenTitan 固件的 SPI 从机配置一定要两端对齐。对于超过 64 字节的数据传输ioctl 方式一次只能传递有限大小的缓冲区性能和吞吐率都不理想更工程化的做法是配合 DMA 传输。但这依赖设备树里 SPI 节点的 dma 属性配置不是简单改代码能解决的需要单独验证。4. 基于 OpenTitan 的 STM32MP1 可信执行环境构建4.1 构建流程与工具链准备构建这套环境的工具链分为两条线OpenTitan 侧和 STM32MP1 侧。OpenTitan 的固件用 RISC-V 交叉编译工具链编译在 Ubuntu 上直接安装 gcc-arm-none-eabi 即可因为 OpenTitan 当前的发布版本面向裸机环境不需要操作系统支持。STM32MP1 侧的 Linux 内核和 FSBL 编译则使用 ARM 官方的交叉编译器版本选择要与官方 SDK 保持一致。sudo apt install gcc-arm-none-eabi git clone https://github.com/lowRISC/opentitan.git cd opentitan pip3 install --user -r python-requirements.txtOpenTitan 的构建系统基于 meson 和 ninja编译固件的命令是ninja -C build-out sw/device/lib。在生成 OpenTitan 的 OTP 初始化镜像和 ROM_EXT 时要注意配置文件里的--lc-state参数开发阶段用DEV状态量产切换到PROD状态两个状态下可访问的调试接口完全不同。初次搭建时最容易踩的坑是 OTP 配置与芯片生命周期状态不匹配导致芯片反复进入 RMA 流程。4.2 安全启动链的落地OpenTitan 集成到 STM32MP1 启动链后的分区结构大致如下镜像存放位置验证方式加载者OpenTitan ROM内部只读存储器硬件固定不可修改硬件上电自动执行ROM_EXT外部 SPI FlashOpenTitan ROM 验签OpenTitan ROMBoot Services外部 SPI FlashROM_EXT 验签ROM_EXTSTM32MP1 FSBL外部 SPI FlashBoot Services 验签OpenTitanLinux Kernel外部存储介质FSBL/OP-TEE 验签FSBL这个启动链设计里最关键的变化是FSBL 不是由 STM32MP1 自身验证而是由 OpenTitan 验证。STM32MP1 上电后处于复位状态OpenTitan 完成镜像检查后才会释放复位信号允许 A7 核从指定地址启动。这样做的好处是即使 A7 侧的 BootROM 存在漏洞也影响不到信任根。整条链路的验签时间开销是必须评估的。RSA-2048 验签在 OpenTitan 的 OTBN 加速下大约在几十毫秒量级加上镜像读取和哈希计算整个启动时间会比原生启动增加几百毫秒。如果产品对开机时间敏感可以在 OpenTitan 侧做一次启动缓存把上次验签通过的镜像哈希记录在 OTP 或 SRAM 中后续启动做快速校验。4.3 固件移植与通信接口开发将 OpenTitan 固件移植到 STM32MP1 平台的实质是让 OpenTitan 通过 SPI 与主控通信同时让主控侧的内核驱动能够识别并访问 OpenTitan 的安全服务。这需要在 Linux 内核中新增一个简单的平台驱动static int ot_probe(struct platform_device *pdev) { struct ot_dev *ot; ot devm_kzalloc(pdev-dev, sizeof(*ot), GFP_KERNEL); ot-spi devm_spi_register(pdev, SPI_MODE_0, 20000000); ot-irq platform_get_irq(pdev, 0); devm_request_irq(pdev-dev, ot-irq, ot_isr, 0, ot, ot); ot_create_sysfs_attrs(ot); return 0; }设备树里需要给这个驱动声明 SPI 片选编号、中断号和 DMA 通道。DMA 通道不是必须的但如果后续要做大块数据加密没有 DMA 会导致 CPU 占用率过高。通信接口开发时建议先做一个只读版本的命令比如获取芯片状态打通整个收发路径后再扩展密钥相关的命令这样可以快速区分是 SPI 硬件问题还是固件逻辑问题。4.4 加密机制与访问控制的具体配置AES-CBC 加解密的工程实现密钥管理是可信执行环境的核心。AES 密钥由 OpenTitan 的 KMAC 模块基于主密钥派生主密钥存放在 OTP 中运行时不落盘。主机需要加密数据时发送派生请求OpenTitan 返回派生后的会话密钥给主控会话密钥只存在于内存中。aes_ctx_t ctx; aes_params_t params { .mode AES_MODE_CBC, .key_len AES_KEY_128, }; aes_init(ctx, params, session_key, iv); aes_crypt(ctx, plaintext, ciphertext, data_len);这段代码里的 aes_init 会把密钥加载到 OpenTitan 的 AES 硬件模块寄存器中而不是软件里做轮运算。data_len 必须是 16 字节的整数倍不足部分要手动做 PKCS7 填充。AES-CBC 模式的 IV 每次加密应该随机生成不能固定否则相同的明文会得到相同的密文泄露数据模式。访问控制的实现OpenTitan 侧的 PMP 保护 Flash 固件区域STM32MP1 侧使用 ETZPCExtended TrustZone Protection Controller隔离外设两者配合形成两层访问控制。PMP 偏重物理内存的读写保护ETZPC 偏重总线级别的外设访问隔离。例如可以把 GPIO 控制器的寄存器空间配置为仅 Cortex-M4 可访问A7 侧 Linux 即使被攻破也无法直接操作关键控制引脚。4.5 测试与验证功能测试可以从三个方面设计正常路径测试构建签名镜像确认启动成功、篡改路径测试修改 FSBL 任意一个字节确认启动失败、回滚测试用旧版本镜像覆盖新版确认 OpenTitan 拒绝加载。其中回滚测试容易被忽略但恰恰是最常出问题的环节。OpenTitan 的 Boot Services 需要记录每个镜像的版本号版本号低于当前值时直接拒绝加载。注意版本号的存储位置要在 OTP 或专门的反回滚计数器中如果存在普通 Flash攻击者可以整体擦除再写入旧镜像让版本号检查形同虚设。5. 性能评估思路与值得留意的优化细节可信执行环境的性能评估不能只看 CPU 跑分要从四个维度设计指标计算性能关注 RSA 签名验证和 AES 加解密的吞吐率存储性能关注 OTP 读写和 Flash 读取延迟通信性能关注 SPI 单次命令往返时延和批量传输吞吐率安全性能关注启动链各阶段的验签耗时。OpenTitan 侧的性能测试需要写专门的固件在调用 OTBN 验签前后读取时间戳计数器记录单次 RSA-2048 验签的周期数。SPI 通信性能可以在 Linux 主控侧用 spidev_test 工具测试sudo ./spidev_test -D /dev/spidev0.0 -s 10000000 -H -b 8 -p 5A01000000000000 -v这里的 -s 参数指定 10MHz 时钟频率-H 表示 SPI 模式 3-b 8 表示 8 位字长-v 输出详细的收发对比。如果收到数据与发送数据不一致先降低频率到 1MHz 验证排除信号质量问题后再逐级提升。如果 1MHz 下都不一致重点检查 MISO 和 MOSI 是否接反以及片选信号极性是否配置正确。实测中节省性能最明显的优化是把 SPI 传输做成 DMA 模式。当数据量超过 64 字节时CPU 轮询方式的吞吐率会下降一半以上DMA 可以完全释放 A7 的算力去处理业务逻辑。DMA 模式需要保证 SPI 控制器的 DMA 请求信号与 OpenTitan 的中断信号配合好否则 DMA 传输完成通知丢失主控会一直等待。另一个值得做的优化是密钥缓存。如果业务场景中大量数据需要同一个密钥加解密不要每次都向 OpenTitan 请求派生而是在内存中保留一个经认证的会话密钥并定期轮换。这样可以显著降低 SPI 通信频率但轮换周期不能太长一般由产品安全策略决定。密钥缓存的释放时机也要注意当 OpenTitan 生命周期状态发生变化或检测到物理攻击时必须立即清空缓存。最后建议在量产阶段把 OpenTitan OTP 的调试接口完全锁死同时利用 STM32MP1 侧的硬件看门狗监控 A7 和 OpenTitan 之间的心跳任何一方超过设定时间无响应即触发系统复位。这样既保护了根密钥也保证了可信执行环境长期运行的稳定性。本文还有配套的精品资源点击获取
简介这份PDF聚焦RISC-V安全扩展与可信执行环境以OpenTitan开源安全核为信任根结合STM32MP1双核SoC阐述TEE搭建方法。内容面向嵌入式安全开发、物联网设备固件设计及可信启动研究人员从RISC-V安全扩展、OpenTitan架构入手逐步拆解硬件连接、固件移植、AES/RSA加密实现、SPI通信与安全机制配置并给出性能测试结果与工业物联网、智能家居、医疗设备等应用分析。资源共30页为单个PDF文档压缩包体积1.94MB支持目录跳转与大纲定位文字图表完整清晰。文档附有硬件初始化、加密算法、通信接口等代码示例便于读者对照实践。浏览/学习人数57适合具备一定嵌入式基础、希望了解可信执行环境工程化落地的读者作为参考资料。1. 可信执行环境不一定非要做在主控芯片内部把可信执行环境做进主控芯片内部是 TrustZone 这类方案的基本思路但它有一个天然约束信任根和主应用放在同一颗硅片上一旦 SoC 的物理防护或固件漏洞被突破整个隔离边界会一起垮掉。更稳妥的路线是把信任根独立出来用一颗专门的 RISC-V 安全芯片承担密钥管理、固件度量和安全启动主控只负责业务逻辑。OpenTitan 是目前少数开源到硅级的安全芯片设计而 STM32MP1 的双核架构又正好提供了清晰的隔离边界。把这两者组合起来可以在工业物联网、边缘网关这类对安全等级有硬性要求的嵌入式场景里搭出一个既透明又可审计的可信执行环境。这套方案的工程量不小但每一步的坑基本都是已知的值得拆开讲清楚。2. RISC-V 安全扩展与 OpenTitan 信任根设计2.1 分级特权与 PMP可信执行环境的两个地基RISC-V 没有像 ARM TrustZone 那样把安全状态直接做成架构特性而是靠分级特权模式和物理内存保护PMP两个机制组合出隔离能力。特权模式分 M、S、U 三级机器模式管硬件初始化和安全监控监督模式跑操作系统内核用户模式跑应用程序。可信执行环境的做法通常是把安全监控器放在 M 模式普通操作系统放 S 模式应用放 U 模式通过模式切换时的异常入口来隔离敏感操作。PMP 是 RISC-V 里更关键的那一层。它允许在硬件层面给物理内存区域配置读、写、执行权限而且这种配置不依赖操作系统的配合即使 S 模式下的内核被攻破也无法越过 PMP 的物理限制。OpenTitan 的 Ibex 处理器实现了 PMP 规范下面这段代码展示了如何在 M 模式下把一个外部 Flash 区域配置为可读可写可执行并加锁。#define PMP_CFG_R (0x1 0) #define PMP_CFG_W (0x1 1) #define PMP_CFG_X (0x1 2) #define PMP_CFG_TOR (0x1 3) #define PMP_CFG_L (0x1 5) void pmp_protect_region(uint32_t start, uint32_t end) { uint32_t pmpaddr (end 2); // pmpaddr 存的是物理地址右移两位 uint32_t pmpcfg PMP_CFG_TOR | PMP_CFG_R | PMP_CFG_W | PMP_CFG_X | PMP_CFG_L; asm volatile(csrw pmpaddr0, %0 :: r(pmpaddr)); asm volatile(csrw pmpcfg0, %0 :: r(pmpcfg)); }这里有几个必须注意的参数细节。TOR 模式下 pmpaddr 寄存器保存的是区域结束地址区域起始地址由前一个 PMP 条目决定所以第一个条目的起始地址默认为 0x0。地址右移两位是因为 pmpaddr 的粒度是 4 字节。加了 L 锁定位之后这条 PMP 配置在当前特权模式下无法再被修改直到系统复位这防止了运行中被篡改的可能。实际配置时还要注意区间对齐PMP 的 NAPOT 模式对对齐要求更严格TOR 相对宽松但起始和结束地址必须落在 4 字节边界上。2.2 OpenTitan 的硬件信任根构成OpenTitan 不是一颗现成芯片而是一个开源的硅信任根设计目标是把安全芯片的设计完全开放出来。它的核心模块大致可以分为四类模块功能在 TEE 中的角色Ibex 处理器32 位 RISC-V 核支持 M 模式和 PMP执行安全固件管理安全状态OTBN大数运算加速器加速 RSA/ECDSA 签名验证OTP一次性可编程存储存放根密钥、生命周期状态、设备唯一 IDKMAC / AES / SHA密钥派生与对称哈希加速数据加密、启动度量、会话密钥生成这套组合里最有价值的是生命周期控制器。芯片从出厂到量产到部署要经过 RAW、TEST、DEV、PROD、RMA 等状态每个状态之间的跳转都有严格限制。比如从 PROD 状态退回 DEV 状态需要物理访问和特定授权这能防止攻击者把芯片调回开发模式重新读取密钥。在可信执行环境设计里生命周期状态直接决定了信任根的可信程度状态机一旦被绕过其他安全机制都失去意义。2.3 OpenTitan 安全启动链路OpenTitan 的启动过程是分阶段验证的片上 ROM 先执行ROM 验证 ROM_EXT 的签名ROM_EXT 再验证后续的 Boot Services 镜像。每一级只信任上一级给出的测量结果形成一条完整的信任链。ROM 本身在流片时固化无法修改所以是整个信任链的锚点。这给嵌入式开发带来的直接变化是主控芯片的固件不再由自己验证自己而是把验签动作交给独立的 RISC-V 安全核完成。STM32MP1 的 FSBL 镜像签名公钥存放在 OpenTitan 的 OTP 里每次启动时 OpenTitan 先检查外部 Flash 里的 FSBL 镜像哈希和签名验证通过才允许 A7 核执行。即使主控上的 Linux 被完全拿下攻击者也拿不到根密钥因为密钥只存在于 OpenTitan 内部主控侧的软件永远接触不到。3. STM32MP1 异构多核的安全边界与 SPI 通信设计3.1 A7 与 M4 的职责切分STM32MP1 的异构双核架构在可信执行环境下需要明确分工。Cortex-A7 具备 MMU 和虚拟内存能力适合运行 Linux 和 OP-TEE负责业务逻辑和运行时敏感计算Cortex-M4 是实时核负责与传感器、执行器直接交互不跑完整操作系统降低攻击面。OpenTitan 在这套体系里既不是主 CPU 也不是实时控制器而是安全协处理器只在需要密钥操作、启动度量、固件认证时被调用。这里容易犯的错误是把所有安全操作都塞给 OpenTitan。它的 Ibex 核性能有限跑 RSA-2048 验签虽然有 OTBN 加速但频繁的对称加解密如果全走 SPI 通道吞吐率会非常难看。合理的做法是OpenTitan 只做低频但高价值的操作密钥派生、签名验证、启动度量运行时的大量对称加密由 STM32MP1 侧处理密钥材料通过安全会话从 OpenTitan 获取。3.2 SPI 接线与硬件资源分配STM32MP1 与 OpenTitan 之间最常见的通信方式是 SPI四根线加一根中断线就能跑起来。硬件连接时有一个容易被忽略的细节OpenTitan 的 SPI 从机接口通常支持的最高时钟频率在 10MHz 到 20MHz 之间而 STM32MP1 的 SPI 主机可以跑到更高频率。直接配置最高速率会导致通信不稳定常见做法是先跑 1MHz 确认信号完整性再逐步提升。硬件资源分配上要专门给 OpenTitan 留一路中断输入用于异步通知 A7安全操作完成。这个中断要接到 STM32MP1 的 EXTI 控制器上并且在 Linux 设备树中配置为专用的中断号。如果和普通 GPIO 中断混用高负载下会丢失安全事件排查起来非常痛苦。3.3 通信协议设计SPI 通信不能只发裸数据需要定义一套简单的请求应答协议。我一般会定义一个固定长度的命令头结构如下typedef struct { uint8_t magic; // 固定 0x5A用于帧同步 uint8_t cmd; // 命令码0x01 获取状态0x02 密钥派生0x03 签名验证 uint16_t length; // 数据域长度大端序 uint32_t crc32; // 整个帧的校验值 } ot_cmd_header_t;每个命令的应答也遵循同一套帧结构A7 发送命令后进入等待状态OpenTitan 处理完成后通过中断通知 A7 读取应答。为什么要加 crc32因为 SPI 在高速率下偶发位翻转的概率不低而安全芯片通信如果出现静默错误后果比性能下降严重得多。帧同步靠 magic 字段完成接收方发现 magic 不对就丢弃并重新同步。3.4 主控侧 SPIDEV 通信代码在 Linux 侧通过内核的 spidev 驱动发送命令是最直接的方式。int fd open(/dev/spidev0.0, O_RDWR); if (fd 0) { perror(open spidev); return -1; } uint8_t mode SPI_MODE_0; uint32_t speed 1000000; // 1MHz先跑稳再提速 ioctl(fd, SPI_IOC_WR_MODE, mode); ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, speed); uint8_t tx[8] {0x5A, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; uint8_t rx[8] {0}; struct spi_ioc_transfer tr { .tx_buf (unsigned long)tx, .rx_buf (unsigned long)rx, .len sizeof(tx), .speed_hz speed, .delay_usecs 0, .bits_per_word 8, }; ioctl(fd, SPI_IOC_MESSAGE(1), tr);这段代码里值得说明的是 spi_ioc_transfer 结构体的参数speed_hz 可以单独指定本次传输的速率不必和设备树里的 max-speed-hz 完全一致delay_usecs 表示两次传输之间的延时在 OpenTitan 处理应答前给一个小的延时可以减少忙等的时间bits_per_word 不设的话默认是 8 位。实际操作中SPI_MODE_0 和 SPI_MODE_3 都可能遇到取决于 OpenTitan 固件的 SPI 从机配置一定要两端对齐。对于超过 64 字节的数据传输ioctl 方式一次只能传递有限大小的缓冲区性能和吞吐率都不理想更工程化的做法是配合 DMA 传输。但这依赖设备树里 SPI 节点的 dma 属性配置不是简单改代码能解决的需要单独验证。4. 基于 OpenTitan 的 STM32MP1 可信执行环境构建4.1 构建流程与工具链准备构建这套环境的工具链分为两条线OpenTitan 侧和 STM32MP1 侧。OpenTitan 的固件用 RISC-V 交叉编译工具链编译在 Ubuntu 上直接安装 gcc-arm-none-eabi 即可因为 OpenTitan 当前的发布版本面向裸机环境不需要操作系统支持。STM32MP1 侧的 Linux 内核和 FSBL 编译则使用 ARM 官方的交叉编译器版本选择要与官方 SDK 保持一致。sudo apt install gcc-arm-none-eabi git clone https://github.com/lowRISC/opentitan.git cd opentitan pip3 install --user -r python-requirements.txtOpenTitan 的构建系统基于 meson 和 ninja编译固件的命令是ninja -C build-out sw/device/lib。在生成 OpenTitan 的 OTP 初始化镜像和 ROM_EXT 时要注意配置文件里的--lc-state参数开发阶段用DEV状态量产切换到PROD状态两个状态下可访问的调试接口完全不同。初次搭建时最容易踩的坑是 OTP 配置与芯片生命周期状态不匹配导致芯片反复进入 RMA 流程。4.2 安全启动链的落地OpenTitan 集成到 STM32MP1 启动链后的分区结构大致如下镜像存放位置验证方式加载者OpenTitan ROM内部只读存储器硬件固定不可修改硬件上电自动执行ROM_EXT外部 SPI FlashOpenTitan ROM 验签OpenTitan ROMBoot Services外部 SPI FlashROM_EXT 验签ROM_EXTSTM32MP1 FSBL外部 SPI FlashBoot Services 验签OpenTitanLinux Kernel外部存储介质FSBL/OP-TEE 验签FSBL这个启动链设计里最关键的变化是FSBL 不是由 STM32MP1 自身验证而是由 OpenTitan 验证。STM32MP1 上电后处于复位状态OpenTitan 完成镜像检查后才会释放复位信号允许 A7 核从指定地址启动。这样做的好处是即使 A7 侧的 BootROM 存在漏洞也影响不到信任根。整条链路的验签时间开销是必须评估的。RSA-2048 验签在 OpenTitan 的 OTBN 加速下大约在几十毫秒量级加上镜像读取和哈希计算整个启动时间会比原生启动增加几百毫秒。如果产品对开机时间敏感可以在 OpenTitan 侧做一次启动缓存把上次验签通过的镜像哈希记录在 OTP 或 SRAM 中后续启动做快速校验。4.3 固件移植与通信接口开发将 OpenTitan 固件移植到 STM32MP1 平台的实质是让 OpenTitan 通过 SPI 与主控通信同时让主控侧的内核驱动能够识别并访问 OpenTitan 的安全服务。这需要在 Linux 内核中新增一个简单的平台驱动static int ot_probe(struct platform_device *pdev) { struct ot_dev *ot; ot devm_kzalloc(pdev-dev, sizeof(*ot), GFP_KERNEL); ot-spi devm_spi_register(pdev, SPI_MODE_0, 20000000); ot-irq platform_get_irq(pdev, 0); devm_request_irq(pdev-dev, ot-irq, ot_isr, 0, ot, ot); ot_create_sysfs_attrs(ot); return 0; }设备树里需要给这个驱动声明 SPI 片选编号、中断号和 DMA 通道。DMA 通道不是必须的但如果后续要做大块数据加密没有 DMA 会导致 CPU 占用率过高。通信接口开发时建议先做一个只读版本的命令比如获取芯片状态打通整个收发路径后再扩展密钥相关的命令这样可以快速区分是 SPI 硬件问题还是固件逻辑问题。4.4 加密机制与访问控制的具体配置AES-CBC 加解密的工程实现密钥管理是可信执行环境的核心。AES 密钥由 OpenTitan 的 KMAC 模块基于主密钥派生主密钥存放在 OTP 中运行时不落盘。主机需要加密数据时发送派生请求OpenTitan 返回派生后的会话密钥给主控会话密钥只存在于内存中。aes_ctx_t ctx; aes_params_t params { .mode AES_MODE_CBC, .key_len AES_KEY_128, }; aes_init(ctx, params, session_key, iv); aes_crypt(ctx, plaintext, ciphertext, data_len);这段代码里的 aes_init 会把密钥加载到 OpenTitan 的 AES 硬件模块寄存器中而不是软件里做轮运算。data_len 必须是 16 字节的整数倍不足部分要手动做 PKCS7 填充。AES-CBC 模式的 IV 每次加密应该随机生成不能固定否则相同的明文会得到相同的密文泄露数据模式。访问控制的实现OpenTitan 侧的 PMP 保护 Flash 固件区域STM32MP1 侧使用 ETZPCExtended TrustZone Protection Controller隔离外设两者配合形成两层访问控制。PMP 偏重物理内存的读写保护ETZPC 偏重总线级别的外设访问隔离。例如可以把 GPIO 控制器的寄存器空间配置为仅 Cortex-M4 可访问A7 侧 Linux 即使被攻破也无法直接操作关键控制引脚。4.5 测试与验证功能测试可以从三个方面设计正常路径测试构建签名镜像确认启动成功、篡改路径测试修改 FSBL 任意一个字节确认启动失败、回滚测试用旧版本镜像覆盖新版确认 OpenTitan 拒绝加载。其中回滚测试容易被忽略但恰恰是最常出问题的环节。OpenTitan 的 Boot Services 需要记录每个镜像的版本号版本号低于当前值时直接拒绝加载。注意版本号的存储位置要在 OTP 或专门的反回滚计数器中如果存在普通 Flash攻击者可以整体擦除再写入旧镜像让版本号检查形同虚设。5. 性能评估思路与值得留意的优化细节可信执行环境的性能评估不能只看 CPU 跑分要从四个维度设计指标计算性能关注 RSA 签名验证和 AES 加解密的吞吐率存储性能关注 OTP 读写和 Flash 读取延迟通信性能关注 SPI 单次命令往返时延和批量传输吞吐率安全性能关注启动链各阶段的验签耗时。OpenTitan 侧的性能测试需要写专门的固件在调用 OTBN 验签前后读取时间戳计数器记录单次 RSA-2048 验签的周期数。SPI 通信性能可以在 Linux 主控侧用 spidev_test 工具测试sudo ./spidev_test -D /dev/spidev0.0 -s 10000000 -H -b 8 -p 5A01000000000000 -v这里的 -s 参数指定 10MHz 时钟频率-H 表示 SPI 模式 3-b 8 表示 8 位字长-v 输出详细的收发对比。如果收到数据与发送数据不一致先降低频率到 1MHz 验证排除信号质量问题后再逐级提升。如果 1MHz 下都不一致重点检查 MISO 和 MOSI 是否接反以及片选信号极性是否配置正确。实测中节省性能最明显的优化是把 SPI 传输做成 DMA 模式。当数据量超过 64 字节时CPU 轮询方式的吞吐率会下降一半以上DMA 可以完全释放 A7 的算力去处理业务逻辑。DMA 模式需要保证 SPI 控制器的 DMA 请求信号与 OpenTitan 的中断信号配合好否则 DMA 传输完成通知丢失主控会一直等待。另一个值得做的优化是密钥缓存。如果业务场景中大量数据需要同一个密钥加解密不要每次都向 OpenTitan 请求派生而是在内存中保留一个经认证的会话密钥并定期轮换。这样可以显著降低 SPI 通信频率但轮换周期不能太长一般由产品安全策略决定。密钥缓存的释放时机也要注意当 OpenTitan 生命周期状态发生变化或检测到物理攻击时必须立即清空缓存。最后建议在量产阶段把 OpenTitan OTP 的调试接口完全锁死同时利用 STM32MP1 侧的硬件看门狗监控 A7 和 OpenTitan 之间的心跳任何一方超过设定时间无响应即触发系统复位。这样既保护了根密钥也保证了可信执行环境长期运行的稳定性。本文还有配套的精品资源点击获取
