RA8E2安全状态机：PL/AL双维度模型与密钥认证实战解析 1. 项目概述理解RA8E2的安全状态机模型在嵌入式系统开发尤其是涉及支付终端、工业控制、智能家居网关等对安全性有严苛要求的领域我们常常面临一个核心矛盾如何在产品生命周期的不同阶段开发、测试、量产、现场维护为不同的参与者芯片原厂、方案开发商、第三方应用开发者、终端用户分配恰到好处的访问权限权限给多了核心知识产权和敏感数据面临泄露风险权限给少了又会阻碍正常的开发、生产和维护流程。瑞萨电子的RA8E2系列微控制器作为一款基于Arm® Cortex®-M85内核的高性能MCU其安全子系统提供了一个非常精巧的解决方案——一个基于保护等级和认证等级的双维度状态机模型。这个模型不是简单地“锁死”或“放开”而是构建了一个有层次、可演进的安全边界。简单来说保护等级定义了“你能做什么”比如能否调试、能否擦写Flash而认证等级则定义了“你凭什么能做”即通过何种密钥认证来证明你的身份。两者结合共同决定了MCU在某一时刻的安全姿态。理解这套机制对于任何需要在RA8E2上实现安全启动、安全固件更新、安全工厂编程以及构建可信执行环境的开发者来说都是至关重要的第一步。它决定了你的产品安全架构的基石是否稳固。本文将从一个一线开发者的视角深入拆解RA8E2的PL/AL状态转换逻辑、密钥认证流程并结合实际开发中遇到的典型场景分享配置要点和避坑经验。2. 核心概念拆解PL与AL的职责与关系要驾驭RA8E2的安全状态机首先必须清晰区分保护等级和认证等级这两个核心概念。它们听起来相似但扮演着截然不同的角色。2.1 保护等级定义访问能力的“硬开关”保护等级即Protection Level在RA8E2中简称为PL。你可以把它想象成一套物理上的门禁系统和保险柜锁。它直接控制着对MCU内部关键资源的访问能力是一种相对“静态”的权限设置。RA8E2定义了三个PL等级PL2开发级。这是权限最高的等级通常只在芯片出厂后的初始开发阶段使用。在此等级下调试接口包括安全和非安全调试完全开放串行编程接口可以访问所有Flash区域代码Flash、数据Flash。开发者可以自由地编程、擦除、读取整个存储器空间并进行全面的调试。PL1受限开发级。这个等级旨在提供给进行非安全应用开发的合作伙伴或团队。在此等级下安全调试功能被禁用调试器只能访问预先定义好的非安全内存区域。串行编程接口虽然可用但被禁止对安全代码或数据Flash区域进行编程、擦除或读取操作。这有效隔离了安全核心资产与非安全应用代码。PL0产品级。这是最终产品部署到现场时所处的等级权限最为严格。所有调试功能均被禁用串行编程接口虽然物理上可能仍能连接但无法访问任何代码或数据Flash区域。MCU就像一个“黑盒”仅能通过预设的安全通道如安全启动后运行的应用进行交互。PL的设定直接体现在硬件层面决定了调试器和编程器“能看到什么、能操作什么”。降低PL等级例如从PL1降到PL0通常没有限制因为这是在收紧权限但想要提升PL等级例如从PL0升到PL1则必须满足更高的身份认证要求这就是AL要解决的问题。2.2 认证等级标识身份合法性的“密钥”认证等级即Authentication Level简称为AL。如果说PL是“门锁”那么AL就是证明你有权开锁的“钥匙”等级。它代表了当前MCU所持有的、经过验证的密钥身份。RA8E2主要涉及三个AL等级AL2最高信任等级。表明MCU已经注入了AL2_KEY并且可能还持有其他高级密钥。处于AL2意味着操作者被证明是可信的“安全开发者”或拥有最高权限。AL1中级信任等级。表明MCU已经注入了AL1_KEY但可能没有AL2_KEY。处于AL1通常对应“非安全开发者”或拥有部分权限的实体。AL0无认证等级。表示MCU未持有任何有效的AL密钥或者密钥已被禁用。这是出厂默认状态或最终产品状态。AL等级本身不直接控制硬件访问但它是一个先决条件。你想把门锁PL调到某个级别请先出示对应级别的钥匙AL来证明你的身份。例如想要从PL0提升到PL1你必须至少处于AL1即拥有AL1_KEY想要从PL1提升到PL2你必须处于AL2即拥有AL2_KEY。2.3 PL与AL的协同构建动态安全边界PL和AL不是孤立的它们通过一套明确的规则协同工作构成了状态转换的基础逻辑PL决定能力AL决定资格PL定义了当前可用的硬件访问能力调试、编程而AL则定义了当前操作者被认证的身份级别。降级自由升级需证PL向更低等级放松限制方向的反向即收紧权限转换通常无需认证。但PL向更高等级放松权限转换时要求当前的AL必须大于或等于目标PL所要求的最低AL。例如当前AL为AL1时可以切换到PL1因为AL1 要求AL1但无法切换到PL2因为AL1 要求AL2。AL的独立性AL的降低如从AL2降到AL1无需认证但AL的提升必须通过对应的密钥认证流程使用AL2_KEY或AL1_KEY。这套机制的精妙之处在于它为产品生命周期管理提供了清晰的路径。一个典型的流程是芯片出厂PL2 AL0 - 安全开发者注入AL2_KEY并设置安全区域进入AL2- 安全开发者将PL降至PL1移交设备给非安全开发者 - 非安全开发者注入AL1_KEY进入AL1并开发非安全应用 - 最终产品部署时禁用调试命令和不需要的AL1_KEY并将PL降至PL0。3. 状态转换详解规则、命令与密钥认证理解了PL和AL的基本概念后我们深入到状态转换的具体规则和操作方法。RA8E2主要通过其引导固件提供的命令集来管理这些状态转换。3.1 状态转换的核心规则图谱根据用户手册中的描述我们可以将PL和AL的状态转换规则可视化虽然不能画图但可以精确描述PL状态PL0 PL1 PL2与AL状态AL0 AL1 AL2共同构成一个二维状态空间。PL转换规则向低PL转换如PL2 - PL1 PL1 - PL0无限制可以直接通过引导固件命令完成。向高PL转换如PL0 - PL1 PL1 - PL2必须满足当前AL 目标PL所需的最低AL。具体来说切换到PL1需要当前AL至少为AL1切换到PL2需要当前AL为AL2。AL转换规则向低AL转换如AL2 - AL1 AL1 - AL0无限制。向高AL转换如AL0 - AL1 AL1 - AL2必须通过对应的密钥认证。从AL0提升到AL1需要使用AL1_KEY进行认证从AL1提升到AL2需要使用AL2_KEY进行认证。如果对应的密钥被永久禁用则相应的AL提升路径将被阻断。这里有一个关键点AL2_KEY可以在AL2状态下被永久禁用AL1_KEY可以在AL2或AL1状态下被永久禁用。一旦禁用相应的AL提升路径就永久关闭了这是一个不可逆的操作常用于产品最终锁定。3.2 关键操作命令解析引导固件提供了一系列命令来操作PL和AL其中最核心、也最危险的是Initialize命令。功能Initialize命令会将PL重置为PL2并擦除Flash存储器中的所有内容。这是一个“核弹”级别的命令用于将设备恢复到接近出厂的状态但安全配置如永久锁定的区域可能保留。执行前提该命令的执行有严格条件PL可重置除非该命令本身被禁用。无永久锁定如果存在任何被永久锁定的Flash块或寄存器命令将无法执行。具体来说需要PBPS和PBPS_SEC寄存器的所有位均为1且FSPR位为1。密钥状态当AL2_KEY被禁用时Initialize命令也会被禁用。危险性命令执行后MCU将无响应。要继续使用引导固件命令必须在执行Initialize命令并复位后再次进入引导模式。这意味着这个命令会中断当前会话必须谨慎规划操作序列。禁用方法可以通过参数设置命令在所有AL状态下永久禁用Initialize命令以防止未授权的擦除操作。3.3 密钥认证机制深度剖析AL等级的提升依赖于密钥认证。RA8E2使用的是基于AES-128的CMAC挑战-应答认证机制。这是一种对称加密的认证方式。密钥注入在进行认证前必须先将密钥AL1_KEY或AL2_KEY注入到MCU中。这是一个安全的过程通常发生在安全开发环境中。密钥注入本身也需通过安全密钥注入流程完成详见后文第5节。AL2_KEY只能在AL2状态下注入AL1_KEY可以在AL2或AL1状态下注入。认证流程挑战当请求提升AL等级时MCU的引导固件会生成一个128位的随机数作为“挑战”发送给请求者如编程器或上位机工具。应答计算请求者使用预先注入的对应密钥AL1_KEY或AL2_KEY通过AES-128 CMAC算法计算这个“挑战”数据的密码学消息认证码。计算公式为应答 AES-128-CMAC(密钥 128位挑战)。验证请求者将计算出的“应答”发回给MCU。MCU使用内部存储的相同密钥进行相同的计算并比对结果。如果匹配则认证成功AL等级提升。算法选择的意义使用AES-128 CMAC而非简单的AES加密是因为CMAC专门用于消息认证能有效防止重放攻击。MCU每次生成的随机挑战不同确保了即使窃听到一次认证过程的数据也无法用于下一次认证。实操心得密钥管理是命门在实际项目中AL2_KEY和AL1_KEY的生成、分发、注入和销毁流程必须作为最高机密来管理。我的经验是分权管理AL2_KEY应由最核心的安全团队或芯片原厂掌握用于初始安全环境搭建和AL1_KEY的注入授权。AL1_KEY可以分发给合作的非安全应用开发团队。注入环境隔离密钥注入操作应在物理安全、网络隔离的环境中进行使用专用的编程工具和经过审计的脚本。及时禁用在产品发布前务必通过引导固件命令永久禁用不再需要的AL密钥例如如果非安全开发者后续无需再提升权限则禁用AL1_KEY。这是一个重要的安全收尾动作。备份与恢复密钥本身必须安全备份但备份介质如HSM、智能卡的访问控制必须比MCU本身更严格。永远不要将明文密钥存储在普通电脑或版本控制系统中。4. 调试与编程接口的权限映射PL和AL的状态不仅影响内部状态转换更直接决定了开发人员最关心的两个外部接口调试接口和串行编程接口的可用性。用户手册中的表格清晰地展示了这种映射关系这对于开发和调试策略规划至关重要。4.1 各认证等级下的接口权限表下表总结了不同AL等级下调试和编程接口的行为认证等级调试功能串行编程接口AL2安全调试与非安全调试均启用调试器可以访问所有调试区域。所有功能均可用可以无限制地对代码和数据Flash进行编程、擦除、读取。AL1仅启用非安全调试调试器只能访问预先定义好的非安全调试可访问区域。安全代码和数据区域对调试器不可见。接口可用但功能受限。可以连接并进行一些操作但禁止对安全代码或数据Flash区域进行编程、擦除或读取。AL0无调试功能可用调试接口被完全阻断。接口可用但访问被阻断。可以连接但无法访问任何代码或数据Flash区域。4.2 对开发流程的实际影响这个权限映射直接塑造了安全嵌入式产品的开发流程安全核心开发阶段AL2 PL2安全开发团队拥有全部权限可以开发和调试安全世界TrustZone Secure World的所有代码设置安全属性并准备非安全世界Non-secure World的运行时环境。这是整个系统安全的奠基阶段。非安全应用开发阶段AL1 PL1应用开发团队拿到设备时他们只能进行非安全应用的开发和调试。他们无法看到或修改安全区域的代码和数据也无法通过编程接口窃取安全资产。这实现了安全的职责分离。产品部署与现场维护阶段AL0 PL0设备交付给终端用户。此时任何通过调试接口或标准编程接口直接访问芯片内部内容的尝试都将被阻止。固件更新必须通过设备内部已实现的安全引导和安全更新协议来完成例如通过加密签名和验签的OTA更新。注意事项调试隔离的陷阱在AL1状态下进行非安全调试时一个常见的坑是安全中断或安全调用引发的异常行为对非安全调试器不可见。例如如果非安全应用错误地触发了安全世界的功能可能只会看到非安全世界“卡死”了但调试器无法揭示安全世界内部的错误状态。因此在AL1阶段进行集成调试时需要与非安全团队明确异常处理协议或者由安全团队在AL2阶段预先提供详尽的非安全API使用文档和错误码定义。5. 安全密钥注入流程全解析无论是用于AL认证的AL2_KEY、AL1_KEY还是用于其他安全功能的密钥其安全注入都是RA8E2安全机制的基石。这个过程确保了密钥在传输和存储过程中不会以明文形式暴露在不安全的环境中。瑞萨提供了安全密钥管理工具来辅助完成这个复杂的流程。5.1 密钥注入的标准化步骤密钥注入流程是一个典型的“密钥包装”过程其核心思想是永远不在不安全信道传输明文主密钥。创建安装密钥用户首先生成一个256位的用户工厂编程密钥。这个UFPK是整个过程的主密钥必须严格保密。它用于包装即加密最终要注入到MCU的用户密钥。获取包装后的UFPK用户将UFPK提交给瑞萨密钥包装服务。这是一个由瑞萨运营的安全服务它使用瑞萨的根密钥对用户的UFPK进行加密生成一个包装后的UFPK。W-UFPK可以公开传输因为只有瑞萨的私钥才能解密它而该私钥不会离开瑞萨的安全服务器。包装用户密钥在用户自己的安全环境中使用UFPK明文和安全密钥管理工具对需要注入的用户密钥进行加密生成包装后的用户密钥。这个用户密钥可以是AL2_KEY、AL1_KEY或者是应用程序使用的加密密钥。注入密钥通过引导固件接口将W-UFPK和包装后的用户密钥发送给RA8E2 MCU。MCU内部的安全硬件执行以下操作使用内置的、唯一的硬件密钥解密W-UFPK恢复出UFPK。使用恢复出的UFPK解密包装后的用户密钥得到明文用户密钥。最后MCU使用其自身的另一个硬件唯一密钥重新加密即进行二次包装这个用户密钥并将结果存储到非易失性存储器中。对于DLM等密钥存储在不可映射的Flash区域对于应用密钥则存储在命令指定的地址。这个过程确保了从用户生成UFPK开始到密钥最终存入MCU真正的用户密钥明文只出现在用户的安全环境和MCU的安全硬件内部。5.2 可注入的密钥类型根据手册可以通过此流程注入的密钥主要包括两类DLM转换密钥用于设备生命周期状态转换。AL转换密钥即AL2_KEY和AL1_KEY用于提升认证等级。5.3 安全工厂编程的关联安全密钥注入流程与安全工厂编程紧密相关。在非安全的生产环境中例如第三方代工厂要烧录加密的固件镜像也需要用到类似的包装机制。此时用户使用UFPK包装一个镜像加密密钥然后用该密钥加密整个固件镜像。工厂产线只需要将W-UFPK、包装后的镜像加密密钥和加密的固件镜像发送给MCU即可完成烧录而产线环境始终接触不到任何明文密钥或固件代码有效防止了生产环节的固件泄露。实操心得密钥注入的工程实践环境准备准备一台离线、无网络连接的专用电脑用于运行安全密钥管理工具和生成UFPK。所有操作应有日志记录和双人复核。服务交互与瑞萨密钥包装服务的交互通常需要通过加密邮件或安全门户网站提交UFPK。务必确认接收W-UFPK的通道安全并进行完整性校验。注入验证密钥注入后不要立即进行关键的状态转换。应先编写一个简单的测试程序尝试使用新注入的密钥进行AL等级提升认证验证密钥是否被正确注入和存储。流程自动化对于量产应将密钥注入和固件编程步骤脚本化、自动化减少人工操作错误。但脚本本身必须存放在安全环境中并对其访问进行严格控制。6. 典型设备生命周期与状态转换实例理论需要结合实践。用户手册中给出了一个非常经典的设备生命周期状态与PL转换示例清晰地描绘了从芯片出厂到最终产品部署的全过程中安全开发者和非安全开发者如何协作以及PL/AL状态如何演变。这个示例是设计产品安全流程的绝佳模板。6.1 安全开发者阶段此阶段由掌握最高权限的团队通常是系统架构方或安全方案提供商执行目标是搭建安全基础环境并做好移交准备。设置安全属性使用引导固件命令配置代码Flash和数据Flash的内存安全属性。这是划分安全世界与非安全世界内存边界的关键一步。如果未设置默认所有区域都是安全的。开发与调试在安全属性设置好后安全团队开始编程和调试安全应用例如安全启动代码、TrustZone安全服务、加密库等。密钥注入如果需要安全团队向MCU注入AL2_KEY和RMA_KEY。RMA_KEY用于后续可能发生的返厂分析流程。为移交做准备在将设备交给非安全开发者之前安全团队需要进行一系列“锁定”操作以限制后续开发者的权限禁用Initialize命令如果不想让非安全开发者有能力擦除整个Flash包括安全代码则禁用此命令。禁用AL2_KEY如果后续流程中不再需要提升到AL2即非安全开发者无需接触安全核心则可以永久禁用AL2_KEY。这同时也会禁用Initialize命令增加了另一层保护。降低PL等级最后使用引导固件命令将PL从PL2降至PL1。至此设备移交。6.2 非安全开发者阶段此阶段由进行上层应用开发的团队执行他们在受限的环境中工作。开发与调试非安全开发者在PL1、AL1或AL0如果未注入AL1_KEY状态下编程和调试非安全应用程序。他们只能访问非安全内存区域和受限的调试功能。注入AL1_KEY如果非安全开发者后续需要执行某些需AL1权限的操作例如在特定条件下更新非安全固件则可以在此阶段注入AL1_KEY。为产品部署做准备应用开发完成后准备将设备锁定为最终产品状态禁用Initialize命令如果尚未禁用或根据产品需求决定禁用。禁用AL1_KEY如果产品部署后不再需要进行任何需要AL1认证的操作如现场调试则永久禁用AL1_KEY关闭AL提升通道。降低PL等级使用引导固件命令将PL从PL1降至PL0。设备进入最终锁定状态。6.3 故障分析阶段如果产品在市场上出现故障需要返厂分析则需要特殊的流程请求分析客户需要将设备生命周期状态更改为RMA_REQ。这个操作需要RMA_KEY进行认证或者使用MCU的唯一ID作为认证码的一部分。执行分析瑞萨在收到处于RMA_REQ状态的设备后才能进行故障分析。返回设备分析完成后瑞萨将设备生命周期状态更改为RMA_RET然后返还给客户。这个流程确保了即使设备返厂其内部的安全资产如密钥、安全代码在未授权的情况下也无法被分析人员获取除非通过合法的RMA流程。7. 安全工厂编程与现场更新策略对于量产和产品生命周期维护RA8E2的安全机制提供了两个强大的功能安全工厂编程和双模式现场更新。7.1 安全工厂编程要点安全工厂编程允许在非安全的生产环境如代工厂中烧录加密的固件防止知识产权泄露。核心前提MCU必须处于OEM设备生命周期状态。命令特性一个专门的引导固件命令可以一次性完成多项操作编程加密固件、设置DLM状态、改变PL、注入AL密钥。这极大地简化了产线流程。关键约束初始PL必须是PL2最终PL必须是PL0。这意味着该命令包含了PL降级过程。如果DLM状态保持在OEM则必须注入AL2_KEY且不能注入AL1_KEY。如果要将MCU转换到LCK_BOOT状态则不能注入任何AL密钥。AL2_KEY必须与镜像加密密钥使用同一个UFPK进行包装。该命令会擦除所有代码和数据Flash区域选项设置存储器除外。如果存在永久锁定的块命令无法执行。对启动区域选择相关的寄存器设置有严格要求必须配置为从引导固件启动。加密固件镜像中必须包含所有选项设置存储器的值即使是默认值。但如果某些区域如SAS寄存器、数据Flash选项设置存储器中的可锁定区域已被写保护则镜像中不应包含对这些区域的写入数据否则命令会报错终止。7.2 双模式现场更新流程对于支持双Bank启动的RA8E2型号其现场固件更新流程需要仔细设计以在Bank交换时保持安全或非安全区域的内容。这是实现无缝、安全OTA更新的基础。手册中给出了两个典型的更新流程更新安全或非安全可调用区域初始状态BANK0中包含固件版本1BANK1为空。更新安全区域首先将BANK0中的非安全固件复制到BANK1然后在BANK0中更新安全部分到版本2最后执行Bank交换。这样在交换的瞬间新旧版本的非安全固件是一致的避免了因安全/非安全接口不匹配导致的崩溃。更新非安全可调用区域流程类似但复制的是安全部分。更新非安全区域初始状态同上。复制安全部分首先必须由安全服务将BANK0中的安全和非安全可调用固件复制到BANK1。这一步是关键因为它确保了安全代码的完整性由安全世界控制。更新非安全部分然后非安全用户更新BANK0中的非安全固件到版本2。执行Bank交换最后执行交换完成更新。避坑指南现场更新的常见问题Bank交换后的启动失败最常见的原因是安全与非安全固件版本不匹配。务必严格按照上述流程确保在交换前目标Bank中的安全/非安全固件组合是兼容的。在更新流程中增加版本兼容性检查是一个好习惯。回滚机制缺失双Bank模式天然支持回滚切回旧Bank。但在设计更新协议时必须考虑如何安全地标记哪个Bank是“正在运行”的哪个是“更新后待测试”的并在新固件稳定运行后再将其标记为“有效”。这通常需要在某个安全存储区域如选项字节或受保护的数据Flash保存状态标志。更新过程中的断电必须考虑更新过程被意外断电打断的情况。设计上应保证即使更新中断设备也能从另一个完整的Bank启动。这通常意味着在擦写新Bank之前不要破坏旧Bank的可启动性并且更新操作如擦除、编程、设置启动标志应设计成原子的或可恢复的。8. 安全属性与特权属性寄存器详解RA8E2通过一系列外设安全属性寄存器PSARx和外设特权属性寄存器PPARx来实现对系统资源的精细化访问控制。这些寄存器是构建安全与非安全世界隔离、特权与非特权模式隔离的硬件基础。8.1 外设安全属性寄存器PSAR寄存器决定了某个外设或模块是归属于安全世界还是非安全世界。这是Arm TrustZone®技术在RA8E2上的具体实现。功能每个位对应一个特定的外设如SCI0、ADC12_0、CANFD等及其对应的模块停止控制位。将该位设置为0表示该外设为安全属性设置为1表示该外设为非安全属性。地址这些寄存器位于PSCU系统控制单元的安全地址空间0x4020_4000和非安全别名地址空间0x5020_4000。访问控制从非安全世界只能访问标记为非安全属性的外设。尝试访问安全外设会导致总线错误。从安全世界可以访问所有外设无论其安全属性如何。典型配置在安全启动初期由安全启动代码或安全服务来配置这些寄存器。通常将关键的外设如加解密模块、真随机数生成器、某些用于安全通信的串口配置为安全属性而将用户界面、应用逻辑相关的外设配置为非安全属性。8.2 外设特权属性寄存器PPAR寄存器决定了在非安全世界内对某个外设的访问是否需要特权模式。这是对Cortex-M内核特权模式的补充和细化。功能同样每个位对应一个外设。将该位设置为0表示访问该外设需要特权模式设置为1表示允许在非特权模式下访问。应用场景在运行非安全世界的RTOS时可以将关键的系统外设如系统定时器、DMA控制器配置为需要特权模式访问而将应用层的外设如GPIO、普通定时器配置为允许非特权访问。这样即使非安全世界的用户态应用崩溃或被恶意利用也无法直接操作关键系统资源增加了系统的健壮性。与PSAR的关系PPAR的检查发生在PSAR之后。即首先判断发起访问的CPU是处于安全状态还是非安全状态PSAR控制如果在非安全状态再进一步判断当前CPU模式是特权模式还是非特权模式PPAR控制。8.3 配置策略与实操建议最小权限原则初始状态下将所有外设的安全属性设置为安全0特权属性设置为需要特权0。然后根据应用程序的实际需求逐步、精确地开放权限。静态与动态配置PSAR/PPAR的配置通常在系统初始化时完成之后保持不变。但在一些高级应用场景下安全服务可以动态地修改某些外设的属性以实现安全的资源共享。例如安全世界可以临时将一个SPI控制器“借”给非安全世界使用用完后收回。调试影响在AL1状态下进行非安全调试时调试器只能访问非安全外设。即使一个外设在硬件上连接着如果它的PSAR位被设置为安全非安全调试器也无法看到或操作它。这在调试硬件相关问题时需要特别注意。寄存器保护注意这些寄存器本身可能也是可写的。为了防止非安全世界或非特权代码恶意修改这些配置需要利用MCU的写保护机制如寄存器写保护位来锁定它们。理解并正确配置PSAR和PPAR寄存器是确保RA8E2的硬件隔离机制有效运行的关键。它使得安全世界成为一个真正受保护的“保险箱”而非安全世界则在一个受控的“沙箱”中运行两者通过明确的硬件边界进行交互共同构建起一个坚固的可信计算基础。