2026 年 4 月，一起涉及美国 ICEPrairieland 拘留所设施的案件引发了安全社区的广泛关注。FBI 特别探员 ClarkWiethorn 在庭审证词中披露，调查人员从被告的 iPhone 中成功恢复了已删除的 Signal 消息，而这些消息的获取并非通过破解 Signal 的端到端加密，而是利用了 iOS 通知系统的缓存机制。关键在于，Signal 应用虽然已被从设备中移除，但系统内部存储的通知数据仍然得以保留，成为取证过程中的可访问 artifacts。这一发现不仅揭示了 iOS 通知子系统的数据持久化行为，更暴露了即使使用端到端加密通信应用，用户仍可能在不知情的情况下面临隐私泄露风险。

iOS 通知子系统的数据持久化机制

要理解 FBI 为何能够提取已删除应用的通知数据，首先需要了解 iOS 通知系统的工作原理。当用户收到一条即时通讯应用推送的消息时，系统会经历一个复杂的数据流转过程。推送通知从服务器端发出后，经过 Apple 的推送通知服务（APNs）路由至目标设备，此时 iOS 系统会接收通知载荷并将其存储在系统的通知数据库中，以便在锁屏界面、通知中心或横幅中向用户展示。这一缓存机制的设计初衷是提升用户体验，确保用户即使在设备暂时离线或应用未运行的情况下也能及时看到消息预览。

iOS 系统在处理通知时会在内部维护一个专门的通知数据库，该数据库独立于具体应用程序的数据存储而存在。当通知送达时，系统会提取其中的关键信息，包括发送者标识、消息内容预览以及时间戳等，并将其写入数据库的表结构中。这些数据会被用于生成锁屏通知、通知中心条目以及横幅展示。即使对应的应用程序已被用户手动删除，只要设备尚未进行完全恢复出厂设置，这些通知记录通常仍会保留在系统的内部存储区域内，等待被下一次系统清理操作所覆盖或删除。

另一个关键因素在于推送通知令牌的生存周期。当用户首次安装 Signal 并授权接收推送通知时，APNs 会为该设备上的应用分配一个唯一的推送令牌，这个令牌会被发送至 Signal 服务器用于后续的消息推送。然而，当用户从设备上删除 Signal 应用时，这个令牌并不会立即被 Apple 的服务器端宣告失效，服务器在最后一次推送之后无法获知应用是否仍然安装，因此会继续向该设备发送推送通知，由 iOS 系统决定是否以及如何处理这些通知。在某些设备状态和 iOS 版本组合下，系统甚至会将这些 “orphan” 通知的内容保存至通知数据库中，形成取证人员可以利用的数据源。

设备状态与取证访问的层级关系

iOS 设备在不同解锁状态下对数据访问的限制程度存在显著差异，这一特性直接影响取证工具能够获取的数据范围。设备在首次解锁之前处于 BFU 状态，此时所有数据均处于硬件加密保护之下，取证工具难以直接访问文件系统。设备完成首次解锁后进入 AFU 状态，文件系统密钥已加载至内存，此时通过越狱或利用内核漏洞的工具可以访问更大范围的数据存储。

根据现有技术资料推测，FBI 在此案中使用的数据提取方式可能涉及两种路径。第一种路径是通过设备完整备份提取数据，用户在通过 iTunes 或 Finder 创建本地加密备份时，系统会将包括通知数据库在内的多个系统数据库打包进备份文件中，取证人员可以解析这些备份文件以提取通知历史。第二种路径是利用商业取证工具直接读取设备文件系统，这些工具通常结合了 checkm8 等 bootrom 漏洞或内核漏洞，能够在设备解锁后提取原始文件系统镜像，其中就包含了通知缓存数据库。

值得注意的是，本案中提取的数据仅限于接收到的消息，而未包含发送的消息。这一限制反映了 iOS 通知系统的工作特性：通知本质上是被动接收的数据，系统仅会为传入消息生成通知预览并存储，而用户主动发送的消息内容通常保存在应用自身的数据库中，不通过通知系统进行中转。因此，即使通知数据库被成功提取，也只能获取到设备作为接收方时的消息副本。

隐私风险评估与系统性隐患

这一取证案例之所以引发广泛讨论，根本原因在于它揭示了一个被大多数用户忽视的系统级隐私风险。端到端加密被广泛视为保护通信隐私的金标准，Signal 作为开源的端到端加密通信协议实现，其加密机制本身并未被破解，消息在传输过程中和设备本地存储时都受到强加密保护。然而，通知系统作为一个独立的中间层，以明文形式缓存了消息内容的可读副本，从而在加密体系之外打开了一个可能被利用的侧信道。

从风险矩阵的角度分析，这一漏洞的影响范围并非均等分布。对于普通用户而言，实际遭受针对性取证的概率相对较低，取证操作通常需要专业工具和特定设备状态的配合。但对于特定风险群体，包括但不限于活动人士、记者、律师以及涉及敏感业务的个人，这一发现具有实质性的安全含义。即使通信应用本身实现了端到端加密，用户仍需意识到设备层面的数据处理行为可能在不经意间留下可被提取的痕迹。

此外，iOS 系统对通知数据的保留策略缺乏足够的透明度。用户在删除应用后通常认为所有相关数据已从设备中清除，但实际上系统可能仍保留着通知历史记录。这种隐式数据持久化行为与用户预期之间存在显著落差，构成了一种隐性的信息不对称。Apple 在 iOS26.4 版本中悄然调整了推送令牌验证机制，虽然官方未明确说明是否与此次案件相关，但时间上的巧合引发了社区的合理猜测。

可落地的防护参数与配置建议

面对这一系统性风险，用户可以通过多个层面的配置来降低通知数据泄露的可能性。以下是可操作的防护参数建议：

** 应用层面：** 在 Signal 应用中，用户应进入设置菜单，启用 “通知” 项下的 “显示内容” 关闭选项。该设置生效后，推送通知将仅显示 “您有新消息” 而不包含消息正文内容，从根本上减少可被缓存的敏感信息量。同样的配置逻辑适用于所有即时通讯应用，包括 iMessage、WhatsApp、Telegram 等。

** 系统层面：**iOS 提供了锁屏通知预览的显示控制选项。用户可以进入 “设置”→“通知”→“显示预览”，将显示时机调整为 “解锁时” 或直接关闭。设置为 “解锁时” 意味着通知内容仅在用户主动解锁设备后才会显示，锁屏界面仅显示 “通知” 而不展示具体内容。这一设置对所有应用生效，是全局性的防护手段。

** 设备管理层面：** 对于高风险用户，建议定期重启设备并关注设备的物理安全。设备每次重启后进入 BFU 状态，文件系统密钥未被加载，理论上可以阻止对通知数据库的进一步访问。此外，避免在设备上创建未加密的本地备份，并定期检查已授权的 iCloud 备份范围，确保通知数据未被同步至云端。

** 长期防护层面：** 关注 iOS 系统更新，Apple 可能在后续版本中调整通知数据的保留策略或增加用户对通知存储的直接控制权。保持系统版本更新是获取这些潜在改进的必要条件。对于有条件的高级用户，可以考虑使用专业的隐私保护工具或配置更严格的设备访问策略。

小结

FBI 通过 iOS 通知缓存提取已删除 Signal 消息的案例，本质上揭示的是 iOS 通知子系统在数据持久化方面的设计特性，而非 Signal 应用本身的安全缺陷。端到端加密仍然有效，但设备层面的通知缓存机制创造了一个独立的明文数据窗口。对于注重隐私的用户而言，理解这一风险并采取积极的防御配置是必要的。关键防护措施可以归纳为三个核心参数：关闭应用通知预览内容、调整锁屏通知显示时机为解锁后、定期管理设备备份与系统更新。这些措施虽然无法提供绝对的保护，但在绝大多数场景下足以显著提升攻击者获取通知数据的难度，将潜在的取证风险控制在可接受范围内。

参考资料：

  • 9to5Mac: "FBI used iPhone notification data to retrieve deleted Signal messages"（2026 年 4 月 9 日）
  • 404 Media: "FBI Extracts Suspect's Deleted Signal Messages Saved in iPhone Notification Database"