大模型 API 在返回推理结果时，会将模型的内部思维链（Chain-of-Thought, CoT）以加密 blob 的形式下发给客户端。这一设计本意是在支持无状态会话的同时保护模型推理过程的隐私，但密码学工程实现中的缺陷却暴露出一系列安全风险。本文基于对 OpenAI 与 Anthropic API 的实际测试，分析加密推理 blob 的密钥派生机制、访问控制漏洞与侧信道泄露风险，为工程团队提供可落地的安全加固参数。
加密推理 Blob 的技术结构
当调用支持推理的 LLM API 时，响应中除了可见的文本输出外，还包含一个名为reasoning或thinking的字段。该字段的内容并非明文，而是 Base64 编码的加密 blob。以 OpenAI 的格式为例，其结构类似于 Fernet Token 标准：包含时间戳、初始化向量（IV）、认证密文和 HMAC 认证标签。Anthropic 的实现则更为复杂，包含多个不透明字段，其中 12 字节的 IV 暗示可能使用 GCM 或 ChaCha20-Poly1305 模式，64 字节的 "签名" 字段经测试并非真正的数字签名，而是某种认证标签。
这些 blob 的设计目标是实现 "零数据保留"（Zero-Data Retention）模式下的状态传递。在无状态架构中，服务器不保存会话历史，客户端需要在后续请求中回传之前的推理状态。加密 blob 使客户端能够存储但不读取这些状态，服务器则可以在收到回传后进行解密和验证，继续推理流程。
密钥派生的关键缺陷
通过系统的重放测试发现，加密 blob 存在一个严重的密钥管理问题：所有用户的推理数据使用同一组全局密钥进行加密和认证。具体表现为：从一个账户获取的加密 blob，可以在完全不同的账户、甚至不同的 API 会话中被成功回传并解密。
这一发现揭示了密钥派生机制的缺失。理想的实现应当基于账户 ID、会话 ID、时间戳等上下文信息派生独立的加密密钥，确保每个 blob 只能在其原始上下文中被验证。而当前实现中，全局密钥的使用意味着：
- 任何获取 blob 的攻击者都可以在其他上下文中重放该 blob
- 服务器无法通过密钥派生路径区分合法回传与恶意注入
- 跨账户的数据隔离仅依赖于应用层逻辑，而非密码学保证
对于依赖零数据保留模式的合规场景，这一缺陷意味着所有用户的推理数据实际上被托管在同一密钥下，而非按账户隔离保护。
访问控制漏洞：重放攻击的实现
重放攻击的实现过程揭示了访问控制设计的薄弱环节。攻击者可以通过以下方式利用这一漏洞：
首先，攻击者诱导目标应用生成包含特定推理内容的 blob。由于 blob 内容不可读，应用开发者往往忽视其安全风险，可能将用户输入直接嵌入到后续请求的 JSON 结构中。如果应用未对输入进行严格的 JSON 净化，攻击者可以构造包含恶意reasoning字段的输入，注入来自其他会话的加密 blob。
当应用将此输入发送给 API 时，服务器会解密并 "恢复" 注入的推理状态。实验表明，这些被重放的 blob 不仅是被 "接受"，而且是 "语义激活" 的 —— 模型确实会读取并响应其中包含的推理内容。在一个跨账户测试中，模型在没有任何提示的情况下，输出了来自另一账户会话中讨论的社会安全号码。
这一漏洞对多租户应用构成直接威胁。如果应用向不可信用户暴露聊天接口，攻击者可能通过注入精心构造的推理 blob，影响模型的行为逻辑，甚至诱导模型泄露敏感信息。
侧信道风险：审计追踪的盲区
即使加密 blob 的内容无法直接读取，其元数据仍构成信息泄露的侧信道。可观测的信号包括：
- Blob 大小：加密后的推理 blob 长度与原始推理内容的复杂度正相关
- Token 计数：OpenAI API 返回的
reasoning_tokens字段直接暴露推理开销 - 响应时间：模型处理复杂推理的时间显著长于简单推理
实验设计了一个比特提取场景：假设模型的系统提示中包含一个秘密比特（0 或 1），且被严格限制不得向用户透露。攻击者请求模型基于该比特执行条件推理 —— 如果比特为 0 则执行简单计算 A，如果为 1 则执行复杂计算 B。由于两种计算的可见输出被设计为相同，模型表面上遵守了保密指令。然而，通过观察加密 blob 的大小或响应时间，攻击者可以准确推断秘密比特的值。
在 80 次试验中，使用 blob 大小和响应时间作为分类特征，对字节0xA3（二进制 10100011）的逐位提取达到了显著的成功率。0 比特和 1 比特在响应时间分布上呈现清晰的分离，橙色（1 比特）样本明显比蓝色（0 比特）样本耗时更长。
这一侧信道对审计追踪构成挑战。传统的审计机制关注明文输入输出，而加密 blob 的元数据泄露发生在密码学保护的范围之外。即使部署了端到端加密和访问日志，响应时间和 token 计数仍可能暴露敏感信息。
工程加固建议
针对上述风险，工程团队可以从以下三个层面实施加固：
密钥派生层：要求模型提供商实现基于上下文的密钥派生。最小参数集应包含账户 ID、会话 ID、时间戳和随机盐值，使用 HKDF 或类似算法派生独立密钥。在提供商修复之前，应用层可通过在 blob 外附加额外的 MAC 来检测重放。
输入净化层：对所有用户输入实施严格的 JSON 净化，拒绝包含reasoning、thinking等保留字段的输入。对于必须保留的 blob 回传，实施完整性检查，确保 blob 与当前会话上下文匹配。
监控与审计层：监控异常模式，包括同一 blob 的多次出现、响应时间与输入复杂度的异常偏离、以及跨会话的 blob 重放尝试。对于高敏感场景，考虑引入响应时间随机化或填充策略，增加侧信道攻击的难度。
结语
加密推理 blob 的设计反映了 LLM 服务在无状态架构与隐私保护之间的工程权衡。然而，全局密钥的使用、重放攻击的可行性以及侧信道泄露的风险表明，当前的实现尚未达到生产环境的安全标准。模型提供商需要将这一机制视为真正的密码学协议进行设计和审计，而不仅仅是 API 实现的细节。对于依赖这些 API 的应用开发者而言，在输入净化和异常监控上投入额外的工程资源，是降低当前风险的必要措施。
参考来源
- Matthew Green, "Let's talk about encrypted reasoning," Cryptography Engineering Blog, May 29, 2026. https://blog.cryptographyengineering.com/2026/05/29/fooling-around-with-encrypted-reasoning-blobs/
- arXiv:2602.17223, "Privacy-Preserving Mechanisms Enable Cheap Verifiable Inference of LLMs."
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。