一、远程证明概述：信任的起点

各位同学，咱们今天聊远程证明。说实话，这个名词听起来挺唬人的。我第一次接触它是在做机密计算项目的时候，当时客户问了一句：“我怎么知道你的代码真的跑在TEE里，而不是被篡改过？”嗯，这个问题，就是远程证明要解决的核心。

1.1 什么是远程证明

远程证明，说白了就是让一台机器向另一台机器证明“我是我，我没被篡改”。你想想看，在分布式系统里，A机器要信任B机器，不能光靠B说一句“我很好”吧？总得拿出点证据来。

这个证据，通常是一组度量值（Measurements）。比如：

• BIOS的哈希值
• 操作系统内核的哈希值
• 关键配置文件的哈希值
• 应用程序代码的哈希值

这些值被安全硬件（TPM或TEE）记录下来，然后签名，生成一份证明报告（Attestation Report）。远程的验证方拿到报告，检查签名是否可信、度量值是否符合预期，就能判断对方是否处于可信状态。

1.2 为什么需要远程证明

我遇到过不少团队，一开始觉得“我们内网环境很安全，不需要这玩意儿”。结果呢？有一次某公司的机密计算节点被攻破，攻击者替换了TEE里的代码，但系统日志显示一切正常——因为没有远程证明，谁都不知道代码已经被换了。

远程证明的必要性，主要体现在三个场景：

场景	没有远程证明的风险	有了远程证明的效果
机密计算	TEE内代码被篡改，数据泄露	每次运行前验证代码完整性
零信任网络	设备被植入后门，横向移动	设备接入前必须通过证明
供应链安全	固件被替换，硬件被篡改	从启动链开始逐级验证

你想想看，如果没有远程证明，机密计算就变成了“黑盒计算”——你只知道数据进去了，结果出来了，但中间发生了什么，你完全不知道。这跟把数据交给一个陌生人有什么区别？

1.3 远程证明的信任根：TPM vs TEE

远程证明不能凭空产生信任，它需要一个信任根（Root of Trust）。目前主流的有两种：TPM和TEE。我分别说说我的理解。

1.3.1 TPM（可信平台模块）

TPM是一个独立的硬件芯片，焊在主板上。它的核心能力是：

• 安全存储：私钥永远不出芯片
• 平台配置寄存器（PCR）：记录启动链的度量值
• 远程证明：用AIK（Attestation Identity Key）签名PCR值

TPM的证明流程，我习惯叫它“启动链证明”：从BIOS开始，逐级度量Bootloader、OS内核、驱动，最后到应用。每一级的度量值都扩展到PCR里，最终形成一个完整的信任链。

1.3.2 TEE（可信执行环境）

TEE是CPU内部的一个安全区域，比如Intel SGX、AMD SEV、ARM TrustZone。它的思路不一样：不是证明整个系统，而是证明一个特定的安全飞地（Enclave）。

TEE的证明流程更灵活：

• Enclave在加载时，CPU会计算它的度量值（MRENCLAVE）
• Enclave可以生成一个证明报告，包含度量值和自定义数据
• 报告由CPU的硬件密钥签名，远程验证方可以验证

1.4 远程证明的典型应用场景

聊完理论，咱们看看实际怎么用。我挑两个最典型的场景说说。

1.4.1 零信任架构

零信任的核心原则是“永不信任，始终验证”。远程证明就是验证的手段之一。

举个例子：某公司的办公网络，员工设备要接入内部系统。传统做法是“设备在域内就信任”，但零信任要求：

1. 设备启动时，TPM记录PCR值
2. 设备接入网络前，向验证服务器发送证明报告
3. 验证服务器检查PCR值是否匹配“干净系统”的基线
4. 匹配才允许接入，不匹配就隔离

我曾经帮一家金融客户做过类似的方案。他们之前被勒索软件搞怕了，后来强制所有终端设备必须通过TPM远程证明才能访问核心系统。效果很明显——有一次某台设备被植入了挖矿程序，PCR值变了，直接就被拦在了网络外面。

1.4.2 机密计算

机密计算是远程证明最典型的应用。数据在TEE里处理，但用户怎么知道TEE里的代码是可信的？

流程大概是这样的：

1. 用户向TEE发起证明请求
2. TEE生成证明报告，包含代码度量值和公钥
3. 用户验证报告签名，确认代码未被篡改
4. 用户用报告中的公钥加密数据，发送给TEE
5. TEE解密数据，在安全环境中处理

你看，没有远程证明，用户根本不敢把数据交给TEE。这就是为什么我说远程证明是机密计算的“入场券”。

1.5 本章知识体系总览

为了让你更直观地理解远程证明的整体结构，我画了一张图。这张图涵盖了信任根、证明流程和典型场景，后面每一章都会围绕这个框架展开。

这张图把远程证明分成了三层：信任根层提供硬件级的安全基础，证明流程层定义了具体的交互步骤，应用场景层展示了实际落地方向。后面29章，我们会一层一层地拆开来讲。