Secure Enclave 通过硬件级密钥隔离实现 macOS 磁盘加密安全，VEK 始终驻留其独立内存，主系统无法访问；启动时验证固件完整性后瞬时解封密钥，Target Disk Mode 和恢复模式均需有效凭证才能解密，无后门可绕过。
macOS 磁盘加密后的固件锁定与硬件安全性机制，核心不在“固件被锁”，而在于Secure Enclave（安全隔区）对密钥的硬隔离管控——它不修改固件行为，而是让加密密钥从不出现在主系统内存中，从根本上切断物理提取路径。
Secure Enclave 是真正的硬件守门人
在 Apple silicon Mac 上，FileVault 的卷加密密钥（VEK）由 Secure Enclave 生成并全程驻留其独立内存与加密引擎内。主 CPU 和 macOS 内核无法读取、复制或导出该密钥，即使系统已被完全攻破或进入恢复模式，密钥也不会暴露。启动时，Secure Enclave 先验证 Boot ROM 和系统固件完整性，确认无篡改后，才临时解封 VEK 用于解密启动卷。这个过程是单向、瞬时、芯片级的。
所谓“固件锁定”其实是访问策略生效
用户感知到的“无法挂载”“拒绝引导”等现象，并非固件本身被写保护或禁用，而是以下机制协同作用的结果：
- Secure Enclave 拒绝向未通过认证的执行环境释放密钥
- 启动流程中，Recovery OS 或 Target Disk Mode 下若缺少有效凭证（密码或恢复密钥），系统不会触发密钥解封，卷保持加密态、不可读
- BIOS/UEFI 层面无传统 PC 式的“管理员密码锁”，但 Apple 芯片通过 localpolicy 文件强制签名验证，阻止未签名固件加载
Target Disk Mode 与物理访问防护的实际边界
启用 FileVault 后，将 Mac 以 Target Disk Mode 连接到另一台设备，对方看到的是一个加密块设备（如 disk2s1），而非可浏览的文件系统：
- 没有密码，无法挂载；输入错误密码超过限定次数后，Secure Enclave 可能延迟响应或临时冻结密钥访问
- 即使使用 Linux 或 Windows 主机尝试暴力读取原始扇区，得到的也只是 AES 加密的乱码数据，无 VEK 就无法还原
- 旧款 Intel Mac 的 T2 芯片同样实现类似隔离，但 Apple silicon 的集成度更高、攻击面更小
恢复模式下的密钥访问受严格上下文约束
macOS 恢复环境（RecoveryOS）虽拥有更高权限，但仍需满足以下任一条件才能访问加密卷：
- 当前登录用户已解锁钥匙串且处于活跃会话中（自动提供密钥）
- 手动输入正确的账户密码（用于派生 KEK，再解封 VEK）
- 输入 24 位恢复密钥（它是 VEK 的另一份加密副本，由初始设置时生成）
不存在绕过这些凭证的“固件后门”或调试接口——Apple silicon 的 Secure Enclave 不开放密钥导出通道，这是硬件设计决定的安全底线。
