Can I install self-signed drivers on 64-bit Windows without test mode if the self-signed CA root certificate is imported to the machine store?

Question

Here is a great SO answer which covers the creation of self-signed CA and then signing executables with the obtained certificates: How do I create a self-signed certificate for code signing on Windows?.

I have read a lot of discussions online on how the driver signing works and the answer seems to be almost unequivocally that you can't load unsigned or self-signed drivers without having the test mode enabled. However, the answer I linked to and especially one comment by Roger Lipscombe seems to provide a contradicting view:

If you want to use this for signing drivers, you need to import the CA certificate into the machine store. My example imports it into the user store, which is fine for most software, for test/internal purposes.

To me, it looks like I would be able to install drivers with self-signed certificates (issued by a self-signed CA) as long as the CA cert was imported to the machine store. I won't have to make any other changes to the system (disabling test mode by pressing F8 on boot menu, messing with boot configuration flags such as TESTSIGNING or NOINTEGRITYCHECKS).

Am I correct? What are the obstacles, if any, that this method is not used more widely when people need to load drivers that have no proper digital signatures provided (such as old printer drivers etc.). Instead, people rely on booting to test mode or a third-party software (DSEO) which tampers with your system files to run such drivers.

What are the drawbacks of this method? The process described in the above SO question needs admin privileges but installing drivers should need them anyway. Trusting a self-signed CA might be a security risk - but won't disabling all signature checks be even bigger security risk?

Answer 1

To expand on Péter Major answer, there's also another case where you can sort-of kinda conclude something with self-signing: kernel-mode drivers already having a valid signature, but that you want to reuse with a different INF file.

You still have to import your own certificates, just like you'd normally go with test-signing, but here's the deal: the signature check that happens at install time to all the files in a "driver package", is actually independent from that specific to just loading the .sys code in the kernel (despite both roles often being fulfilled together by one single catalog file). Microsoft doesn't particularly underline this difference (since all production purposes are supposed to piggyback the official chain of trust anyway) but if you are desperate enough it still provides a meaningful alternative to "test mode" proper.

And you can see the technique working in libwdi, just like in Win-Raid's modded storage drivers. They cannot touch even a single bit of the driver binaries themselves, but this is still enough to customize the setup information to remove OS version locks or re-target different hardware.

And this is granted to be always possible with every boot-start driver (since they must all carry their own embedded signature). It's unclear though what could be done when the driver signature is only inside the .cat file, i.e. the very same thing that you should re-generate/overwrite with your own (also what the hell is an installation without a package?). David Grayson in his masterpiece dissection seems to suggest that the module load checks don't just happen against the "source package" credentials, but all the ones currently installed in the system, so.. I don't know, perhaps it might be possible to play some trick with multiple packages (one shoehorning the original driver with its pristine validated hash, and then another with whatever wack INF we created)? Or maybe the staging dilemma could be worked around just by temporarily enabling test mode? But my brain is too small to try to also figure out this puzzle.

p.s. of note that everything here might or might not be negatively influenced by Secure Boot in later Windows 10, just like by S mode or running an ARM build. The stricter security may just ambiguously mean that they have fewer publishers/authorities that they trust out-of-box (but you can still add yours eventually, similarly to what I just described) or it may in fact be a complete lock down on the certificate stores, putting the operation much on the same footing of KMCS.

Answer 2

User mode drivers will work on Windows 10 X64 with secure boot and everything with self signed certs as long as you add the cert to the Trusted Root CAs. Kerner mode drivers only work with paid MS trusted root CAs.

Answer 3

No, this is unfortunately not possible, starting from Windows Vista and Windows Server 2008.

The driver has to be cross-signed. Creating your own CA and adding it to the machine store won't be enough because the newly created CA won't be trusted by the Windows chain of trust.

Driver Signing Requirements for Windows

In Windows Vista and Windows Server 2008, new features take advantage of code-signing technologies, and new requirements for security in the operating system enforce the use of digital signatures for some kinds of code.

Components must be signed by a certificate that Windows "trusts" as described in the white papers on this site.

One of the white papers referred is Digital Signatures for Kernel Modules on Windows which describes the load process and explains why self-signing won't be sufficient:

When a driver is loaded into kernel memory, Windows Vista verifies the digital signature of the driver image file. Depending on the type of driver, this can be either the signed hash value in the catalog file or an embedded signature in the image file itself. The cross-certificates that are used when signing the kernel driver package are used for the load-time signature verification; each certificate in the path is checked up to a trusted root in the kernel. The load-time signature check does not have access to the Trusted Root Certificate Authorities certificate store. Instead, it must depend on the root authorities that are built into the Windows Vista kernel.

As mentioned earlier, this is also outlined on the Requirements for Device Driver Signing and Staging page:

The 64-bit versions of Windows 7 and Windows Server 2008 R2 have special signature requirements for kernel mode device drivers. If you use a 64-bit version of Windows, then you cannot create your own certificate for signing. Instead, you must use a Software Publishing Certificate that chains to an approved certification authority (CA).

The valid CAs for signing kernel mode drivers can be found on the following page:

Cross-Certificates for Kernel Mode Code Signing

Answer 4

you are correct, if you create a self signed certificate and save it in user store (or machien store) as a Trusted CA, it will work for you... but keep in mind that:

1. Secure boot will not work for you.
2. This is a security breach, if someone get a hold of the certificate, they will have to run kernel mode code on your system.

Other option, is to buy Trusted Code Signing Certificate from GoDaddy :)