基于Windows的操作系统不再是移动环境中的默认和首要选择。Android的开放源性质已在OEM中吸引了许多粉丝，因此，如今越来越少的手机使用Windows。但是，如果您属于仍在日常生活中继续使用Windows设备的人群，那么您会发现一些新闻。是好是坏，这取决于您的立场和对本新闻用例的解释。
根据Ars Technica 和TheRegister 的报道，该新闻来自网站，这可能会让您头疼(不要开玩笑)，一些开发人员(@never_released和@ TheWack0lian)发现，Microsoft为调试目的而生的后门已经开启了在Windows设备上禁用安全启动的可能性。
安全启动，这是什么?
首次启动Windows设备时，启动过程按以下一般顺序进行：UEFI(统一可扩展固件接口，它是BIOS的替代品)->引导管理器->引导加载程序-> Windows。UEFI是存在安全启动功能的地方。顾名思义，它与Secure Boot结合使用，旨在通过在后续步骤中要求数字签名来提高安全性。本质上，如果未使用UEFI期望使用的密钥对引导加载程序进行签名，则引导设备的过程将无法完成。
安全启动是一项可选功能，但是Microsoft已强制启用它，以便从Windows 8及更高版本获得Windows认证。这样做的理由是，安全启动会使恶意软件作者难以在启动过程中插入代码。但是，安全启动的一个副作用是，它使在Windows机器上进行双重引导有点复杂，因为第二个操作系统及其所有必备组件也都需要进行数字签名，否则就需要禁用安全启动。 。这还有很多其他问题，经验丰富的双启动器对它们的了解要比我在一段中所能解释的更多。
现在，有些设备即使用户愿意也无法禁用安全启动。在这个领域中，我们的主题从所有Windows设备(包括台式机)急剧缩小到特定的Windows设备，例如Windows Phone设备，Windows RT设备，某些Surface设备甚至HoloLens。这些最终用户设备已锁定了安全启动，这意味着最终用户无法修改或禁用与安全启动相关的方面，并且通过扩展，他们无法以Microsoft未经授权的方式接触最终用户的操作系统。
但是出于正在进行的官方开发目的，安全启动需要放宽一点。在安全启动已锁定的设备上，存在安全启动策略，可以帮助进行授权开发而无需禁用安全启动。正如研究用户所提到的，此安全启动策略文件是在Windows的启动过程中由启动管理器加载的。策略文件还可以包含注册表规则，注册表规则又可以包含策略本身的配置等。同样，必须对策略文件进行签名，并且存在其他适当的设置以确保只有Microsoft可以设置这些更改。
签名元素还依赖于所谓的DeviceID，该ID在应用时使用。我将在此处让博客文章进行解释，因为其中有些部分对我来说不太清楚：
另外，还有一个叫做DeviceID的东西。它是某些UEFI PRNG输出的盐化SHA-256哈希的前64位。在Windows Phone和Windows RT上应用策略时使用它(mobilestartup在Phone上设置它，并在RT上首次启动时在SecureBootDebug.efi上设置它)。
在电话上，该策略必须位于EFIESP分区上的特定位置，其文件名包括DeviceID的十六进制形式。(使用Redstone，它已更改为UnlockID，由bootmgr设置，并且只是原始UEFI PRNG输出)。
基本上，bootmgr会在加载策略时检查该策略，如果它包含与运行bootmgr的设备的DeviceID不匹配的DeviceID，则该策略将无法加载。任何允许启用测试签名的策略(MS都将其称为“零售设备解锁/ RDU策略”，并且安装它们是为了解锁设备)，都应锁定为DeviceID(在Redstone及更高版本上为UnlockID)。确实，我有几个类似的策略(由Windows Phone生产证书签名)，其中唯一的区别是包括的DeviceID和签名。如果没有安装有效的策略，bootmgr将退回到使用位于其资源中的默认策略。此策略是使用BCD规则阻止启用测试签名等的策略。
这是事情变得有趣的部分。在Windows 10 v1607的开发过程中，Microsoft为内部测试和调试目的创建了一种新型的安全启动策略(为简便起见，下文简称为SBP)。该策略本质上是“补充的”，不存在DeviceID，并且会导致其设置被合并到现有的启动策略中。引导管理器加载较旧类型的SBP，然后验证其签名和真实性，然后加载这些补充引导策略。这里的问题是补充政策本身没有进一步的验证。此外，早于Windows 10 v1511的启动管理器也不知道这些策略的补充性质是否存在，因此会做出反应，就好像它们加载了完全有效且经过签名的策略一样。同样，这种行为很可能是内部开发的结果，因此开发人员不必对每个操作系统版本都进行签名，而不必在设备上进行小的更改。
此SBP被称为“金钥匙”，因为它基本上使签名检查的目的无效。尽管此SBP处于停用状态，但无意中将其运输到零售设备上。开发人员找到了此SBP，并告知了他们的发现。现在，可以在Internet上找到 SBP 了，该特定的zip用于在Windows RT设备上安装SBP。
这是什么意思?
如果加载了补充SBP，则可以为Windows启用测试签名，以允许您加载未签名的驱动程序。此外，由于这些策略在引导过程的引导管理器阶段之前起作用，因此您可以损害整个订单的安全性并运行未经授权的(读取自签名)代码。这给打算修改授权范围以外的Windows部分的用户以及恶意软件创建者都提供了很多可能性。
这一发现的作者集中于整个惨败的讽刺。Microsoft锁定了某些设备上的安全启动，以防止未经授权的更改，但是它内置了一个后门，可以让它们继续进行开发和调试。但是，这种后门为在所有运行Windows的设备上禁用安全启动铺平了道路，使整个过程变得毫无意义。
现在，不愿意的用户不仅可以在仅Windows的平板电脑和手机上安装Linux发行版(甚至可以在Android上)，不愿意的用户还可以通过破坏对设备的物理访问来安装恶意的引导程序。尽管前者是我们可以跃跃欲试的事情，但后者并没有真正灌输很多信心。这是双向的，它向我们展示了为什么安全是一把双刃剑。此外，SBP本质上是通用的，无论其体系结构如何，都可以在任何设备上使用。对于可以轻松关闭安全启动的台式机来说，它并不是特别有用，但是对于您不能随意使用安全启动的设备来说，它的作用范围很大。
那么，解决方法是什么?
微软确实发布了一些补丁，但开发人员坚持认为该问题尚未完全解决。您可以检出这些修补程序(MS16-094和MS16-100)，然后在博客文章本身上阅读它们为什么不能解决问题的信息。如果它们是正确的，则此问题尚无解决方法或修补程序，尽管这不会阻止Microsoft尝试在路上设置更多的障碍。
接下来是什么?
有很多可能性，其中一些正在我们的Windows论坛上酝酿。您可以查看有关Windows Phone 8开发和黑客的论坛以及有关Windows 8，Windows RT和Surface开发和黑客的论坛。您还可以在其他用户正在讨论的某些设备上找到指令线程。
此调试后门的存在和SBP的泄漏不仅对于锁定Windows设备的第三方开发很重要，而且还向我们显示了一个严峻的提示：如果留有故意的后门会发生什么。最近对安全的关注已转向调查机构，要求存在此类后门以协助其合法调查目的。但是这些方法迟早会落入错误的手中。原本打算用作打击和司法协助的工具，后来有一天将成为本身的工具。
