摘要：YellowKey 曝出的，不是 BitLocker 数学加密本身被破解，而是默认启动与恢复链路中的假设正在被重新审视。默认安全仍然重要，但它从来不等于充分安全。
很多人对笔记本安全有一个朴素判断：只要开了 BitLocker，硬盘就安全了。电脑丢了，别人拿到的也只是一块加密磁盘。没有恢复密钥，没有账号密码，没有 TPM 里的密钥，就不可能读出里面的数据。
但 YellowKey 这个新披露的零日漏洞，正是在挑战这个判断。
根据 Ars Technica 的报道，一个名为 YellowKey 的漏洞利用已经在网上流传。它针对的是 Windows 11 默认部署下的 BitLocker 保护模式：攻击者只要拥有设备的物理访问权限，就可能绕过正常的恢复密钥流程，在 Windows 恢复环境中获得对加密磁盘内容的访问。微软方面对 Ars 表示正在调查，但截至报道发出时，具体机制和官方修复方案仍不清晰。(极客公园)
这件事的冲击，不在于“BitLocker 被数学破解了”。更准确地说，BitLocker 的加密算法本身未必被攻破；真正出问题的，是默认启动和恢复链路中，密钥被释放、系统卷被解锁之后，攻击者可能借助某种异常路径拿到本不该拿到的命令行访问权。也就是说，问题不一定出在锁芯，而可能出在开门流程。
这正是企业安全中最容易被忽视的地方：我们总以为安全是一个功能开关，但真正的安全是一整条链路。
默认 BitLocker 为什么受欢迎，也为什么容易被高估
BitLocker 的默认体验之所以受欢迎，是因为它足够“无感”。许多 Windows 11 设备可以在 TPM 支持下自动启用设备加密。用户开机不需要额外输入 PIN，不需要插入启动密钥，系统照常启动，数据在静止状态下受保护。对大规模企业管理来说，这种模式很友好：部署简单、用户摩擦小、帮助台压力低。
但安全从来没有免费的午餐。TPM-only 模式的核心假设是：设备启动链路可信，TPM 会在合适条件下释放密钥，系统正常进入受保护环境。问题在于，一旦启动链路或恢复环境中出现绕行路径，攻击者就可能不需要“破解密码”，而是让机器自己把门打开。
YellowKey 可怕的地方就在这里。报道中提到，多个安全研究人员验证了该漏洞利用能够在默认 Windows 11 BitLocker 部署下生效；其相关行为似乎与 Windows 恢复环境、Transactional NTFS 以及某些特殊目录结构有关。Will Dormann 等研究者关注的重点是：为什么一个卷上的特定目录状态，可能影响另一个卷或恢复环境中的启动行为。这已经不是普通配置失误，而像是底层系统机制中的边界问题。(极客公园)
对普通用户来说，这可能听起来很遥远。但在真实世界里，物理访问并不罕见。笔记本丢在出租车上、员工电脑在出差途中被盗、离职人员带走设备、办公室设备被短暂接触、维修和供应链环节暴露，这些都属于物理访问风险。BitLocker 本来就是为了应对这类场景存在的：即使设备落入他人手里，硬盘数据也不该轻易暴露。
如果一个漏洞让“拿到机器”重新变成“拿到数据”的近似条件，那它就动摇了很多组织对终端加密的基本假设。
真正的问题不是“有没有加密”，而是默认链路能不能被绕过
更值得警惕的是，这类问题很容易被低估。很多企业的安全合规清单里，只会写一句“终端启用 BitLocker”。审计时也常常只看加密状态：是否启用、恢复密钥是否托管、设备是否合规。但 YellowKey 暴露出的，是“启用加密”与“具备足够防盗数据能力”之间的差距。
安全策略最怕这种半真半假的安心感。
从技术角度看，默认 BitLocker 主要保护的是“离线数据读取”。如果别人把硬盘拆下来，放到另一台机器上，因为密钥绑定在原设备 TPM 中，通常无法直接解密。但 YellowKey 这类攻击的思路并不是把硬盘拿走破解，而是利用原设备本身、原启动环境、原密钥释放流程来绕过控制。也就是说，攻击者利用的不是外部算力，而是设备自己的信任链。
这也是为什么安全行业长期建议，高风险设备不要只依赖 TPM-only，而应启用预启动身份验证，比如 TPM + PIN 或启动密钥。微软官方文档也说明，BitLocker 可以在 TPM 之外要求用户在正常启动前提供 PIN 或插入包含启动密钥的可移动设备，从而形成额外认证层；预启动认证的目的，就是在系统盘内容可访问前增加人为输入条件。(微软学习)
但现实问题是，TPM + PIN 并不总是容易推广。它会增加用户操作成本，也会增加忘记 PIN、远程支持、批量部署和设备恢复的管理复杂度。微软 Intune 文档也提到，静默 BitLocker 加密若要顺利工作，设备通常不能要求 TPM 启动 PIN 或启动密钥，因为这些都需要用户交互。(微软学习)
这就是企业安全的典型矛盾：越安全，越麻烦；越无感，越依赖默认链路不出问题。
对企业来说，这不是单个漏洞，而是终端分级和应急流程问题
YellowKey 事件提醒我们，安全策略不能只围绕“最低摩擦”设计。对于普通办公电脑，默认 BitLocker 或许仍然能抵御大量低级风险；但对于研发人员、财务、人力、法务、高管、涉密项目成员、政府承包商、工程源代码和客户数据终端，单纯 TPM-only 已经不应该被视为足够强的保护。
企业需要做的第一件事，是重新给终端分级。不是所有电脑都需要同一套策略。普通低敏设备可以保持低摩擦配置，高敏设备则应该启用更强的预启动保护、限制外部启动、锁定 UEFI/BIOS 设置、禁用不必要的恢复入口、加强设备丢失后的快速响应。安全不是平均主义，而是风险分层。
第二件事，是把“物理访问”重新纳入威胁模型。很多组织默认把攻击想象成网络入侵、钓鱼邮件、恶意软件、凭证泄露，却忽视了设备丢失本身就是数据泄露入口。终端加密不是摆设，它是最后一道防线。如果最后一道防线依赖默认配置，而默认配置出现零日绕过，那么资产清单、设备定位、远程擦除、密钥轮换、凭证吊销都要同步纳入应急流程。
第三件事，是不要把 BIOS 密码、Secure Boot、启动顺序控制、USB 启动限制等当成“老派设置”。这些措施无法替代系统补丁，也不一定能单独阻止所有变种，但它们会提高物理攻击成本。尤其是在企业环境中，攻击链往往不是一招定胜负，而是多个小缺口叠加。减少外部介质启动机会、减少恢复环境被滥用机会，本身就是降低风险的一部分。
第四件事，是密切关注微软后续修复和缓解建议。当前 YellowKey 仍处在信息快速变化阶段，不同媒体对影响范围、变种和防护效果的描述并不完全一致。例如 Tom’s Hardware 报道中提到研究者声称还有针对 TPM+PIN 场景的未公开变体，但这类说法尚需等待更多独立验证和微软官方说明。(Tom’s Hardware)
这类零日最麻烦的地方，就是“公开利用”会迅速改变风险曲线。SecurityWeek 对此类公开零日的评价很准确：一旦 PoC 出现，攻击者就有了可测试、可修改、可整合进更大攻击链的起点。即使漏洞利用有物理访问门槛，它也不再只是理论问题。(SecurityWeek)
“已经开了 BitLocker”，不等于可以放心
对个人用户来说，最实际的建议是：首先确保 Windows 和固件更新保持最新；其次，重要设备不要随意离身；再次，备份好 BitLocker 恢复密钥；如果你的设备保存大量敏感资料，可以考虑启用更强的启动保护，哪怕这会带来一点麻烦。便利和安全之间，没有永远免费的默认答案。
对企业来说，则应该尽快做一次自查：哪些设备启用了 BitLocker？哪些只是 TPM-only？哪些属于高敏岗位？哪些允许 USB 启动？哪些设备的恢复密钥是否安全托管？丢失设备的处置流程是否包括账号吊销、会话失效、远程擦除和日志追踪？如果这些问题答不上来，YellowKey 即使最后被补丁修复，也只是暴露了更大的管理盲区。
这件事最重要的启示，不是“BitLocker 不可信”，而是“默认安全不等于充分安全”。
现代操作系统为了普及安全，越来越倾向于把加密、防护和身份验证做成默认开启。这当然是进步。没有默认加密的时代，普通用户和企业终端暴露得更彻底。但默认配置的目标，是覆盖最大多数人的最低安全线，不是替高风险组织完成威胁建模。
YellowKey 就像一记提醒：安全从来不是一个开关，而是一组假设。只要攻击者能绕过其中一个假设，整个保护效果就可能从“看起来很强”变成“意外脆弱”。
过去我们说，电脑丢了没关系，硬盘加密了。现在可能要补上一句：加密了，但你用的是哪种启动保护？恢复环境能不能被滥用？外部介质能不能参与启动？TPM 释放密钥前有没有第二因素？设备丢失后多久能触发应急流程？
在 AI、云和远程办公时代，很多企业把注意力放在云端权限、模型安全和网络边界上，却忘了最传统的终端仍然是数据的最后容器。一个笔记本、一块硬盘、一个恢复环境漏洞，仍然可能打开整个组织的敏感资料。
YellowKey 的真正价值，可能不只是让微软修一个漏洞，而是让所有人重新审视那句过于轻松的安全承诺：
“放心，已经开了 BitLocker。”