太私密而难以察觉：针对 Apple Intelligence 的实用令牌窃取攻击

核心问题：攻击者能否轻易从受害者的 Mac 窃取 Apple Intelligence 访问令牌，并在另一台 Mac 上冒充受害者使用服务（论文原话的研究问题）。

• 场景与重要性：Apple Intelligence 是 Apple 设备内置的 GenAI 服务，云端请求经 Private Cloud Compute（PCC）处理，采用两阶段匿名令牌认证（TGT + 一次性 OTT）以保护隐私。作者认为，相比以往针对开发者的密钥泄露攻击，针对该平台令牌的攻击影响更大：受害者是无安全知识的普通消费者、令牌是 bearer token、且受害者无法吊销令牌。
• 现有设计的不足（按作者说法）：作者称匿名化身份本身并不等于安全——令牌未与合法用户做密码学绑定，存储在普通用户可访问的登录钥匙串中，且没有吊销机制。
• 核心观察：认证流程在 PCC Identity Service 之后不再验证设备资格，令牌验证只检查签名，不校验 nonce 中的设备信息，因此谁持有令牌谁就能使用服务。
• 论文产出：作者提出 Serpent 攻击（作者称其为首个针对 Apple Intelligence 认证流程的实用跨设备令牌重放攻击），在 macOS 26 Tahoe 上演示，并提出两类缓解与三类完整防御思路；Apple 已确认漏洞、分配 CVE 并发放赏金。
• 威胁模型：
  • 攻击者目标：窃取受害者令牌，在自己设备上使用 Apple Intelligence，用量计入受害者配额。
  • 攻击者知识/能力：让受害者运行其分发的恶意应用（普通用户权限，无需提权），并假设受害者在钥匙串认证弹窗中点击 Allow；攻击者架设远程服务器接收令牌。
  • 受害系统：运行 macOS 26 Tahoe 的 Mac（实验用 M4 Mac mini）上的 Apple Intelligence 客户端及 PCC 云端认证流程。
  • 成功判定：令牌被传回且可用于 Apple Intelligence 服务即视为成功。

论文将 Serpent 定位为凭证窃取攻击，相关工作分两组讨论，并在 Table 2 中给出对比。

API key 泄露

• 主动分析类（[41, 43, 45, 46]）：通过流量分析和逆向工程获取各平台上保护不足的 API key。
• 被动扫描类（[23, 32, 35, 42]）：扫描 GitHub 等开源平台项目中泄露的 API key。
• 论文指出 Serpent 与这些工作的区别：受害者是非技术终端用户而非专业开发者；受害者几乎无法察觉攻击（开发者可设用量告警 [24, 36]）；Serpent 从非特定受害者的设备批量收割令牌而非分析单一应用内全局密钥；API key 可被开发者吊销 [18]，而 Apple Intelligence 令牌无法吊销。

Cookie 窃取攻击

• 机制包括 XSS 与 CSRF [9, 34]、会话劫持 [19]、安全策略伪造 [21, 39]、DNS 劫持 [20] 等，攻击者冒用受害者身份使用 Web 服务。
• 论文指出区别：cookie 泄露可通过 IP 地理定位 [33] 和使用模式 [8] 被平台和用户检测，而 Apple Intelligence 匿名化设计使其无法被检测；多数服务提供"sign out everywhere"吊销 cookie [44]，Apple Intelligence 无此机制。

背景性引用

• Privacy Pass（RFC 9578 [11]、Davidson [14]）与盲签名/OPRF [10, 17] 是 Apple Intelligence 认证的技术基础；macOS Keychain [7] 是令牌存储设施，已知常被攻击 [40, 48]。

定位：作者称 Serpent 是首个针对 Apple Intelligence 认证流程、终端用户交互最少、有规模化部署潜力的攻击，与上述工作在攻击对象、受害者类型、可检测性和补救手段上均有本质区别（Table 2）。

整体思路：通过流量解密分析、逆向工程和与 Apple 公开文档交叉比对，解剖 Apple Intelligence 的认证与授权流程，定位漏洞根因，然后实施 Serpent 攻击（提取阶段 + 伪装阶段）。分析基于 macOS 26.0 (25A353) Tahoe、M4 Mac mini。

认证流程解剖（Section 3）

• TGT 签发：客户端向 PCC Identity Service 证明设备资格，获得遵循 RFC 9578、基于 RFC 9474 RSA 盲签名的 TGT；作者逆向发现 challenge 是静态的，不同 TGT（甚至跨设备）的差异仅来自 nonce（Figure 3）。
• OTT 签发：TGT 经 OHTTP 中继向 Token Granting Service 兑换 OTT，本地缓存目标为 50 个；OTT 同时充当速率限制器，配额约数百万 token/天/用户，用完后约次日才能再领。
• 请求处理：PCC Gateway 校验 OTT（一次性消耗）；PCC 节点上的 TGT 校验代码已实现，但配置项 enforceTGTValidation 默认为 false，校验失败不会中断请求（Figure 4）。
• 有效期机制：令牌本身不含过期信息，过期由签名密钥有效期决定；实测 TGT 存活数天，OTT 约 12 小时失效（Table 1）。
• 设备端存储：逆向 privatecloudcomputed → NetworkServiceProxy 私有框架 → networkserviceproxy 守护进程（XPC 端点 com.apple.networkserviceproxy.fetch-token，命令类型 51）→ Security 框架 SecItemCopyMatching 的调用链，发现令牌明文存储在登录钥匙串（Figure 5）。

协议缺陷（Section 4.1）

• 客户端无保护：TGT/OTT 明文存于登录钥匙串，普通用户权限即可读写，无需提权。
• 未绑定硬件：nonce 虽可能含设备信息，但任何验证环节都不校验，验证器无法确认请求来自令牌签发设备。
• 长寿命 TGT 可泄露：TGT 有效期数天，速率限制冷却约一天后可再次兑换 OTT，攻击者可在单个 TGT 生命周期内多次耗尽受害者每日配额。
• 无吊销机制：用户无法吊销或刷新令牌。

Serpent 攻击流程（Section 4.2）

1. 提取阶段：受害者设备上的恶意逻辑通过钥匙串 API（SecItemCopyMatching）或 /usr/bin/security 工具读取令牌，得到 plist 格式数据（令牌以 Base64 编码），经网络发往攻击者服务器；首次访问需用户在钥匙串弹窗授权（无需 root）。
2. 伪装阶段：攻击者在自己 Mac 上用相同 account/service 名覆盖或新建钥匙串条目写入受害者令牌；之后该机发出的请求即以受害者名义认证，OTT 用尽后可用 TGT 继续兑换新批次。

对策设计（Section 6）

• 缓解一（去特权化）：将令牌移出用户可直接访问的范围；作者称 Apple 在 macOS 26.2 中采用了相近思路——把 TGT 移到 iCloud 钥匙串、access group 设为 apple，由 AMFI 强制 restricted entitlement 检查（Figure 6）。
• 缓解二：缩短 TGT 签名密钥寿命（如从数天缩到数小时），缩小被盗 TGT 可用窗口，代价是 PCC Identity Service 负载增加。
• 完整防御：不留可检索明文——用 Secure Enclave 等硬件信任根加密令牌且仅向 PCC 守护进程解密，或 PCC 守护进程每次启动重新申请 TGT；作者称这些仍是缓解而非根治。

实验设置

• 被测系统：macOS 26.0 (25A353) Tahoe 上的 Apple Intelligence，运行于 M4 Mac mini（Section 3、Section 5）；攻击演示另在 macOS 26 Tahoe 上完成，Apple 的缓解在 macOS 26.2 上分析。
• 分析手段：流量解密与拦截分析、逆向工程（NetworkServiceProxy 私有框架、networkserviceproxy 守护进程、CloudBoard 源码）、与 Apple 公开文档 [31] 交叉比对。
• 成功判定：令牌被传回攻击者且可用于 Apple Intelligence 服务即攻击成功（Section 4.2 威胁模型）。
• 关键观测对象：TGT/OTT 的格式与有效期（Table 1）、钥匙串存储位置（Figure 5）、PCC 节点 TGT 校验逻辑（Figure 4）。
• 论文未报告实验重复次数、样本量或统计检验；实验设备为作者自有设备。

主结果

论文无定量结果表，主结果为三项实证观察（Section 5.1）：

表格较宽，可左右滑动

实验	做法	观察结果	出处
请求名义归属	导入受害者令牌后拦截 privatecloudcomputed 发出的请求	请求中携带的 TGT/OTT 确实来自受害者	Section 5.1
复活被封禁 Mac	先用数百万 token 的大提示词耗尽攻击者 Mac 配额，再反复删取 TGT 直至 PCC Identity Service 也封禁该机，然后导入受害者令牌	该机恢复使用 Apple Intelligence，TGT 可正常兑换新 OTT	Section 5.1
对受害者 DoS	攻击者用被盗 TGT 持续兑换 OTT 耗尽配额	受害者 Mac 显示"Apple Intelligence is currently not available"并停止服务	Section 5.1

• 作者据此认为：Apple Intelligence 的认证完全基于 TGT/OTT 令牌本身，不含其他所有权信息；攻击者用量确实计入受害者配额。
• 作者指出 DoS 甚至无需真正消耗 OTT：速率限制由 Fraud Detection Service 通过控制 TGT 可兑换的 OTT 数量实现，攻击者只需反复兑换再丢弃即可。

受害者可察觉性分析（Section 5.2）

• 攻击中：钥匙串弹窗显示应用名和服务名，应用名可自定义；作者引用 Apple 社区 [12, 13] 和论坛 [29] 的建议（输入密码点 Allow 甚至 Always Allow），认为普通用户授权的可能性高；也可用伪造认证弹窗（如 AMOS 恶意软件 [48] 的做法）或钥匙串绕过漏洞（如 CVE-2017-7150 [40]）实现无感知提取。
• 攻击后：配额耗尽时受害者仅看到服务不可用警告，作者认为这更像服务中断而非被攻击，受害者难以察觉。

对 Apple 缓解措施的分析（Section 6.1）

• 测了什么：分析 macOS 26.2 安全更新后令牌存储的变化。
• 结果：TGT 被移至 iCloud 钥匙串，access group 设为 apple（Figure 6），访问需 Apple 签发的 restricted entitlement，由内核 AMFI 强制。
• 作者解读：作者称该缓解不是根治——[27] 的内核扩展可选择性绕过 entitlement 检查，自动化内存调试和流量分析仍能获取令牌；作者已报告 Apple 并获确认，Apple 正在开发新补丁。

其他消融与分析

• 令牌有效期实测（Section 3.4）：TGT 存活数天，OTT 约 12 小时失效；过期由签名密钥有效期决定，客户端无法查询或吊销。
• 配额与冷却（Section 3.2、4.1）：每用户每日配额约数百万 token；速率限制冷却约一天后 TGT 可再次兑换 OTT。
• TGT 校验默认放行（Section 3.3，Figure 4）：CloudBoard 源码中 enforceTGTValidation 默认为 false，TGT 校验失败不中断请求。
• 进一步滥用讨论（Section 7）：作者认为可构建跨平台（如 Linux）全自动兼容客户端，把 Apple Intelligence 当通用 LLM 服务使用甚至转售；此为作者基于漏洞的推断，未报告实现。

作者指出的局限与后续方向

• 缓解一可被绕过（Section 6.1）：去特权化（含 Apple 在 macOS 26.2 采用的 iCloud 钥匙串方案）可被 root 权限或内核扩展绕过 entitlement 检查，sudo 提示也可被伪造，作者明确称其"只是缓解而非根本修复"。
• 内存与流量路径仍开放（Section 6.1）：自动化内存调试和流量分析仍可揭示令牌；作者已报告 Apple，Apple 正在开发新补丁。
• 缩短密钥寿命只是缩小窗口（Section 6.2）：将 TGT 签名密钥寿命从数天缩到数小时不能消除攻击，且会增加 PCC Identity Service 负载。
• 明文不落地仍是缓解（Section 6.3）：硬件加密或每次启动重领 TGT 的方案下，攻击者仍可通过调试 PCC 守护进程提取令牌（尽管更难），作者称其"是缓解而非根治"。
• 完整防御需重构协议（Section 6 引言）：作者称由于认证流程复杂且非标准，完整防御不可避免地需要对协议做重大改动。
• 跨平台滥用为推断（Section 7）：构建 Linux 等平台的全自动客户端、将服务转售为通用 LLM 服务是作者认为"可能"的方向，论文未报告实现。

实验覆盖范围

• 实验平台为 macOS 26.0 (25A353) Tahoe、M4 Mac mini；攻击演示在 macOS 26 Tahoe 上，Apple 缓解分析针对 macOS 26.2（Section 3、5、6.1）。
• 实证实验为三组：请求名义归属流量分析、复活被封禁 Mac、对受害者 DoS（Section 5.1）。
• 论文未报告实验重复次数、样本量及统计检验。
• 伦理声明确认实验仅在作者自有设备上进行，未触及公共服务或正常用户（Section 7）。
• 论文未覆盖 iOS/iPadOS/visionOS 上的实证（这些平台仅在背景中提及）。

这是一篇针对 Apple Intelligence 认证机制的安全分析论文：作者通过流量解密、逆向工程和文档交叉比对，解剖了其基于 Privacy Pass 的两阶段匿名令牌流程，并提出跨设备令牌重放攻击 Serpent。

• 要解决的问题：Apple Intelligence 用匿名 TGT/OTT 令牌实现"认证不暴露身份"，作者检验匿名化是否足以保证令牌不可转移。
• 方法要点：发现令牌明文存于登录钥匙串（普通用户权限可读）、验证只查签名不绑设备、TGT 存活数天且无吊销机制；攻击分提取（恶意应用读钥匙串并经弹窗授权）和伪装（攻击者 Mac 覆盖写入受害者令牌）两阶段。
• 主要结果：在 macOS 26.0 的 M4 Mac mini 上，导入受害者令牌后请求确以受害者名义发出；一台配额与 TGT 均被封锁的 Mac 导入令牌后立即恢复服务；DoS 实验中受害者端仅显示服务不可用，用量确认计入受害者。令牌参数：OTT 本地缓存 50 个、约 12 小时失效，TGT 存活数天，每日配额约数百万 token、冷却约一天。
• 作者结论：作者称匿名化身份本身不能让 AI 服务安全，强制不可转移性需要将令牌密码学绑定到合法用户/设备。
• 后续：Apple 在 macOS 26.2 将 TGT 移至 iCloud 钥匙串（与作者建议的缓解思路相近），作者分析后认为仍可被绕过并已再报 Apple；作者另提出缩短密钥寿命、硬件加密存储等方向，并称根治需重构协议。