Hello,
As by now you probably know - starting Windows Vista (and in Windows 7 and Windows 8) Microsoft decided on strictly controlling software publisher's that are able to load their code at kernel mode on Windows 7 operating system. To me this decision seems strictly driven by their wish to improve overall system stability (or did we enjoy those wonderful blue screens? :)) and security. Official statement is: "Windows Vista and later versions of Windows rely on digital signatures of these components to increase the safety and stability of the Microsoft Windows platform and enable new customer experiences with next generation premium content."
To home users this causes some concerns, especially if their favourite piece of software is not available! But thankfully there are workarounds.
The best way to solve issues with unsigned drivers is to use the tool provided by http://www.ngohq.com/ - Driver Signature Enforcement Overrider.
Thorough documentation and guides are available both on the website and in user interface.
Pros: Quick to setup, saves you a lot of manual steps
Cons: System wide setting, possible security and system stability risk
Now, if we're talking about corporate, managed environments when you want to make sure software does not impose a risk to infrastructure, system stability and want to remove user interaction when distributing software - it's more complicated.
Let's dig into how this looks on the practical side of things! As an example I'll review a popular application that includes a kernel-mode driver - ATITool from techpowerup.
During installation you receive the following notification: "Windows can't verify the publisher of this driver software".
If you select to "Install this driver software anyway" and navigate to %windir%\inf\setupapi.dev.txt
First thing we need to determine if this is a kernel-mode driver (A possible (but not the only one) hint to why it is kernel-mode is it's location in %systemroot%\System32\drivers). We can also check the list in MsInfo32.exe - > Software Environment - > System Drivers
A solution would be to sign the driver using a third party or self-generated certificate, but, regrettably, this has a limitation - kernel-mode binaries must always be signed using Software Publisher Certificate AND "The SPC is obtained from a third-party certificate authority (CA) that is authorized by Microsoft to issue such certificates".
Efficiently translating into - you cannot use a self-generated Software Publisher Certificate for this!
This is a "bit" confusing, but if you're interested, here's a further read - As an additional step involved in signing kernel-mode binaries a Cross-Certificate is used. Cross-Certificates for Kernel Mode Code Signing
In case the driver is not kernel-mode, things get a lot more simple to manage! The following guide will walk you through all steps needed to sign drivers (generating certificates and pre-configuring those certificates on clients PCs) - Guide to signing unsigned drivers
Further reads:
Driver Signing Requirements for Windows
http://msdn.microsoft.com/en-us/windows/hardware/gg487317.aspx
PnP Device Installation Signing Requirements (Windows Vista and Later)
http://msdn.microsoft.com/en-us/library/windows/hardware/ff549724(v=vs.85).aspx
Kernel-Mode Code Signing Policy (Windows Vista and Later)
http://msdn.microsoft.com/en-us/library/windows/hardware/ff548231(v=vs.85).aspx
Kernel-Mode Code Signing Requirements (Windows Vista and Later)
http://msdn.microsoft.com/en-us/library/windows/hardware/ff548239(v=vs.85).aspx
Cross-Certificates for Kernel Mode Code Signing
http://msdn.microsoft.com/en-us/windows/hardware/gg487315.aspx
CM_PROB_UNSIGNED_DRIVER
http://msdn.microsoft.com/en-us/library/windows/hardware/ff539108(v=vs.85).aspx
How to Release-Sign a Driver Package
http://msdn.microsoft.com/en-us/library/windows/hardware/ff546234(v=vs.85).aspx