FileVault 加密磁盘引导不依赖独立解锁界面，而是通过固件级验证（Secure Enclave/T2/EFI校验Recovery HD与签名）、系统级解密（内核调用apfs_encrypt模块，登录触发PBKDF2派生密钥）和用户级登录（仅授权账户可解密，需禁用自动登录）三重协同完成，全过程静默透明。
FileVault 加密磁盘的引导过程不依赖单独的“加密解锁界面”，而是深度融入 macOS 启动链，靠三重认证协同完成：固件级验证、系统级解密、用户级登录。它不是“先输密码再进系统”，而是把密码验证拆解到不同阶段，由硬件与软件分层协作。
启动时的固件与 Recovery HD 验证
Mac 开机后，Apple Silicon 或 Intel 的固件（Secure Enclave / T2 芯片或 EFI）首先校验 Recovery HD 是否完整可信，并确认启动卷签名有效。若 Recovery HD 缺失或损坏（如被误删或位于外置盘），FileVault 将无法激活——因为解密密钥部分托管在 Recovery 环境中，且启动流程需调用其内建的 CoreStorage 或 APFS 解密模块。
- Apple Silicon Mac：Secure Enclave 在 Boot ROM 阶段即参与密钥封装，用户密码不会明文传递给系统，仅用于解锁存储在 Secure Enclave 中的类密钥（Class Key）
- Intel Mac（含 T2）：固件密码 + FileVault 组合生效；若未设固件密码，攻击者可能通过恢复模式绕过登录直接挂载加密卷（除非已启用固件锁）
登录前的透明解密触发
系统加载内核与驱动后，APFS 卷识别到 FileVault 已启用，会暂停用户空间启动，转而调用内核扩展 apfs_encrypt 和 corecrypto 模块。此时并不弹窗，而是等待首个合法用户账户完成登录认证——该登录动作实际触发了密钥派生（PBKDF2 衍生出 Volume Key），进而解密 APFS 容器元数据，使系统能读取 /System、/Users 等路径。
- 密码输入发生在图形登录界面（loginwindow），但解密操作在内核态静默完成，用户无感知
- 若使用 iCloud 恢复密钥，该密钥仅在首次登录失败且连续输错多次后才被尝试调用（需联网并验证 Apple ID）
- 自动登录功能必须关闭，否则登录环节被跳过，解密无法触发，系统将卡在灰屏或报错“无法访问启动磁盘”
多用户环境下的密钥授权机制
FileVault 不是“全盘一把锁”，而是为每个获授权用户生成独立的密钥封装副本（Wrapped Volume Key）。这些副本均存于 /var/db/FileVaultPRK.db，由各自账户密码保护。只有被明确启用 FileVault 解锁权限的账户，才能在启动或唤醒时解密整个卷。
- 新增管理员账户后，默认不具备解锁权限；需在「系统设置 > 隐私与安全性 > 文件保险箱」中点击“+”添加，系统会重新封装一份密钥
- 被移除的授权用户，其密钥副本会被安全擦除，不再能参与解密流程
- 若所有授权账户密码遗忘且无恢复密钥，数据不可恢复——Apple 无法介入，这是设计上的安全边界
加密状态与启动行为的联动表现
FileVault 是否真正生效，不能只看设置界面显示“已开启”。实际引导中，以下现象可佐证认证逻辑正常运行：
- 重启后首次登录前，屏幕左下角短暂显示小锁图标（macOS 13+），表示正在解密卷头
- 登录成功后，菜单栏右上角出现常驻锁形图标，悬停可见“已解锁”及加密进度（100% 表示元数据解密完成，文件内容实时加解密）
- 若启动时插入外置启动盘，而主盘启用 FileVault 且固件锁已设，则该外置盘无法引导——因为固件拒绝加载未签名或非授权的启动环境
