用户如何自证中转没有偷换

原理 · 三拍讲完

原理不复杂：在中转出口放一个中转方改不动、也伪造不了的硬件“见证人”，让它亲自跟官方对接、再签字证明“这段响应是从官方原样取回、没被改过的”。

问题

你用中转站调 OpenAI。运营方掌握服务器，他能偷换成便宜模型、能改你拿到的答案、能在转发途中动手脚。你怎么知道他没干？以前——只能信他这个人。

办法 · 一句话

在出口放一个硬件“见证人”（TEE）。它亲自跟官方建立加密连接、原样取回响应，再给每条响应签字。而它的厂商（AWS）出具一张硬件签名的“身份证明”，上面写两件事：① 这见证人跑的是哪段代码（PCR0 指纹）；② 它这次开机随机生成的签名公钥。于是你不再信运营方，只需核三件事：

代码指纹 == 公开审计源码（而源码写死“只调官方、原样转发”）→ 见证人不会偷换、乱改

响应签名能用身份证明里那把公钥验通过 → 这段响应确实出自见证人之手、一字未改

身份证明本身链到 AWS 根 → 这见证人是真 AWS 硬件，冒充不了

焊点 · 为什么绕不过去

关键一步：那把签名公钥，是和代码指纹一起被写进身份证明、由 AWS 签的。于是“见证人是诚实的（代码可审计）”和“这把钥属于那个诚实见证人”焊成一条链——运营方想自造一把钥、签段假响应冒充见证人？那把钥不在任何 AWS 身份证明里，你根本不认。

见证人靠两个独立的支柱，缺一不可

支柱 A · 签名

证明「这次交换没被改」

TEE 用内部私钥签一份字段分解声明：上游域名 / 路径 / 方法 / 状态 + 请求体哈希 + 响应体哈希

验签通过 = 这条响应、连同它声称调的上游，一字未改、全出自 TEE

证明不了：「声称调的上游」是否属实——那只是 TEE 的自述，可信全靠支柱 B 背书

支柱 B · 远程证明

证明「跑的是哪段代码」

CPU 出具报告：受保护区内代码哈希 = PCR0，由 TEE (AWS) 签名

用户对比 PCR0 = 自己复现构建审计源码得到的度量值，而源码写死「只调官方」

证明不了：这个响应是不是真走了这个 TEE——靠支柱 A 背书

↑ 扣合点：支柱 A 的签名公钥，被塞进支柱 B 的证明报告里一起被 TEE (AWS) 签名 → 两条链焊成一条

攻击模拟器 · 你来当恶意运营方

点左边的攻击按钮，看右边用户的验证会不会当场识破。

😈 你的攻击手段

你控制中转服务器和部署，想偷工减料

▼ 左道 = 请求下行　　▲ 右道 = 响应上行

用户

发出请求，最后用公钥验证收到的东西

公网

中转服务器（不可信）

只搬运密文 9f2a··c4，看不懂、改不了

vsock

TEE 已远程证明

运行代码 PCR0 = a3f9·71e0·审计源码
出口动作 = 调 api.openai.com → 签名

TLS

api.openai.com

官方模型，正品响应

🔍 用户端验证

收到响应+签名+证明后自动跑三步

B远程证明 · 对 PCR0

PCR0 = 审计哈希 ✓

A签名 · 验完整性

签名与数据一致 ✓

🔒TLS · 在 TEE 内终结

官方证书校验通过 ✓

✅ 不是黑箱 · 可信

老实运营：三道检查全过。你这个人无需被信任——信任降到 TEE (AWS) 硬件 + 可复现的公开代码，其余全是密码学推导出来的。

用户中转服务器（不可信，可捣乱但偷不了换不了） TEE（可信，已证明） OpenAI

用户端到底验了哪三步

验证明报告的签名 → 一路链到 TEE (AWS Nitro) 根证书（公开），确认「这是一个真 TEE」。

比对 PCR0 → 等于自己复现构建审计源码得到的度量值，确认「里面跑的是会调官方的那段代码」。

用报告里的公钥验响应签名 → 确认「这段响应确实出自那个 TEE、传输途中没被改」。

↑ 第 2 步成立有个一次性前提：用户得能把公开源码复现构建出同一个 PCR0——这是「PCR0 ↔ 审计源码」之间唯一的桥。否则 PCR0 只是个对不上任何东西的哈希。这一步与请求无关，验一次即可，做法见 tee-reproducible-build.md。

两个必须认的硬限制（不夸大）

信任根落在 TEE (AWS)

证明报告由 TEE (AWS) 签发。这不是区块链那种纯数学，而是「信任 TEE (AWS) 这家厂 + 没有 TEE 漏洞」。它把信任从「运营方」搬到了「芯片/云厂商」，没有彻底消灭信任。

OpenAI 端只能「观测」

OpenAI 不对自己的响应签名。所以「官方真的诚实产出」这件事，最强只能到「TEE 通过真 TLS 观测到了它」，到不了纯数学证明。这是此路线的天花板。