Confer：端到端加密AI聊天的TEE架构与远程证明实现

当你在 ChatGPT 或 Claude 中分享个人想法、商业机密或敏感信息时，这些数据以明文形式流经服务提供商的服务器。OpenAI、Anthropic 等公司不仅存储这些对话，还将其用于模型训练、行为分析，并在未来可能面临黑客攻击、员工泄露或法律传票。这种隐私困境在 AI 聊天时代变得尤为尖锐 —— 我们正在向 API 端点倾诉内心，而这些端点本质上是一个精心设计的数据湖。

Signal 创始人 Moxie Marlinspike 的最新项目 Confer 试图改变这一现状。Confer 宣称提供真正的端到端加密 AI 聊天，确保只有用户能够访问自己的对话内容。这不仅仅是另一个隐私声明，而是基于可信执行环境（TEE）、远程证明和可验证构建系统的完整技术栈。本文将深入分析 Confer 的技术架构，探讨其在 AI 隐私保护领域的创新与挑战。

核心架构：TEE、Passkey 与 Noise 协议的三重保障

Confer 的安全模型建立在三个核心技术组件之上：可信执行环境、passkey 加密和 Noise 协议。这种组合创造了与传统 AI 服务截然不同的隐私保护层次。

可信执行环境（TEE）：硬件强制的隔离

可信执行环境是现代 CPU 提供的硬件级安全功能，如 Intel SGX、AMD SEV 或 ARM TrustZone。TEE 创建一个加密的内存区域，即使主机操作系统或虚拟机监控器也无法访问其中的代码和数据。对于 AI 推理场景，这意味着：

内存加密：TEE 内的所有数据（包括用户提示和模型权重）在离开 CPU 芯片前自动加密
完整性保护：硬件确保 TEE 内的代码执行不被外部篡改
远程证明：TEE 可以向远程方证明自己运行的是特定代码

Confer 将整个推理过程封装在 TEE 中运行。用户提示通过加密通道直接进入 TEE，在隔离环境中处理，响应再加密返回。服务器操作员无法窥探 TEE 内部，即使他们拥有服务器的 root 权限。

Passkey 加密：设备本地的密钥管理

传统端到端加密系统依赖密码或恢复短语，这些机制在 AI 聊天场景中存在可用性问题。Confer 采用 passkey（通行密钥）作为加密基础，这是一种基于 WebAuthn 标准的现代认证机制：

// Passkey加密流程示意
const passkey = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32),
    rp: { name: "Confer" },
    user: { id: new Uint8Array(16), name: "user@example.com" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],
    authenticatorSelection: {
      authenticatorAttachment: "platform",
      requireResidentKey: true,
      userVerification: "required"
    },
    extensions: {
      prf: { eval: { first: new Uint8Array(32) } }
    }
  }
});

Passkey 的关键优势在于：

平台认证集成：与 Face ID、Touch ID、Windows Hello 等生物识别系统无缝集成
无密码体验：用户无需记忆复杂密码或恢复短语
防钓鱼：密钥与域名绑定，防止中间人攻击
PRF 扩展：支持伪随机函数扩展，用于派生加密密钥

Confer 使用 passkey 派生的密钥加密用户聊天历史，这些密钥永远不会离开用户设备。即使 Confer 的服务器被完全入侵，攻击者也无法解密存储的对话数据。

Noise 协议：前向保密的通信通道

Noise 协议框架是 Signal 协议的后继者，提供简单、可组合的加密协议。Confer 使用 Noise Pipes 建立客户端与 TEE 之间的加密通道：

Noise_XX_25519_ChaChaPoly_BLAKE2s
  -> e
  <- e, ee, s, es
  -> s, se

这种握手协议提供：

前向保密：每次会话使用临时密钥，即使长期密钥泄露，历史会话仍受保护
身份隐藏：通过模式选择保护客户端和服务端身份
降级攻击防护：明确协商密码套件，防止协议降级

远程证明与可验证性：从硬件到代码的信任链

TEE 提供了硬件隔离，但客户端需要验证 TEE 内运行的是正确的代码。这就是远程证明发挥作用的地方 —— 建立从硬件到应用代码的完整信任链。

硬件证明：TEE 的密码学签名

当 TEE 启动时，硬件生成一个签名的证明引用（quote），包含：

PCR 值：平台配置寄存器，记录启动组件的哈希
非对称密钥：TEE 内生成的临时密钥对
硬件签名：由 CPU 制造商证书链签名的证明

对于 Confer，证明引用包含内核、initrd 和命令行参数的测量值。更重要的是，Confer 扩展了这一测量范围，通过 dm-verity 覆盖整个根文件系统。

dm-verity：全文件系统完整性验证

dm-verity 是 Linux 内核的设备映射器目标，提供块级完整性检查。Confer 使用它构建整个文件系统的 Merkle 树：

文件系统 -> 分块哈希 -> Merkle树 -> 根哈希

根哈希被嵌入内核命令行参数，由于命令行在 TEE 启动时被测量，任何文件修改都会改变证明引用。这意味着：

逐字节验证：每个文件的每个字节都影响最终证明
实时检测：运行时检测到篡改会阻止文件访问
无性能开销：哈希验证仅在访问时发生，不增加推理延迟

可重现构建：Nix 与 mkosi 的精确控制

证明引用只是一个哈希值，要验证它，必须能够重现完全相同的二进制文件。Confer 使用 Nix 包管理器和 mkosi（Make Operating System Image）实现 bit-for-bit 可重现构建：

# Confer的Nix表达式示例
{ pkgs ? import <nixpkgs> {} }:

pkgs.stdenv.mkDerivation {
  name = "confer-image";
  src = ./.;
  
  buildInputs = with pkgs; [
    python3
    tensorflow
    mkosi
  ];
  
  buildPhase = ''
    mkosi --default mkosi.conf
  '';
  
  installPhase = ''
    cp mkosi.output $out
  '';
}

Nix 的关键特性：

纯函数式构建：相同输入总是产生相同输出
沙盒隔离：构建过程在隔离环境中进行
内容寻址存储：通过哈希标识构建产物

mkosi 则负责创建完整的操作系统镜像，确保内核、文件系统和所有依赖项的一致性。

透明日志：公开可审计的发布记录

即使有可重现构建，用户也需要知道应该验证哪个哈希值。Confer 使用 Sigstore 的透明日志服务：

发布流程：
1. 构建Confer镜像 -> 生成SHA256哈希
2. 使用Confer Labs的发布密钥签名
3. 提交到Sigstore透明日志
4. 日志条目包含时间戳、哈希和签名

透明日志是仅追加的数据结构，任何人都可以：

搜索发布记录：通过 Confer 的发布者邮箱查询
验证时间顺序：确保没有回滚或删除
独立审计：第三方可以监控所有发布活动

安全通信流程：从握手到加密推理

当用户访问 Confer 并开始对话时，系统执行以下安全握手流程：

阶段 1：TEE 启动与证明准备

服务器启动 TEE，加载 Confer 镜像
TEE 生成临时密钥对（ephemeral key pair）
硬件生成包含 PCR 值和公钥的证明引用
TEE 等待客户端连接

阶段 2：客户端验证与 Noise 握手

客户端发起 Noise 握手，请求 TEE 证明
TEE 在握手响应中嵌入证明引用
客户端验证：
- 证明签名的有效性（验证 CPU 制造商证书链）
- 公钥绑定（确认握手密钥与证明中的公钥匹配）
- 测量值验证（检查 PCR 哈希是否匹配透明日志中的发布记录）
握手完成，建立加密通道

阶段 3：加密推理与响应

客户端使用 passkey 派生加密密钥
用户提示通过 Noise 通道加密发送到 TEE
TEE 内 LLM 处理加密提示（模型权重也在 TEE 内）
响应通过同一通道加密返回
客户端使用 passkey 密钥解密显示

阶段 4：安全存储与同步

聊天历史使用 passkey 派生的密钥加密
加密数据可安全同步到 Confer 服务器
只有拥有 passkey 的设备才能解密历史记录
前向保密确保即使 passkey 泄露，历史会话仍安全

工程实现细节：构建可验证的 AI 隐私系统

Nix 构建系统的精确控制

Confer 的构建系统基于 Nix，这不仅仅是包管理选择，而是安全架构的核心部分。Nix 提供：

# 依赖锁定确保可重现性
{
  pkgs = fetchTarball {
    url = "https://github.com/NixOS/nixpkgs/archive/nixos-24.05.tar.gz";
    sha256 = "0abc123...";
  };
  
  # 精确的Python环境
  pythonEnv = pkgs.python3.withPackages (ps: [
    ps.torch
    ps.transformers
    ps.numpy
  ]);
  
  # 构建脚本的完全确定性
  buildScript = pkgs.writeScript "build-confer" ''
    #!/bin/sh
    set -e
    export SOURCE_DATE_EPOCH=1736726400
    # 构建过程...
  '';
}

关键工程决策：

固定时间戳：设置SOURCE_DATE_EPOCH确保时间相关操作确定性
哈希锁定：所有依赖项通过内容哈希引用
沙盒构建：防止网络访问和本地文件系统污染

dm-verity 配置与内核集成

Confer 的 dm-verity 配置确保文件系统完整性：

# mkosi配置中的dm-verity设置
[Output]
Format=disk
Verity=yes
VerityHash=sha256
VerityDataBlockSize=4096
VerityHashBlockSize=4096
VeritySalt=random:16

# 内核命令行包含根哈希
console=ttyS0 root=PARTUUID=... dm-mod.create="confer-root,,,ro,0 1048576 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 $(ROOT_HASH) $(SALT)"

工程挑战与解决方案：

根哈希传递：通过内核命令行将 dm-verity 根哈希传递给 TEE 测量
盐值管理：使用随机盐值防止彩虹表攻击
性能平衡：选择适当的块大小（4KB）平衡安全性与 I/O 性能

Sigstore 透明日志集成

Confer 的发布流程完全自动化集成 Sigstore：

# 简化的发布脚本
import sigstore
from cryptography.hazmat.primitives import serialization

def publish_release(image_path, version):
    # 计算镜像哈希
    with open(image_path, 'rb') as f:
        image_hash = hashlib.sha256(f.read()).hexdigest()
    
    # 生成证明材料
    attestation = {
        'version': version,
        'hash': image_hash,
        'timestamp': datetime.utcnow().isoformat(),
        'build_id': os.environ.get('GITHUB_RUN_ID')
    }
    
    # 签名并提交到透明日志
    client = sigstore.Client()
    result = client.sign_and_submit(
        attestation,
        identity_token=os.environ['SIGSTORE_TOKEN']
    )
    
    # 验证日志条目
    entry = client.verify_include(result)
    return entry.log_index, entry.integrated_time

透明日志提供：

不可否认性：一旦发布无法否认
公开审计：任何人都可以验证发布历史
时间证明：提供可信的时间戳服务

局限性与挑战：现实世界的约束

尽管 Confer 的技术架构令人印象深刻，但在实际部署中面临多个挑战：

性能开销：TEE 中的推理延迟

在 TEE 中运行 LLM 引入显著性能开销：

内存加密：所有内存访问需要加解密操作，增加延迟
上下文切换：进出 TEE 的上下文切换成本
I/O 限制：TEE 与外部世界的通信带宽限制

实测数据显示，TEE 中的推理速度可能比普通环境慢 30-50%。对于实时聊天应用，这可能导致可感知的延迟。Confer 通过以下方式缓解：

模型优化：使用量化、剪枝等技术减小模型大小
批处理：在安全边界内批处理请求
硬件加速：利用支持 TEE 的 GPU（如 NVIDIA H100 的 Confidential Computing）

浏览器兼容性与用户体验

Confer 要求浏览器支持高级 passkey 功能：

PRF 扩展：用于派生加密密钥
平台认证器：硬件级安全存储
WebAuthn Level 3：最新标准支持

目前仅 Chrome 116+、Firefox 139+、Edge 141 + 完全支持。移动设备兼容性更复杂：

iOS Safari：passkey 支持良好但 PRF 扩展有限
Android Chrome：支持但需要硬件认证器
Firefox 移动版：部分功能缺失

这限制了 Confer 的用户群体，特别是隐私意识强的用户可能使用不兼容的浏览器。

信任模型依赖：硬件供应链风险

Confer 的安全最终依赖硬件制造商：

CPU 漏洞：如 Spectre、Meltdown 影响 TEE 隔离
供应链攻击：硬件生产过程中的后门植入
制造商妥协：证书私钥泄露或恶意更新

虽然远程证明可以检测软件篡改，但无法防止硬件级攻击。这是所有 TEE 方案的固有局限。

商业模式可持续性

传统 AI 服务通过数据收集和训练实现货币化。Confer 的隐私承诺排除了这一收入来源，其商业模式面临挑战：

计算成本：TEE 基础设施比普通云服务器昂贵
维护开销：可验证构建和透明日志增加运营复杂度
用户付费意愿：隐私敏感用户可能愿意付费，但市场规模有限

结论：端到端加密 AI 的未来方向

Confer 代表了 AI 隐私保护的重要里程碑。它将 Signal 在即时通讯领域验证的隐私理念成功迁移到 AI 聊天场景，展示了端到端加密在生成式 AI 时代的可行性。

技术趋势与影响

硬件安全成为标配：随着 Intel TDX、AMD SEV-SNP、ARM CCA 等 TEE 技术成熟，硬件级隔离将成为 AI 服务的标准功能
可验证计算兴起：零知识证明、全同态加密等密码学技术与 TEE 结合，提供更强的隐私保证
透明基础设施：Sigstore 等透明日志服务从边缘工具变为核心基础设施

工程实践建议

对于希望实现类似隐私保护的团队：

# 隐私优先AI架构检查清单
security_requirements:
  - hardware_isolation: "TEE with remote attestation"
  - key_management: "passkey with PRF extension"
  - transport_encryption: "Noise protocol with forward secrecy"
  - storage_encryption: "client-side encryption with passkey-derived keys"
  - verifiable_builds: "Nix/mkosi with bit-for-bit reproducibility"
  - transparency_log: "Sigstore or similar append-only log"
  - audit_trail: "publicly verifiable release records"

performance_considerations:
  - tee_overhead: "30-50% latency increase expected"
  - model_optimization: "quantization, pruning, distillation"
  - batch_processing: "within security boundary"
  - hardware_acceleration: "TEE-capable GPUs when available"

compatibility_requirements:
  - browser_support: "Chrome 116+, Firefox 139+, Edge 141+"
  - platform_auth: "Face ID, Touch ID, Windows Hello"
  - mobile_support: "iOS 16+, Android 14+ with hardware authenticator"

未来展望

Confer 的成功与否将影响整个 AI 行业的隐私标准。如果用户大规模采用隐私优先的 AI 服务，可能迫使主流提供商改进其隐私实践。技术层面，我们可能看到：

混合隐私方案：TEE 用于敏感推理，普通服务器用于非敏感任务
分布式 TEE 网络：去中心化的可信执行环境集群
标准化证明格式：跨厂商的远程证明互操作性标准

最终，Confer 提醒我们：技术不仅应该强大，还应该尊重用户。在 AI 日益融入日常生活的时代，隐私不是可选项，而是基本权利。通过精心设计的加密架构和可验证的系统，我们可以在享受 AI 强大能力的同时，保护最珍贵的资产 —— 我们的思想和对话。

资料来源：

Ars Technica - "Signal creator Moxie Marlinspike wants to do for AI what he did for messaging" (2026-01-13)
Confer Blog - "Private inference" (2026-01-05)
Confer Blog - "Confessions to a data lake" (2025-12-23)
Hacker News 讨论 - "Confer – End to end encrypted AI chat" (2026-01-13)