📚 课程目录第3章信任根（RoT）

信任根（RoT）：设备可信的起点

聊远程证明，绕不开一个概念——信任根。说白了，它就是整个可信体系的「原点」。你想想看，如果连这个起点都不靠谱，后面所有的验证都是空中楼阁。

我在做可信计算项目时，客户最常问的就是：「我怎么知道我的设备一开始就是可信的？」嗯，答案就在信任根里。

硬件信任根，就是把信任建立在芯片物理结构上。最常见的就是 TPM（可信平台模块）和 TEE（可信执行环境）。

我个人习惯把硬件信任根比作「保险箱里的印章」。这个印章从出厂那一刻就刻好了，谁也没法改。任何想要篡改的行为，都得先物理破坏芯片——这成本，一般人扛不住。

核心特征：

我记得有一次帮客户选型，对方坚持用纯软件方案。我问他：「如果攻击者拿到了root权限，你的信任根还在吗？」他沉默了。后来还是老老实实加了硬件TPM。

软件信任根，不依赖专用硬件，而是通过密码学手段在启动过程中建立信任。比如UEFI Secure Boot、Linux的IMA（完整性度量架构）。

说白了，软件信任根就是「用代码验证代码」。启动时，前一段代码校验后一段代码的签名，通过才执行。一环扣一环。

注意：软件信任根有个天然弱点——如果攻击者能篡改最初始的那段代码，整个链条就崩了。我曾经在调试一个IoT设备时发现，厂商把签名公钥硬编码在固件里，但没做防读保护。攻击者直接dump固件，替换公钥，然后用自己的签名固件启动。嗯，这信任根等于白设。

所以我的建议是：能用硬件信任根就别只用软件。如果成本受限，至少保证初始代码存储在只读区域，并且签名验证逻辑足够健壮。

信任根只是起点。真正的挑战在于：如何让这份信任从启动一直延续到应用运行？这就是信任链要做的事。

信任链的传递过程，就像接力赛。每一棒（每一层代码）都要验证下一棒的身份和完整性。

你看，每一层都只信任上一层。只要有一环断了，整个信任链就失效。我在项目中见过最典型的翻车案例：Bootloader验证了内核签名，但内核加载驱动时没做校验。攻击者注入一个恶意驱动，直接绕过所有上层安全机制。

避坑指南：我曾经在嵌入式Linux项目里吃过这个亏。后来强制要求：所有内核模块必须签名，并且签名验证失败时直接拒绝加载，不能只打日志。记住，信任链的强度取决于最弱的一环。

远程证明的核心问题就一个：如何让远程的验证方相信，你的设备当前处于可信状态？

信任根在这里扮演三个关键角色：

提供不可伪造的身份：硬件信任根内置的唯一密钥对，相当于设备的「身份证」。这个私钥永远不出芯片，验证方用公钥验签即可确认设备身份。
保护度量数据：启动过程中，信任根会计算各层代码的哈希值，并安全存储（比如TPM的PCR寄存器）。远程证明时，把这些度量值签名后发给验证方。
保证证明过程的隔离性：证明协议的执行必须在信任根的保护下完成。我见过一个方案，证明逻辑跑在普通用户态，结果被恶意进程篡改了度量报告。嗯，这证明等于白做。

说白了，没有信任根，远程证明就是「贼喊捉贼」。你让一个可能已经被攻陷的设备来证明自己可信，这逻辑本身就站不住脚。

下面这张图展示了信任根在整个远程证明体系中的位置：

从这张图你能看到，信任根不是孤立存在的。它向下支撑身份、度量和证明执行三个核心能力，向上为远程证明协议提供可信基础。最终，验证方通过校验签名和度量值，判断设备是否可信。

总结一下：

我个人觉得，理解信任根是理解远程证明最关键的一步。后面章节我们会深入具体的证明协议和实现细节，但根基就在这里——没有信任根，一切都是空谈。