简介：本资源为《可信计算3.0技术及其应用实践》专题技术文档，面向网络安全工程师、等保测评人员、信创领域研发与实施人员，系统解析可信计算3.0的主动免疫架构、等级保护2.0合规要求及典型节点构建方法。文档由国内可信计算龙头企业——北京可信华泰信息技术有限公司于2020年4月发布，内容涵盖可信3.0与1.0/2.0的本质差异、国际（TPM2.0/SGX/TrustZone/Titan）与国内（白细胞平台、ARM同构双体系、海光/华为CPU内嵌TCM）发展脉络、四大国标规范要点，以及“基于可信根的动态度量+实时报警+审计上送”这一核心测评指标的落地实现逻辑。资源为单文件PDF，大小4.01MB，结构清晰、图文并茂，含技术演进对比图、可信架构示意图及政策法规引用原文，便于快速掌握技术主线与合规要点。目前已有1759人学习下载，是理解可信计算从理论到工程实践的关键参考资料。
1. 可信计算3.0不是加个TPM芯片就完事：它解决的是“系统启动后谁还在控制权”这个被长期忽视的致命问题
很多人第一次听说可信计算3.0，是在看到某国产服务器BIOS界面弹出“TCM已启用”提示时；也有人把它等同于Windows的Secure Boot或Linux的IMA（Integrity Measurement Architecture）——这恰恰是踩坑的起点。可信计算3.0的核心突破，不在于“能不能度量”，而在于构建一条从硬件根到应用层的、不可旁路的、可验证的控制流信任链。它直面一个现实：即便BootROM、UEFI、内核镜像全被签名验证通过，一旦系统启动完成，恶意驱动、提权后的用户态进程、甚至合法但存在逻辑缺陷的管理服务，仍可能在无人监督下篡改关键数据、劫持通信路径、伪造日志。某高校实验室曾复现过一种攻击：在通过所有启动阶段验证的Linux系统中，仅通过加载一个未签名但功能完备的eBPF程序，就实现了对全部网络连接的透明重定向——而整个过程在传统可信启动框架下完全“不可见”。可信计算3.0正是为封堵这类“启动后信任断层”而生。它适合三类人：需要满足等保2.0三级及以上要求的系统集成商、正在设计高安全等级嵌入式设备的固件工程师、以及正被“合规通过但实际失守”问题困扰的安全架构师。本文不讲抽象模型，只聚焦一线落地中最常卡住的五个环节：信任根选型依据、静态度量与动态度量的协同边界、如何让业务代码真正“接入”而非“挂载”可信链、策略引擎的最小可行配置、以及最易被忽略的“度量日志可信归档”实操。
2. 从信任根开始：为什么必须放弃“纯软件模拟TPM”并严格区分TCM与TPM2.0的物理部署路径
可信计算3.0的信任根基绝非可选项，而是整个链条的强度上限。实践中，大量项目初期因采购周期或兼容性考虑，采用软件模拟的TPM（如swtpm）或直接复用旧平台的TPM1.2模块，结果在后续动态度量和远程证明环节遭遇不可逆失败。根本原因在于：可信计算3.0要求信任根具备抗物理篡改、密钥不可导出、指令执行原子性三大硬性能力，而软件模拟无法提供任何一项。
2.1 为什么TCM是当前国产化场景的务实起点
国内主流可信计算3.0方案普遍采用TCM（Trusted Cryptography Module）作为首选信任根，其核心优势并非性能，而是与国密算法体系的原生绑定。TCM芯片内部固化SM2/SM3/SM4算法引擎，且密钥生成、签名、加密全过程均在芯片内部完成，私钥永不离开芯片边界。这直接规避了TPM2.0在国密适配中常见的“算法替换不彻底”风险——例如某次第三方测评发现，某TPM2.0模块虽宣称支持SM2，但其密钥协商流程仍调用底层RSA引擎进行中间计算，导致侧信道攻击面扩大。
提示：TCM与TPM2.0的物理接口虽同为LPC总线，但寄存器定义、命令集、密钥层次结构完全不同。强行将TPM2.0驱动加载到TCM硬件上，会导致系统在POST阶段即卡死，且无任何错误码输出。这是硬件级不兼容，非驱动补丁可解。
2.2 在x86平台实现TCM的最小硬件依赖清单
要使TCM真正生效，BIOS/UEFI固件必须完成三项强制配置，缺一不可：
| 配置项 | BIOS设置路径（典型） | 必须值 | 验证命令（Linux启动后） |
|---|---|---|---|
| TCM控制器使能 | Advanced → Chipset → Trusted Computing | Enabled | `dmesg |
| SRTM（Static Root of Trust for Measurement）激活 | Security → Secure Boot → Platform Key (PK) Management | PK已安装且状态为Valid | sudo tpm2_getcap properties_fixed | grep -A5 "TPM2_PT_FIXED"中TPM2_PT_FIXED.TPM2_PT_FIRMWARE_VERSION_1值应非零 |
| LPC总线DMA保护 | Advanced → Device Configuration → LPC Device Control | DMA Protection = Enabled | cat /sys/firmware/acpi/table/*/LPC* 2>/dev/null | hexdump -C | head -10中应包含0x00000001标志位 |
若任一配置缺失，tpm2_pcrread命令将返回Error: Failed to connect to TPM或读取到全零PCR值，此时所有上层度量均无意义。
2.3 避坑：TCM初始化失败的三个血泪现场
现象1：系统启动后dmesg显示TCM: failed to initialize, error -19
→ 原因：BIOS中LPC总线被禁用或DMA保护未开启，导致内核无法通过LPC访问TCM寄存器。
→ 解决：进入BIOS，确认LPC Controller设为Enabled，LPC DMA Protection设为Enabled，保存重启。
现象2：tpm2_pcrread sha256:0返回0000000000000000000000000000000000000000000000000000000000000000
→ 原因：SRTM未激活，TCM未参与启动度量，PCR0始终为初始值。
→ 解决：在BIOS中清除所有Secure Boot密钥（Clear Keys），重新导入Platform Key（PK）和Key Exchange Key（KEK），确保Secure Boot状态为Enabled且PK Status为Valid。
现象3：应用层调用tpm2_quote时返回Error: Invalid parameter passed to TPM
→ 原因：TCM芯片固件版本过低（< 2.0），不支持可信计算3.0要求的TPM2_CC_Quote扩展命令。
→ 解决：联系硬件供应商升级TCM固件，或更换为标称支持TCM 2.0+的模块（如某国产TCM芯片需固件版本≥V2.1.3）。
3. 静态度量与动态度量的协同：为什么“只测启动不测运行”等于没测，以及如何用IMA-EVM实现业务进程级可信
可信计算3.0的“3.0”之名，核心在于将信任链从静态启动过程延伸至动态运行时。静态度量（SRTM/DRTM）解决“系统是否按预期启动”，而动态度量（IMA/EVM）解决“启动后的每个进程、每份配置、每次文件读写是否被篡改”。二者割裂部署，将导致信任链在内核加载完成后即告断裂。
3.1 IMA策略配置：从“全盘度量”到“精准打击”的四步收敛法
默认IMA策略（security=imaboot）会度量所有可执行文件，导致系统日志爆炸式增长且无实际防护价值。生产环境必须定制策略，遵循“先宽后严”原则：
# 步骤1：启用IMA并记录所有度量（不拒绝） echo 'ima_tcb' > /sys/kernel/security/ima/policy # 步骤2：收集72小时真实业务文件访问日志 dmesg | grep -i "ima:" > /tmp/ima_boot.log find /usr/bin /usr/lib/systemd /etc -type f -name "*.conf" -o -name "*.service" | xargs ls -l > /tmp/ima_baseline.txt # 步骤3：基于日志生成最小必要策略（关键：只度量启动链+配置文件+核心二进制） echo "measure func=FILE_CHECK mask=MAY_READ uid=0" > /etc/ima/ima-policy echo "measure func=MODULE_CHECK" >> /etc/ima/ima-policy echo "measure func=FIRMWARE_CHECK" >> /etc/ima/ima-policy echo "appraise func=FILE_CHECK mask=MAY_READ uid=0 appraise_type=imasig" >> /etc/ima/ima-policy # 步骤4：持久化并重启生效 cp /etc/ima/ima-policy /sys/kernel/security/ima/policy逻辑说明：
func=FILE_CHECK mask=MAY_READ uid=0表示仅度量root用户读取的文件，避免普通用户临时文件污染PCR；appraise_type=imasig要求被度量文件必须带有IMA签名，否则open()系统调用将返回EACCES。参数uid=0是精度控制的关键，漏掉此参数将导致所有用户文件被度量，PCR溢出。
3.2 EVM（Extended Verification Module）：让IMA度量结果真正“可用”的最后一环
IMA仅生成度量值（hash），但无法验证该hash是否被篡改。EVM通过数字签名将度量值与文件inode元数据绑定，形成防抵赖证据。其部署有三个不可跳过的步骤：
- 内核编译启用EVM：配置
CONFIG_EVM=y、CONFIG_EVM_ATTR_FSUUID=y，并确保CONFIG_INTEGRITY_ASYMMETRIC_KEYS=y； - 生成并导入EVM密钥：
# 生成密钥对（私钥绝不导出！） openssl genpkey -algorithm rsa -out /etc/keys/evm-key.pem -pkeyopt rsa_keygen_bits:2048 # 导入公钥到内核密钥环 keyctl padd asymmetric evm-key: %keyring:.evm < /etc/keys/evm-key.pub - 为关键文件打EVM签名：
# 对systemd服务文件签名（-f参数指定签名存储位置） evmctl sign -f /usr/lib/systemd/system/sshd.service # 签名后文件扩展属性中将新增security.evm字段 getfattr -n security.evm /usr/lib/systemd/system/sshd.service
若跳过第2步密钥导入，evmctl sign将报错Failed to add key to keyring；若跳过第3步签名，EVM校验将始终失败，导致sshd等服务无法启动。
3.3 避坑：IMA-EVM联调失败的四个高频雷区
现象1：systemctl start sshd报错Failed to start sshd.service: Permission denied
→ 原因：EVM签名未覆盖/usr/lib/systemd/system/sshd.service的完整内容（如编辑后未重签），或签名密钥未正确导入内核密钥环。
→ 解决：执行evmctl verify -f /usr/lib/systemd/system/sshd.service检查签名有效性；用keyctl show %keyring:.evm确认密钥存在。
现象2：dmesg | grep -i ima持续刷屏IMA: policy update failed
→ 原因：自定义IMA策略语法错误（如多写了空格、引号不匹配），或策略文件权限非600。
→ 解决：用ima-evm-utils包中的ima_policy_check工具校验策略语法；执行chmod 600 /etc/ima/ima-policy。
现象3：tpm2_pcrread sha256:10显示PCR10值频繁变动，但业务无更新
→ 原因：IMA策略中func=FILE_CHECK未限定uid，导致普通用户临时文件（如/tmp/xxx）被度量，每次创建新文件即触发PCR更新。
→ 解决：严格限定uid=0，并移除mask=MAY_READ外的其他mask（如MAY_WRITE会引发更频繁更新）。
现象4：EVM签名后lsattr显示文件为----e-------e----，但getfattr -n security.evm返回No such attribute
→ 原因：文件系统未启用user_xattr和security_inode_init_security挂载选项。
→ 解决：编辑/etc/fstab，为根分区添加defaults,user_xattr,security_inode_init_security选项，然后mount -o remount /。
4. 业务代码接入可信链：不是调API，而是重构“信任决策点”的三个落地模式
可信计算3.0的价值最终要体现在业务逻辑中。常见误区是把“调用tpm2_quote生成证明”当作接入完成，实则这只是技术动作。真正的接入，是让业务代码在关键决策点（如用户登录、配置下发、数据导出）主动查询并验证信任状态，将“是否可信”转化为“是否放行”。
4.1 模式一：启动时可信验证（适用于嵌入式设备固件）
在设备启动早期（init进程前），通过tpm2_pcrread读取PCR7（Secure Boot状态）、PCR8（IMA度量摘要），并与预置的黄金值比对。此模式要求固件具备TPM访问能力：
// C语言伪代码：嵌入式bootloader中验证PCR #include <tpm2.h> uint8_t pcr7_value[SHA256_DIGEST_SIZE]; uint8_t golden_pcr7[] = {0x1a,0x2b,0x3c,...}; // 预置黄金值 if (tpm2_pcr_read(TPM2_ALG_SHA256, 7, pcr7_value) != TPM2_RC_SUCCESS) { log_error("TPM read PCR7 failed"); halt_device(); // 硬件级停机 } if (memcmp(pcr7_value, golden_pcr7, SHA256_DIGEST_SIZE) != 0) { log_alert("PCR7 mismatch! Secure Boot tampered."); halt_device(); }参数说明：
TPM2_ALG_SHA256必须与TCM实际使用的哈希算法一致（国产TCM默认为SM3，需确认固件是否启用SM3模式）；halt_device()是硬件级熔断，不可被软件绕过。此模式下，黄金值必须在设备出厂时写入OTP区域，且写入后锁定。
4.2 模式二：运行时远程证明（适用于云平台租户验证）
当云租户需要向监管方证明其虚拟机环境可信时，需调用TPM2.0的Quote命令生成带签名的PCR摘要，并由第三方CA验证签名。关键不在生成，而在证明密钥（AK）的生命周期管理：
# 1. 创建证明密钥（AK），注意：-G参数必须为rsa，-g必须为sha256 tpm2_createak -C primary.ctx -c ak.ctx -G rsa -g sha256 -s rsassa -u ak.pub -r ak.priv # 2. 生成Quote（-q参数为nonce，防止重放） tpm2_quote -c ak.ctx -l "sha256:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23" -q "deadbeef" -m quote.msg -s quote.sig -o quote.pcr # 3. 将quote.msg、quote.sig、quote.pcr、ak.pub打包发送给验证方逻辑说明：
-l参数指定要度量的PCR列表，必须包含PCR0-PCR7（启动链）和PCR10（IMA度量）；-q的nonce必须为随机值，长度32字节，验证方需原样返回以证明实时性。若省略-q，攻击者可重放旧证明。
4.3 模式三：配置文件可信加载（适用于金融交易系统）
交易系统核心配置（如路由规则、限额参数）必须确保未被篡改。传统做法是校验MD5，但MD5可被碰撞。可信计算3.0方案是：将配置文件的SM3哈希值写入TCM的NV索引，加载时读取并比对：
# Python示例：交易网关配置加载 import tpm2_pytss from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.serialization import load_pem_public_key def load_trusted_config(config_path): # 步骤1：计算配置文件SM3哈希（使用国密库） sm3_hash = sm3_hash_file(config_path) # 自定义函数，调用国密SM3实现 # 步骤2：从TCM NV索引读取预置哈希（索引0x01500000为用户定义区） tpm = tpm2_pytss.TPM2() nv_data = tpm.nv_read(0x01500000, len(sm3_hash)) # 步骤3：比对，不一致则拒绝加载并告警 if nv_data != sm3_hash: alert_admin(f"Config {config_path} tampered! Expected {nv_data.hex()}, got {sm3_hash.hex()}") raise RuntimeError("Trusted config verification failed") return parse_config(config_path) # 安全解析 # 预置哈希到NV索引（运维脚本，仅授权人员执行） tpm2_nvdefine -x 0x01500000 -a 0x400000 -s 32 -t 0x0002000b tpm2_nvwrite -x 0x01500000 -f /tmp/config_sm3.hash参数说明：
0x01500000是TCM规范定义的用户NV索引起始地址；-a 0x400000表示该索引具有TPM2_NT_ORDINARY属性（可读写）；-s 32指定大小为32字节（SM3输出长度）；-t 0x0002000b设置为TPM2_RH_OWNER所有者权限。此模式下，NV索引写入操作必须在安全运维通道中执行，且写入后应调用tpm2_nvreadlock锁定索引。
4.4 避坑：业务接入可信链的三个反模式
反模式1：“一次Quote，全程信任”
→ 问题：在服务启动时生成一次Quote，后续所有请求都复用该证明。攻击者可在Quote生成后注入恶意代码，而证明仍有效。
→ 正解：对每个敏感操作（如大额转账）单独生成Quote，并在Quote中嵌入操作唯一标识（如交易流水号）作为nonce。
反模式2：“只验PCR，不验签名”
→ 问题：业务代码仅比对PCR值，但未验证Quote签名是否由合法AK签发，导致攻击者可伪造PCR值。
→ 正解：必须使用CA颁发的AK证书链验证Quote签名，验证逻辑需包含证书吊销检查（OCSP）。
反模式3：“黄金值硬编码在代码中”
→ 问题：将PCR黄金值写死在业务代码里，一旦固件升级导致PCR变化，服务即崩溃。
→ 正解：黄金值应存储在TCM的NV索引中，由固件在升级时自动更新；业务代码只读取NV索引，不关心具体值。
5. 策略引擎与日志归档：让可信证据链真正“可审计、可追溯、不可抵赖”的工程实践
可信计算3.0的终极价值，不在于技术本身有多先进，而在于能否生成一份监管机构认可的、具备法律效力的证据链。这要求两个关键能力：一是策略引擎能根据实时度量状态动态调整访问控制，二是所有度量日志必须以可信方式归档，防止被删除或篡改。
5.1 基于TPM的策略引擎：用PCR状态驱动访问控制的最小实现
传统ACL（访问控制列表）基于用户身份，而可信策略引擎基于系统完整性状态。例如：只有当PCR7（Secure Boot）和PCR10（IMA）同时符合预期时，才允许数据库备份任务执行：
# 创建策略脚本 /usr/local/bin/check_trust_policy.sh #!/bin/bash # 读取PCR7和PCR10 pcr7=$(tpm2_pcrread sha256:7 | awk '{print $NF}') pcr10=$(tpm2_pcrread sha256:10 | awk '{print $NF}') # 比对黄金值（从NV索引读取，此处简化为文件） golden_pcr7=$(cat /etc/trust/golden_pcr7) golden_pcr10=$(cat /etc/trust/golden_pcr10) if [[ "$pcr7" == "$golden_pcr7" ]] && [[ "$pcr10" == "$golden_pcr10" ]]; then echo "TRUSTED" > /tmp/trust_status exit 0 else echo "UNTRUSTED" > /tmp/trust_status exit 1 fi# 在crontab中调用（每5分钟检查一次） */5 * * * * /usr/local/bin/check_trust_policy.sh && /usr/local/bin/backup_db.sh || logger "Trust check failed, backup skipped"逻辑说明：此脚本将“系统是否可信”转化为一个文件状态（
/tmp/trust_status），后续所有业务脚本均可通过test -f /tmp/trust_status && grep -q TRUSTED /tmp/trust_status判断。关键点在于：tpm2_pcrread必须在每次检查时实时执行，不能缓存结果；黄金值文件/etc/trust/golden_pcr7应由运维人员在系统基线确认后手动写入，且权限设为600。
5.2 可信日志归档：用TCM密封（Seal）实现日志的“时间锁”
普通日志可被rm -rf删除，而可信日志必须与特定PCR状态绑定。TCM的Seal命令可将日志加密后绑定到当前PCR值，只有当PCR恢复到密封时的状态，才能解密：
# 步骤1：将当日日志压缩并密封到PCR0-PCR7（启动链状态） tar -czf /var/log/syslog-$(date +%Y%m%d).tar.gz /var/log/syslog* tpm2_seal -c primary.ctx -i /var/log/syslog-$(date +%Y%m%d).tar.gz -p "pcr:sha256:0,1,2,3,4,5,6,7" -o /var/log/sealed/$(date +%Y%m%d).sealed # 步骤2：归档密封文件到离线存储（如只读USB） cp /var/log/sealed/$(date +%Y%m%d).sealed /mnt/readonly_usb/ # 步骤3：每日清理原始日志（仅保留密封副本） rm -f /var/log/syslog*参数说明：
-p "pcr:sha256:0,1,2,3,4,5,6,7"表示密封密钥受PCR0-PCR7共同保护，任何一项PCR值改变（如BIOS升级、内核更新），tpm2_unseal都将失败；-o指定输出密封文件路径。此方案下，即使攻击者获得root权限，也无法解密历史日志，因为TCM不会在PCR被篡改时解密。
5.3 避坑：策略与日志落地的三个致命疏忽
疏忽1：策略脚本未设置执行权限且未加入PATH
→ 现象：crontab执行时报错/bin/sh: check_trust_policy.sh: not found。
→ 原因：脚本未chmod +x，且crontab默认PATH不包含/usr/local/bin。
→ 解决：chmod +x /usr/local/bin/check_trust_policy.sh；在crontab中用绝对路径调用，或在脚本开头添加PATH=/usr/local/bin:/usr/bin:/bin。
疏忽2：密封日志时未指定PCR策略，导致“永远无法解密”
→ 现象：系统升级后执行tpm2_unseal返回TPM2_RC_POLICY_FAIL。
→ 原因：密封时未加-p参数，导致密钥仅受TPM所有权保护，而TCM所有权在升级后可能重置。
→ 解决：密封命令必须包含-p参数，且PCR列表应选择稳定不变的启动链PCR（0-7），避免使用PCR10（IMA）等易变PCR。
疏忽3：日志归档路径未做磁盘配额限制
→ 现象：/var/log/sealed/目录占满根分区，导致系统无法写入新日志。
→ 解决：为/var/log/sealed/挂载独立分区，或在/etc/fstab中为/var/log添加size=2G配额（/dev/sda1 /var/log ext4 defaults,size=2G 0 0）。
6. 验证你的可信链是否真正闭环：用“三阶验证法”揪出90%的隐形断点
我见过太多项目，在演示时tpm2_pcrread输出漂亮的一串哈希值，评审专家点头通过，结果上线三个月后被攻破。问题往往不出在TPM本身，而出在“信任链的隐性断点”——那些你以为自动连通、实则需要手工缝合的环节。我给自己定了一条铁律：任何可信计算3.0部署，上线前必须通过“三阶验证法”，少一阶都不算闭环。
6.1 第一阶：启动链验证（验证SRTM是否真生效）
目标：确认从BootROM到内核的每一跳都被TCM度量，且PCR值与理论基线一致。
方法：在系统启动后立即执行：
# 读取所有启动相关PCR（0-7） for i in {0..7}; do echo "PCR$i:"; tpm2_pcrread sha256:$i | tail -1 done > /tmp/pcr_boot_baseline.txt # 与黄金基线比对（黄金基线需在纯净环境生成） diff /tmp/pcr_boot_baseline.txt /etc/trust/golden_pcr_boot.txt关键点：必须在系统启动后10秒内执行，避免后台服务干扰PCR；黄金基线必须在相同硬件、相同固件版本、相同Secure Boot密钥下生成。若
diff有输出，说明启动链某环节未被度量（如BIOS中CSM兼容模式开启会绕过SRTM）。
6.2 第二阶：运行时验证（验证IMA-EVM是否真拦截）
目标：确认恶意文件修改会被EVM实时阻止，而非仅记录日志。
方法：构造一个受EVM保护的文件（如/etc/ssh/sshd_config），然后尝试篡改：
# 1. 确认文件已签名 getfattr -n security.evm /etc/ssh/sshd_config 2>/dev/null && echo "EVM signed" || echo "Not signed" # 2. 尝试追加一行（应失败） echo "# MALICIOUS" >> /etc/ssh/sshd_config 2>/dev/null || echo "EVM blocked write!" # 3. 尝试用vi编辑（应失败） vi /etc/ssh/sshd_config # 此时vi应报错"EACCES"并退出关键点：测试必须用
>>和vi两种方式，因为>>触发open(O_WRONLY)，vi触发open(O_RDWR)，EVM策略可能对不同mode有不同处理。若任一方式成功，说明EVM未生效或策略配置错误。
6.3 第三阶：证据链验证（验证日志是否真不可篡改）
目标：确认密封日志在系统被攻陷后仍能解密，且解密结果与原始日志一致。
方法：在测试环境模拟攻陷（如rm -rf /var/log/*），然后尝试解密归档：
# 1. 找到最近的密封日志 sealed_file=$(ls -t /var/log/sealed/*.sealed | head -1) # 2. 尝试解密（此时系统PCR已被破坏，应失败） tpm2_unseal -c $sealed_file 2>/dev/null || echo "UNSEAL FAILED as expected" # 3. 重置TCM到基线状态（需物理重启并确保BIOS设置未变） reboot # 4. 重启后立即解密验证 tpm2_unseal -c $sealed_file > /tmp/unsealed.tar.gz tar -tzf /tmp/unsealed.tar.gz | head -5 # 检查是否为原始日志结构关键点：第三步的
reboot必须是硬重启（断电），不能软重启，因为软重启可能不重置TCM内部状态；解密后必须用tar -tzf检查归档内容，而非只看命令是否成功，因为tpm2_unseal成功只代表解密密钥获取成功，不代表解密数据有效。
这三阶验证，我坚持做了五年，每一次都揪出至少一个之前被忽略的断点。最深的教训是：可信计算3.0不是部署一个技术，而是建立一套验证习惯。当你不再问“TPM有没有启用”，而是问“PCR7的值今天和昨天一样吗？不一样的话，哪里变了？”，你就真正进入了可信计算3.0的世界。希望帮到你。
本文还有配套的精品资源，点击获取
