Too Private to Notice: A Practical Token Theft Attack Against Apple Intelligence

Core question: can an attacker easily steal Apple Intelligence access tokens from a victim's Mac and impersonate the victim to use the service on another Mac (the research question as stated in the paper).

• Scenario and significance: Apple Intelligence is the GenAI service built into Apple devices; cloud requests are handled via Private Cloud Compute (PCC), using two-stage anonymous token authentication (TGT + one-time OTT) to protect privacy. The authors argue that, compared with previous key-leak attacks targeting developers, attacks on this platform's tokens have greater impact: victims are ordinary consumers without security knowledge, the tokens are bearer tokens, and victims cannot revoke the tokens.
• Shortcomings of the existing design (per the authors): the authors state that anonymized identity does not by itself equal security—tokens are not cryptographically bound to the legitimate user, are stored in the login keychain accessible to ordinary users, and there is no revocation mechanism.
• Core observation: after the PCC Identity Service, the authentication flow no longer verifies device eligibility; token verification only checks the signature and does not validate the device information in the nonce, so whoever holds the token can use the service.
• Paper output: the authors propose the Serpent attack (which the authors call the first practical cross-device token replay attack against the Apple Intelligence authentication flow), demonstrate it on macOS 26 Tahoe, and propose two types of mitigation and three types of complete defense approaches; Apple has confirmed the vulnerability, assigned a CVE and paid a bounty.
• Threat model:
  • Attacker goal: steal the victim's tokens, use Apple Intelligence on their own device, with usage counted against the victim's quota.
  • Attacker knowledge/capability: get the victim to run a malicious app distributed by the attacker (ordinary user privileges, no privilege escalation required), and assume the victim clicks Allow in the keychain authentication pop-up; the attacker sets up a remote server to receive the tokens.
  • Victim system: the Apple Intelligence client and PCC cloud authentication flow on a Mac running macOS 26 Tahoe (an M4 Mac mini for experiments).
  • Success criterion: the tokens are transmitted back and can be used for the Apple Intelligence service.

The paper positions Serpent as a credential theft attack, discusses related work in two groups, and provides a comparison in Table 2.

API key leakage

• Active analysis type ([41, 43, 45, 46]): obtaining insufficiently protected API keys on various platforms through traffic analysis and reverse engineering.
• Passive scanning type ([23, 32, 35, 42]): scanning for API keys leaked in projects on open-source platforms such as GitHub.
• The paper points out how Serpent differs from these works: victims are non-technical end users rather than professional developers; victims can hardly detect the attack (developers can set usage alerts [24, 36]); Serpent harvests tokens in bulk from non-specific victims' devices rather than analyzing a single global key within an app; API keys can be revoked by developers [18], whereas Apple Intelligence tokens cannot be revoked.

Cookie theft attacks

• Mechanisms include XSS and CSRF [9, 34], session hijacking [19], security policy forgery [21, 39], DNS hijacking [20], etc., with attackers impersonating victims to use web services.
• The paper points out the differences: cookie leakage can be detected by platforms and users through IP geolocation [33] and usage patterns [8], whereas Apple Intelligence's anonymization design makes it undetectable; most services offer "sign out everywhere" to revoke cookies [44], whereas Apple Intelligence has no such mechanism.

Background references

• Privacy Pass (RFC 9578 [11], Davidson [14]) and blind signatures/OPRF [10, 17] are the technical basis of Apple Intelligence authentication; macOS Keychain [7] is the token storage facility, known to be frequently attacked [40, 48].

Positioning: the authors state that Serpent is the first attack targeting the Apple Intelligence authentication flow with minimal end-user interaction and potential for large-scale deployment, and that it differs fundamentally from the above works in attack target, victim type, detectability and remediation (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）：

Swipe horizontally to read the table

实验	做法	观察结果	出处
请求名义归属	导入受害者令牌后拦截 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 服务使用甚至转售；此为作者基于漏洞的推断，未报告实现。

Limitations and future directions noted by the authors

• Mitigation one can be bypassed (Section 6.1): de-privileging (including the iCloud keychain approach Apple adopted in macOS 26.2) can be bypassed by root privileges or kernel extensions bypassing entitlement checks, and the sudo prompt can also be forged; the authors explicitly call it "only a mitigation, not a fundamental fix."
• Memory and traffic paths remain open (Section 6.1): automated memory debugging and traffic analysis can still reveal tokens; the authors have reported this to Apple, and Apple is developing a new patch.
• Shortening key lifetimes only narrows the window (Section 6.2): shortening the TGT signing key lifetime from several days to several hours does not eliminate the attack and increases the load on the PCC Identity Service.
• Keeping plaintext off disk is still a mitigation (Section 6.3): under hardware encryption or re-requesting a TGT on each startup, an attacker can still extract tokens by debugging the PCC daemon (though it is harder); the authors state it "is a mitigation, not a root fix."
• Complete defense requires redesigning the protocol (Section 6 introduction): the authors state that because the authentication flow is complex and non-standard, a complete defense inevitably requires major changes to the protocol.
• Cross-platform abuse is inferred (Section 7): building a fully automated client for platforms such as Linux and reselling the service as a general LLM service are directions the authors consider "possible"; the paper does not report an implementation.

Scope of experiments

• The experimental platform is macOS 26.0 (25A353) Tahoe, M4 Mac mini; the attack demonstration is on macOS 26 Tahoe, and the analysis of Apple's mitigation targets macOS 26.2 (Sections 3, 5, 6.1).
• There are three empirical experiments: traffic analysis of request nominal attribution, reviving a banned Mac, and DoS against the victim (Section 5.1).
• The paper does not report the number of experiment repetitions, sample sizes or statistical tests.
• The ethics statement confirms that experiments were conducted only on the authors' own devices and did not touch public services or normal users (Section 7).
• The paper does not cover empirical work on iOS/iPadOS/visionOS (these platforms are mentioned only in the background).

这是一篇针对 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；作者另提出缩短密钥寿命、硬件加密存储等方向，并称根治需重构协议。