How to sign drivers in Windows step by step

Signing a driver in Windows might seem, at first glance, like something only highly advanced developers can do, but if you work with devices, custom drivers, or test environmentsSooner or later, you're going to run into this requirement. In modern systems, especially 64-bit systems, Windows no longer trusts just any binary that tries to sneak into the kernel: it wants valid digital signatures, modern algorithms like SHA2, and, in many cases, certification through Microsoft.

In the following lines we will calmly examine what exactly it means to sign a controller, what differences there are between kernel mode and user modeHow it affects 64-bit Windows 7, 8, 8.1 and 10, what role tools like SignTool or Visual Studio play, and what options you have for both development environments (test or self-signed certificates) and public releases with certificates issued by a trusted authority.

What is driver signing in Windows and why is it mandatory?

Driver signing in Windows involves associating a digital signature to a driver package (binary files, INF files, catalog, etc.) in order to guarantee two things: that no one has manipulated the files since they were created and that they really come from the indicated publisher (the software provider or manufacturer of the hardware).

In practice, during the installation of a Windows device, these digital signatures are used to verify the integrity of the package and the publisher's identity. If something doesn't match (corrupted signature, untrusted certificate, incorrect hash, etc.), the system will display warnings, block the installation, or simply refuse to load the driver.

From Windows Vista 64-bit onwards, and especially in Windows 7, 8, 8.1 and 10 x64, the kernel-mode security policy is clear: any driver that is going to run in the kernel It must be properly signed.Otherwise, the driver will not load, the device may become inoperative, and blue screens may even occur if invalid binaries are forced to load.

When you decide to certify your driver with Microsoft, you can submit it to the Windows Hardware Quality Labs (WHQL) validation process. If the driver package passes the certification tests, Microsoft grants its certification. official WHQL signatureThis not only improves trust and compatibility, but also allows you to distribute the driver through Windows Update and other distribution channels supported by Microsoft.

It's important to keep in mind that starting with Windows 10 version 1507, all drivers signed through the Microsoft Hardware Development Center are signed using SHA2 as a hash algorithmSHA1 has become obsolete for these scenarios, and mixing old certificates can cause problems, especially on newer systems.

Differences between driver signing in kernel mode and user mode

Windows supports drivers that run in kernel mode and user modeThe signing policy is not exactly the same in both environments, although it tends to become stricter with each new version of the operating system.

Kernel-mode drivers are the most sensitive because they run in the system kernel and have privileged access to memory and hardware. In 64-bit versions of Windows Vista and later, these drivers They are required to be signed in order to be charged. This restriction is directly related to system stability and protection against malware that it attempts to inject at a low level.

On the other hand, drivers that operate in user mode (for example, many printer drivers and additional components) were not originally subject to such a strict obligation. In fact, in older versions of Windows It was not an absolute requirement that these drivers be signed. However, Microsoft has always recommended signing them for security reasons, and since Windows 8 there are scenarios in which signing is required for certain types of user drivers.

A typical example: a printer driver installed on an x64 computer usually displays a dialog box during the installation process asking for user confirmation. In practice, that package It must be properly signed so that the installation can continue without blockages or critical security alerts.

The general idea is that, although the requirement is not universal in user mode, Microsoft is increasingly pushing for it to all driver-related software must be signedSigning them allows for reliable verification of who created them, detection of tampering, and a reduction in the risk of malicious components slipping in while masquerading as legitimate controllers.

Signature requirements and SHA algorithms in different versions of Windows

One of the most troublesome aspects is the compatibility between Windows versions and hash algorithms such as SHA1 and SHA2Many developers encounter drivers that work on one system but not on another, and much of the blame lies with changes in signing policies.

In older systems, such as 64-bit Windows 7 or 8, it was common to work with certificates and signatures based on SHA1, although Microsoft already warned that SHA1 fell short in securityAs progress has been made towards Windows 8.1 and 10, SHA2 has become the standard for code and driver signatures.

In practice, some manufacturers chose to sign kernel-mode binaries by embedding dual certificates (SHA1 and SHA2) issued by entities other than Microsoft. These dual-signed binaries, in certain cases, They fail to load in versions prior to Windows 10and on some Windows 10 systems they can even cause serious crashes or blue screens.

To mitigate these problems, Microsoft released specific patches, such as update KB 3081436. Installing this update on affected systems corrects incompatibilities with certain SHA2-signed drivers and provides a list of reference SHA hash values in the “More information – File hash information” section of that support article.

If you are going to distribute drivers that need to work on multiple versions of Windows, it is essential to review the signature requirements per version detailed by Microsoft. There it is specified which algorithms are valid, how backward compatibility is handled, and which signature combinations (catalog, embedded binary, cross-certificates, etc.) are officially accepted.

User-mode driver signing: recommendations and resources

Although the kernel often gets the most attention, user-mode driver signing also deserves attention. Microsoft didn't enforce it so strictly from the beginning, but it did... strongly recommends to preserve safety of the system and offer confidence to the end user.

The signature of a user-mode driver basically performs the same functions as in kernel mode: identifies the controller provider (manufacturer, ISV, etc.) and confirms that the package has not been modified since it was signed. When a user installs, for example, a printer with user-mode drivers on an x64 computer, the installation wizard may display a dialog box asking if the publisher is trusted. If the signature is valid and the certificate belongs to a recognized entity, the installation is smoother and with far fewer warnings.

Microsoft provides a series of documents and tutorials that delve deeper into the signing process, many of them originally designed for kernel mode but also applicable to user mode. The main article on driver signature and the subtopic “How to version sign a kernel module” within the kernel-mode code signing tutorial are good starting points for understanding the general logic of code signing in Windows.

Additionally, the Windows Driver Kit (WDK) installation includes a help file called selfsign_readme.htm, located in the directory selfsignThis document explains how to generate test certificates and how to use them during development, which is especially useful when you don't yet have a certificate issued by a trusted root authority.

In summary, although a user-mode driver can technically function without a signature in some scenarios, it should be treated as if it were mandatory. This is due to security, brand image, and compatibility with Windows installation wizards. Signing the driver is the most sensible thing to do..

Signing kernel-mode drivers in Windows 7 and 8 using SignTool

When working with 64-bit Windows 7 and 8, one of the most common approaches to signing kernel-mode drivers is to use the command-line tool. commands SignToolIncluded in the Windows SDK, this utility allows you to both sign files and verify existing signatures, and it offers a wide range of options to suit different scenarios.

Some of the most important options The features of SignTool are as follows:

• /ac: specifies an additional certificate, for example, a cross-certificate that links your certificate to a trusted root authority.
• /f: indicates the file that contains the signing certificate (usually a .pfx).
• /p: provides the password associated with the signing certificate stored in the .pfx file.
• /fd: defines the hash algorithm used when creating the file signature, for example, /fd sha256 to generate a signature based on SHA256 (if nothing is specified, SHA1 is usually the default value in older versions).
• /n «Common name of the certificate»: allows you to select a specific certificate from the Windows certificate store based on its common name (CN).
• /t: specifies a timestamping server compatible with the Microsoft Authenticode scheme.
• / tr: indicates a timestamp server compliant with RFC 3161, more modern and recommended for new implementations.

When working on your driver project, it's important to know which files need to be signed. For a driver to install correctly on Windows 7 or 8, it must be signed. all relevant binaries of the project (for example, .sys files) and also the catalog file (.cat) that groups the set of files in the package.

You have two main options: you can copy those files to a working directory where you have SignTool available, or directly move them to the Windows SDK bin folder and run the tool from there. The important thing is that you have both the binaries and the certificates you're going to use for signing on hand.

A typical scenario involves acquiring the appropriate code signing certificate, for example, a “Microsoft Cross Certificate” certificate issued by GlobalSign or another trusted authority. You place that cross-certificate (CrossCert.crt) in your working directory along with your main code-signing certificate (for example, CodeSign.pfx) and run a command similar to this:

signtool sign /ac CrossCert.crt /f CodeSign.pfx /p password1234 /tr http://timestamp.globalsign.com/tsa/r6advanced1 filter.sys

This command generates a signature that includes the cross-certification and obtains a timestamp from GlobalSign's RFC 3161 server. The timestamp is key because it proves that the file was signed on a date when the certificate was valid, even if it later expires.

After signing the file, it's time to verify that everything is correct. This is usually done using a verification command such as:

signtool verify -v -kp filename.sys

The option -v It forces a detailed output, showing detailed information about the certificate chain, and the option -kp It verifies the signature according to the kernel-mode driver's specific code signing criteria. If everything goes well, you will see a result indicating that the signature and certificate chain are correct.

Finally, it is recommended Repeat the same signing and verification process with the .cat file of the package. Once both the binaries and the catalog are properly signed, the driver can be installed on Windows 7 and 8 x64 without security issues, and during the installation wizard, the trusted publisher information and standard system windows should appear.

To delve deeper into all the tool's variants, Microsoft maintains a comprehensive SignTool command reference, as well as a Specific tutorial for code signing in kernel mode and documentation dedicated to digital signatures of kernel modules in Windows. These resources explain special cases, advanced parameters, and particularities of each system version.