Kernel Driver Signing - Part III

Copyright © 2010, Steven E. Houchin

In Parts I and II of this article, I discussed the requirement for driver signing, digital signatures, and how to go about testing signed drivers.

The last step is the actual signing of the binaries that you integrate into the customer product. In order to do this, you must first purchase a digital certificate from a reputable certificate authority (CA). In fact, for kernel mode drivers, you must purchase your digital certificate from Verisign. Certificates from other vendors can be used to sign the binaries, and Windows installs them, but it refuses to execute those binaries (as of Windows 7).

As I've mentioned in the earlier parts of this article, the step-by-step procedures for driver signing are contained in a document at the Windows WHDC site, and need not be repeated here. It contains a section titled "The Kernel-Mode Code-Signing Process." The important decision to make is whether to set up the digital signature via a catalog file (specified in the INF file), or to sign the binaries directly. A cartalog is preferable, especially if you are signing multiple files; but that won't work if your binaries start at boot time (see StartType in your INF fle). In that case, signing the binarys themselves is required. Microsoft has another site, titled "Signing Drivers for Public Release", that gives more details about the files you may receive from your CA.

When you distribute your product for the customer to install, the installer package must include, in addition to the binaries, the INF file, signed catalog files (if any), and the public key portion of your digital certificate. The public key digital certificate (.spc or .cer file) must be installed on your customer's system. Your original private key digital certificate (.pvk file) should be locked away, because it is used in the signing process.

Kernel Driver Signing - Part II

Copyright © 2010, Steven E. Houchin

In Part I of this article, I explained that all kernel drivers on 64-bit Windows systems must be digitally signed.

There are two ways of signing kernel drivers: embed the signature in the driver binaries themselves, or use a signed catalog file. To peform driver signing, you really must have the latest Microsoft WDK installed on your signing system.

For drivers that start at boot time (see StartType in your INF fle), the binary itself must be signed.  Use of a catalog file is not enough, though is also required if installing the driver package via INF file.  For other types of drivers - especially those that contain multiple files - a signed catalog file can be used to identify all the files in a driver package. 

Use of a catalog file requires that the driver package be installed via an INF file, because that is where the catalog file is specified. For example, ADriver.inf will have the following line included in its [Version] section:

CatalogFile=ADriver.cat

After your driver binaries are all built and copied to a "package" directory (which includes the INF file), a catalog file is created using the WDK's Inf2Cat utility. For example, if your package files are in C:\MyDriverPackage, the catalog file (in this case for Win2K and Win64 systems) is created via:

Inf2Cat /driver:C:\MyDriverPackage\ /os:2000,Server2003_X64

This utility will scan all INF files in the given directory and create catalog files for each one using the "CatalogFile" line.

Once the catalog files are created, they must be signed using WDK's SignTool utility and your digital certificate information.  The details for catalog file creation and signing, and driver binary signing, are at the Windows WHDC site, which contains white paper that has decent step-by-step procedures.

The catalog file and INF file go together as a pair wherever the signed driver package is to be installed.  If your INF file is also used for 32-bit drivers, then your 32-bit installer should comment out the "CatalogFile" line in the [Version] section so that a signing certificate isn't needed on those systems.

Kernel Driver Signing - Part I

Copyright © 2010, Steven E. Houchin


Back in January of 2006, Microsoft announced - much to developers' dismay - that all kernel drivers on 64-bit Windows systems must be signed. Signing is defined as:

the process of assigning an encrypted digital signature to executables in order to confirm the software's author and to guarantee that the code has not been altered or corrupted

Once I ported my client's driver code to 64-bit, I found myself in an "uh-oh" situation: how do I test the changes on my development systems without having my client's digital signing certificate?  A digital certificate is:

a digital signature from a certificate authority (CA) that contains a private key used to sign some software, which must match the public key in the CA's certificate installed on a user's system

The private key (PK) is necessary for me to sign the driver executables, and is something that the software vendor (my client) must not pass around to anyone else - including me - lest it fall into the wrong hands and be used for malicious signing. That gets us back to my dilemma: how do I test without the PK?

The answer provided by MSFT is Test Signing. The Windows WHDC site contains a good white paper on this subject that has decent step-by-step procedures. The basic idea is this: a developer can create a Test Certificate, which is used on the development systems to sign and validate executables.  The catch is, the executables will only work if the target test system is configured to boot into a special Test Signing mode. This is done on the target system with the BCDEDIT command. Note that, in the past, it was also possible to boot Windows into a "Disable Driver Signature Enforcement" mode, where signatures were ignored. That option, while still visible via F8 boot options, does not actually work anymore.

Next time: Test Signing using catalog files.