跳转到主要内容
Venice 提供运行在可信执行环境(TEE)中并支持端到端加密(E2EE)的隐私增强模型。这些模型为您的数据保密提供了密码学保证——即使是 Venice 也无法访问。

了解隐私级别

E2EE 模型在 TEE 保护之上加入了客户端加密。TEE 模型提供 enclave 安全性,无需客户端加密。

可用模型

Loading…
查看模型页面获取包含定价和上下文限制的完整列表。

TEE 模型

TEE 模型在硬件安全 enclave(Intel TDX、NVIDIA Confidential Computing)中运行。模型权重和您的数据受到保护,不会被主机系统访问——包括 Venice 的基础设施。

基础用法

TEE 模型的使用方式与常规模型完全相同:

验证 TEE 证明

您可以通过获取模型的证明报告,以密码学方式验证模型正在真实的 TEE 中运行:
证明响应包含:
在生产用途中,请在客户端通过解析 Intel TDX quote 并检查 NVIDIA 证明来验证证明。
对于纯 TEE 模型验证,signing_address 和服务端验证字段足以进行基础证明检查。当您需要客户端 E2EE 密钥协商和严格的密钥绑定检查时,需要 signing_key

响应签名

TEE 模型可以对其响应进行签名,证明输出来自被证明的 enclave:

E2EE 模型

E2EE 模型在 TEE 保护之上增加了客户端加密。您的 prompt 在离开设备之前被加密,只有 TEE 能够解密。 Venice E2EE 使用:
  • ECDH(椭圆曲线 Diffie-Hellman) 基于 secp256k1 进行密钥交换
  • HKDF-SHA256 用于密钥派生
  • AES-256-GCM 用于对称加密
  • TEE 证明用于验证模型运行在安全 enclave 中
E2EE 需要客户端实现。下面的示例展示了完整协议。

E2EE 的工作方式

1

生成临时密钥对

客户端为此会话生成 secp256k1 密钥对。
2

获取 TEE 证明

客户端请求 /api/v1/tee/attestation 并接收模型的公钥、证明证据和 nonce。
3

验证证明

客户端检查 nonce 匹配、debug 模式被禁用以及证明有效性。
4

加密消息

客户端使用 ECDH 共享秘密 → HKDF → AES-GCM 加密 prompt。
5

发送请求

客户端发送带 E2EE 头部(X-Venice-TEE-Client-Pub-KeyX-Venice-TEE-Model-Pub-KeyX-Venice-TEE-Signing-Algo)的请求。
6

TEE 处理

TEE 解密请求、处理它并加密响应。
7

解密响应

客户端接收加密的 chunk 并使用私钥解密。

前置条件

JavaScript(Node.js ESM):
Python:

步骤 1:检查模型 E2EE 支持

首先,通过检查 /models 端点验证模型是否支持 E2EE。

步骤 2:生成临时密钥对

为每个会话生成新的密钥对。私钥应仅保留在内存中,并在使用后安全清零。

验证辅助函数

在发送请求之前使用这些辅助函数验证密钥和加密内容。

步骤 3:获取并验证 TEE 证明

证明证明模型正在真实的 TEE 中运行。在信任模型的公钥之前,请始终验证证明。
重要:Nonce 长度 - 客户端 nonce 必须是 32 字节(64 个十六进制字符)。某些 TEE 提供商要求恰好 32 字节,并会拒绝更短的 nonce。

步骤 4:加密消息

在发送之前加密用户和系统消息。只有 usersystem 角色的消息需要加密。
当存在 E2EE 头部时,所有 usersystem 角色的消息都必须加密。在这些角色中发送任何明文内容将导致 “Encrypted field is not valid hex” 错误。

步骤 5:使用 E2EE 头部发送请求

包含所需的头部以启用 E2EE 处理。

步骤 6:解密响应 chunk

来自 E2EE 模型的响应是十六进制编码的加密 chunk。使用您的私钥解密每个 chunk。

完整工作示例

E2EE 限制

由于加密要求,E2EE 存在一些限制:

安全最佳实践

  1. 每个会话生成新的密钥对 - 不要复用临时密钥
  2. 清零私钥 - 使用完成后从内存中清除私钥字节
  3. 验证证明 - 始终检查 verified: true 和 nonce 匹配
  4. 检查 debug 模式 - 拒绝来自 debug enclave 的证明
  5. 使用流式传输 - E2EE 需要流式传输以正确分块加密
  6. 优雅处理错误 - 不要向用户暴露解密错误
  7. 使用 32 字节 nonce - TEE 提供商要求恰好 32 字节

最佳实践

不要仅信任 verified: true 响应。在客户端解析 Intel TDX quote 并验证测量值是否与预期值匹配。对于 NVIDIA GPU,通过 NVIDIA 的验证服务检查证明。
始终为每个证明请求生成新的随机 nonce。这可以防止攻击者提供过时证明的重放攻击。
签名密钥应该绑定到 TDX REPORTDATA 字段。这证明密钥是在 enclave 内部生成的。
验证 TDX 证明没有设置 debug 标志。debug enclave 可以被检查,不应被信任用于生产环境。
E2EE 需要谨慎的密码学实现。请使用我们的官方 SDK 而不是自己实现协议。

检查模型能力

您可以通过 models 端点检查模型是否支持 TEE 或 E2EE:

错误处理

故障排查

nonce 长度不正确。TEE 提供商要求恰好 32 字节(64 个十六进制字符)
  • 使用 crypto.randomBytes(32).toString('hex')(JS)或 secrets.token_hex(32)(Python)
  • 常见错误:secrets.token_hex(16) 产生 32 个十六进制字符(16 字节),而非 32 字节
  • 检查模型是否支持 E2EE(supportsE2EE: true
  • 验证您的 API 密钥有效且可访问请求的模型
  • 验证到 Venice API 的网络连接
  • 确保您使用的是生成头部中发送的公钥的相同私钥
  • 检查响应内容是否确实是十六进制编码(E2EE 处于激活状态)
  • 验证模型公钥与用于加密的密钥匹配
  • 当存在 E2EE 头部时,所有 usersystem 角色的消息都必须加密
  • 验证您的加密内容通过 isValidEncrypted() 验证(最少 186 个十六进制字符)
  • 检查加密输出是小写十六进制且没有任何前缀
  • 客户端公钥必须恰好是以 04 开头的 130 个十六进制字符
  • 使用 validateClientPubkey() 辅助函数在发送前验证格式
  • 确保您使用未压缩的公钥格式(65 字节 = 130 个十六进制字符)
  • 验证模型 ID 正确且模型支持 E2EE
  • 使用 /models 端点验证可用的 E2EE 模型

资源