苹果公布 Secure Exclaves：小圆点没通过像素校验，Hey Siri 的音频就不放行

苹果迷 2026-11-12 20:57 苹果家园 | 隐藏边栏 | 抢沙发 | 2 0

文章评分 0 次，平均分 0.0 ：

导语：苹果 11 月 12 日在安全研究博客公开 Secure Exclaves，把 iPhone 18 Pro 与 iPhone Duo 屏幕上的麦克风摄像头提示点交给显示隔离区核对像素：颜色、形状、时长、亮度、有没有被挡住，任何一项不对，音频就不许离开隔离区。常驻监听录到的原始音视频，处理完即销毁。

11 月 12 日，苹果安全工程与架构团队（SEAR）和核心操作系统团队（Core OS）在苹果安全研究博客发了一篇长文，标题是《Secure Exclaves and Ambient Sensing》。文中写明，iPhone 18 Pro、iPhone 18 Pro Max 与 iPhone Duo 屏幕上的麦克风、摄像头提示点，已经改由显示隔离区核对像素；核对不过，音频就不能离开隔离区。

Secure Exclaves 是苹果给摄像头和麦克风数据划出的一块独立运行环境。它跑在与主系统不同的处理器执行环境里，内核用的是苹果早前为安全隔离区处理器（SEP）这类高安全场景准备的 L4 定制版。进到里面的音视频，主操作系统读不到，App 读不到，苹果自己也读不到。

苹果安全研究博客的流程图：左侧是常开处理器，往右依次是音频隔离区、Siri 隔离区、隔离区指示控制器与显示隔离区，虚线框分出协处理器与安全隔离区两块；下半部分是主系统里的 Siri 守护进程、音频驱动与屏幕指示器，数字 1 到 11 标出 Hey Siri 的处理顺序 — 苹果安全研究博客配的流程图：左侧是常开处理器（Always-On Processor），往右依次是音频隔离区、Siri 隔离区、隔离区指示控制器与显示隔离区，虚线框把 Coprocessor 与 Secure Exclaves 圈成两块；下半部分是主系统（Main OS）里的 Siri 守护进程、音频驱动与屏幕指示器，图中 1 到 11 按顺序标出「Hey Siri」的处理路径。

一句话唤醒要走十一步

iPhone 18 Pro 从听到「Hey Siri」到把音频交给 Siri，中间有十一步，苹果在博客里逐步标了号。

最前面是常开处理器。它一直以低功耗状态听着环境里的声音，只做粗略的第一轮判断，不把完整录音交给主系统。初筛觉得可能听到了唤醒词，它才唤醒主处理器，把这段音频缓冲交给音频隔离区。

音频隔离区先做一遍回声消除，把语音弄干净，再交给 Siri 隔离区。Siri 隔离区跑的是更大、更精细的唤醒词模型，放在主处理器上跑，能滤掉的误报比常开处理器单独判断多得多。

确认之后，Siri 隔离区只给主系统里的 Siri 守护进程发一个唤醒标志，这时候音频一个字节都还没过去。守护进程向音频驱动请求麦克风，驱动调界面画出麦克风指示点，再向隔离区指示控制器（EIC）申请音频访问。

EIC 转头让安全显示隔离区去看屏幕，检查的是实际画上去的像素：颜色、形状、显示时长，与麦克风指示点该有的样子是否一致。这一关过了，系统才从环境模式切到主动模式，EIC 放行音频，Siri 隔离区把含「Hey Siri」的那段历史音频连同后续请求一起交给守护进程。指示点会亮到会话结束，最短三秒。

小圆点不是系统说画了就画了

在 iPhone 这种用屏幕指示点的设备上，光有 EIC 还不够，另有一个显示隔离区盯着那块像素。

它借显示子系统里的一块专用硬件，直接去看屏幕上画了什么，判断依据包括颜色、形状、显示时长，也包括像素有没有达到最低亮度阈值、有没有被邻近的像素挡住。系统自己报告「已经画了小圆点」，不构成放行理由。

夜览这类会改变屏幕观感的模式也被算进去了。显示控制器里的可信固件把精确的背光数值报给隔离区，隔离区据此判断这个点此刻是不是真的看得见。

苹果给这套机制定的目标写得很直白：不管攻击多复杂，传感器全开的时候，用户都要拿到一个清晰、可靠、无法被篡改的信号。指示点从提示变成了证据，靠的就是这层校验。

苹果支持文档示意图：一台 iPhone 的屏幕顶部，灵动岛里前置镜头右侧亮着橙色小圆点，左侧显示 09:41，右上角是信号、Wi-Fi 与电池图标 — 苹果支持文档里的示意图：一台 iPhone 的屏幕顶部，灵动岛里前置镜头的右侧亮着一个橙色小圆点，左侧显示 09:41，右上角依次是信号、Wi-Fi 与电池图标，机身下方衬着一块浅灰色背景。

常驻监听到底有没有在录

一台随时等着「Hey Siri」的手机，是不是一直在后台录音录像，是这套架构要回答的问题。

苹果把它分成两种模式。环境模式下，摄像头和麦克风的数据只在隔离区里处理，出来的只有元数据：有没有听到特定声音、有没有认出已登记的用户、人在哪个位置。原始画面和声音不进主系统，处理完就销毁。

要拿完整数据，必须切到主动模式，切过去的前提就是提示点亮起来并通过那层检查。

顺序决定了谁能看到什么：环境模式下主系统拿不到音视频，主动模式下拿得到，而那时候屏幕上一定有个点。

为什么没沿用硬连线指示灯

硬连线的 LED 指示灯好懂，苹果自己说它在隐私和安全的提示上一直很好用，可放到环境感知里就不合适了——它会一直亮着。

一直亮，等于没有指示。用户分不出设备是在背景里听着等唤醒词，还是真的在录音录像，这颗灯原本的作用就没了。

所以两类设备走了两条路。HomeView 这类用 LED 的，由 EIC 直接开关这颗灯，并保证亮度足够被看见。iPhone 这类用屏幕点的，多一道显示隔离区做像素校验。

同一个 EIC 还负责给同时申请音视频的多个应用排序，保证该出现的指示出现，不会因为抢资源被顶掉。

HomeView 认人，只往外报三个字段

Secure Exclaves 最先落地的场景是 HomeView。这台设备要随时判断视野里有没有人，又不能把摄像头画面交给系统。

启动时，认人隔离区从安全存储隔离区加载已登记的人脸与声纹模型，以及身份库。摄像头隔离区收到连续的画面帧，检测人脸、画出边框、排队等后续处理，然后告诉主系统的守护进程「可能有人」，画面数据不出隔离区。

麦克风这一路并行：音频先过音频隔离区做异常检测与回声消除，再交给认人隔离区。神经网络引擎用专门的隔离队列跑模型，每个模型跑完都把状态清掉。

最后，认人隔离区把结果与身份库比对，人脸与声纹合起来算一个置信度。回到主系统的只有三样：用户标识、位置、置信度。HomeView 最多能认六名已登记用户。

拿到这三样之后，日历、信息、Apple Music 这些功能才按人给出不同的内容，第三方音视频应用也可以调用。

HomeView 产品图：三台圆角方屏设备并排坐在织网布面扬声器底座上，从左到右分别是南瓜汤食谱、音乐播放与智能家居控制面板界面 — HomeView 的产品图：三台圆角方屏设备并排，机身坐在织网布面的扬声器底座上。左边一台显示「Butternut Squash Soup」的食谱界面，中间一台在播放「FEVER DREAM」的音乐，右边一台是智能家居控制面板，摆着灯、对讲、门锁与早安场景的方块按钮。

底下还有一层微内核

支撑这套隔离的，是苹果自己写的一个微内核，来自他们早前为安全隔离区处理器做的那套 L4 定制版本。

它用的是能力（capability）机制：组件默认没有任何权限，只有被明确授予某个能力，才能碰对应的资源。内存隔离与进程间通信都按这一套走。

隔离区之间的通信走一套叫 Secure IPC 的机制，用 Swift 写，为的是内存安全。它把接口描述语言和运行时绑在一起，只允许被授权的组件互相说话。每个通往主系统的接口都要单独审计，确认出去的只有跑通这个场景必需的那点元数据。

内存这一层由安全页表监控器（SPTM）管，它跑在比主系统内核更高的权限级上，不与主系统共享数据或代码，主系统内核也就读不到隔离区独占的那块内存。

苹果还给这个微内核做了形式化验证，用数学方法证明 C 实现符合一份抽象功能规范，工具是 Isabelle/HOL 与 AutoCorres2。文中说得很清楚：验证是逐步推进的，没有覆盖内核的全部部分。

这套架构落在哪些设备上，苹果列得很具体：iPhone 18 Pro、iPhone 18 Pro Max、iPhone Duo 的屏幕指示，MacBook Neo 与 HomeView 的摄像头指示，还有 HomeView 的认人、Apple Watch 上的 Siri Recap 与 Live Rewind。老款 iPhone 上的指示点会不会也改用这套机制，文中没有交代。