这里有一个非常好的stackoverflow答案，它涵盖了创建自签名CA，然后使用获得的证书签署可执行文件的内容：如何在Windows上创建自签名证书进行代码签名？。
我已经阅读了很多关于驱动程序签名工作原理的讨论，并且答案似乎几乎毫无疑问，如果没有启用测试模式，则无法加载未签名或自签名的驱动程序。但是，我链接的答案，特别是Roger Lipscombe的一条评论，似乎提供了相反的观点：
“如果要用这个来签名驱动程序，您需要将CA证书导入机器存储区。我的示例将其导入用户存储区，对于大多数软件来说，这是可以接受的，用于测试/内部目的。”
对我来说，只要将CA证书导入机器存储区，我就能够安装带有自签名证书（由自签名CA签发）的驱动程序，而无需对系统进行任何其他更改（通过按F8禁用测试模式，在启动菜单中， messing with boot configuration flags such as TESTSIGNING or NOINTEGRITYCHECKS等）。我正确吗？ 如果需要加载没有适当数字签名的驱动程序（例如旧打印机驱动程序等），为什么不更广泛地使用此方法，而是依赖测试模式或第三方软件（DSEO）来篡改系统文件来运行此类驱动程序？
这种方法的缺点是什么？ 上述SO问题中描述的过程需要管理员权限，但是安装驱动程序应该需要这些权限。信任自签名CA可能存在安全风险-但是禁用所有签名检查是否会带来更大的安全风险？
如果将自签名CA根证书导入到机器存储中，我是否可以在64位Windows上安装未经测试模式的自签名驱动程序？
30
- user130496
5
2好问题。MSDN 签署设备驱动程序包的步骤也指出，只要时间戳正确，自签名驱动程序可以通过这种方式安装。 - user743382
1@hvd 感谢提供的链接。不过它确实说“此部分创建和使用的证书仅可用于 32 位 Windows 版本上的 32 位驱动程序”，并且还提供了一个链接，其中包含以下声明：“Windows 7 和 Windows Server 2008 R2 的 64 位版本对内核模式设备驱动程序有特殊签名要求。如果您使用的是 64 位 Windows 版本，则无法创建自己的签名证书。相反，您必须使用链到经批准的认证机构（CA）的软件发布证书。”也许这是不可能的？ - user130496
3在64位系统上，您必须交叉签名您的驱动程序，因此无法进行自我签名。 - Luke
1看起来是这样的。如果有人费心写一个清晰描述情况并带有适当参考资料的答案，我会接受它。 - user130496
相关链接：https://dev59.com/oGw05IYBdhLWcg3wiybg - ivan_pozdeev
4个回答
30
很遗憾，从Windows Vista和Windows Server 2008开始，这是不可能的。驱动程序必须是交叉签名的。创建自己的CA并将其添加到机器存储区域不够，因为新创建的CA不会被Windows信任链所信任。
Windows的驱动程序签名要求。在Windows Vista和Windows Server 2008中，新功能利用代码签名技术，并且操作系统中的新安全要求强制使用数字签名来执行某些类型的代码。组件必须由Windows可信赖的证书签名，如本站上的白皮书中所述。其中之一所提到的白皮书是Windows内核模块的数字签名，其中描述了加载过程并解释了为什么自我签名不足够。当驱动程序加载到内核存储器中时，Windows Vista会验证驱动程序映像文件的数字签名。根据驱动程序的类型，这可以是目录文件中的已签名哈希值或图像文件本身中的嵌入式签名。签署内核驱动程序包时使用的交叉证书用于加载时的签名验证；在内核中检查每个路径中的证书，直到到达受信任的根位置。加载时签名检查无法访问可信任的根证书颁发机构证书存储区域。相反，它必须依赖于内置到Windows Vista内核中的根权限。正如前面提到的，在设备驱动程序签名和分段的要求页面上也概述了这一点：
Windows 7和Windows Server 2008 R2的64位版本对内核模式设备驱动程序有特殊的签名要求。如果您使用64位版Windows，则不能创建自己的证书进行签名。
您必须使用链接到经过批准的认证机构（CA）的软件发布证书来进行签名。
用于签署内核模式驱动程序的有效CA可以在以下页面找到：
- user1704650
1
实际上它们是有效的，您可以检查libusb-win32，它们正是这样做的，自签名驱动程序可以毫无问题地工作... - Gusman
1
用户模式驱动程序可在 Windows 10 X64 上使用安全启动和自签名证书，只需将证书添加到受信任的根 CA 中。内核模式驱动程序仅与付费的微软受信任根CA一起工作。
- Péter Major
0
进一步扩展Péter Major的回答，还有另一种情况可以通过自签名来推断一些东西：内核模式驱动程序已经具有有效的签名，但您希望将其与不同的INF文件重用。
您仍然需要像通常使用测试签名一样导入您自己的证书，但是这里的关键是：在“驱动程序包”中的所有文件在安装时进行的签名检查实际上与仅仅在内核中加载.sys代码的独立（尽管这两个角色通常由一个单独的目录文件同时完成）。微软并没有特别强调这种差异（因为所有生产目的都应该依赖官方的信任链），但如果您足够绝望，它仍然提供了一个有意义的替代“测试模式”的选择。
你可以在libwdi中看到这项技术的运作方式，就像在Win-Raid的修改过的存储驱动程序中一样。他们无法触及驱动程序二进制文件的任何位，但这已足够定制设置信息，以消除操作系统版本锁定或重新定位不同的硬件。
这在每次启动驱动程序时都是可能的（因为它们都必须携带自己的嵌入式签名）。然而，当驱动程序签名仅存在于.cat文件中时，目前尚不清楚可以采取什么措施，也就是说，您应该重新生成/覆盖的正是您自己的签名文件（而且一个没有软件包的安装是什么鬼？）。大卫·格雷森在他的杰作解析中似乎暗示模块加载检查不仅针对“源软件包”的凭据进行，而且还针对系统中当前安装的所有凭据进行，所以...我不知道，也许可以通过多个软件包来玩一些把戏（一个软件包用原始驱动程序及其原始验证哈希值，然后另一个软件包用我们创建的任何奇怪的INF文件）？或者也许可以通过临时启用测试模式来解决staging困境？但是我的大脑太小了，无法解决这个难题。 p.s. 值得注意的是，这里的一切可能会或可能不会受到后来的Windows 10中的安全启动的负面影响，就像S模式或运行ARM版本一样。更严格的安全性可能只是含糊地意味着他们在开箱即用时信任的发布商/机构更少（但您仍然可以最终添加您自己，就像我刚才描述的那样），或者实际上可能是对证书存储的完全封锁，使操作与KMCS处于相同的地位。
您仍然需要像通常使用测试签名一样导入您自己的证书，但是这里的关键是：在“驱动程序包”中的所有文件在安装时进行的签名检查实际上与仅仅在内核中加载.sys代码的独立（尽管这两个角色通常由一个单独的目录文件同时完成）。微软并没有特别强调这种差异（因为所有生产目的都应该依赖官方的信任链），但如果您足够绝望，它仍然提供了一个有意义的替代“测试模式”的选择。
你可以在libwdi中看到这项技术的运作方式，就像在Win-Raid的修改过的存储驱动程序中一样。他们无法触及驱动程序二进制文件的任何位，但这已足够定制设置信息，以消除操作系统版本锁定或重新定位不同的硬件。
这在每次启动驱动程序时都是可能的（因为它们都必须携带自己的嵌入式签名）。然而，当驱动程序签名仅存在于.cat文件中时，目前尚不清楚可以采取什么措施，也就是说，您应该重新生成/覆盖的正是您自己的签名文件（而且一个没有软件包的安装是什么鬼？）。大卫·格雷森在他的杰作解析中似乎暗示模块加载检查不仅针对“源软件包”的凭据进行，而且还针对系统中当前安装的所有凭据进行，所以...我不知道，也许可以通过多个软件包来玩一些把戏（一个软件包用原始驱动程序及其原始验证哈希值，然后另一个软件包用我们创建的任何奇怪的INF文件）？或者也许可以通过临时启用测试模式来解决staging困境？但是我的大脑太小了，无法解决这个难题。 p.s. 值得注意的是，这里的一切可能会或可能不会受到后来的Windows 10中的安全启动的负面影响，就像S模式或运行ARM版本一样。更严格的安全性可能只是含糊地意味着他们在开箱即用时信任的发布商/机构更少（但您仍然可以最终添加您自己，就像我刚才描述的那样），或者实际上可能是对证书存储的完全封锁，使操作与KMCS处于相同的地位。
- mirh
-1
你是正确的，如果你创建了一个自签名证书并将其保存在用户存储区（或机器存储区）作为受信任的 CA，它将对你有用...但请记住：
- 安全启动将无法为您工作。
- 这是一种安全漏洞，如果有人掌握了证书，他们将必须在您的系统上运行内核模式代码。
其他选择是从GoDaddy购买受信任的代码签名证书 :)
- Baget
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接