Even if you read, "It's Not Your Computer" and "Take Two - x64 Driver Signing", you may still have questions about how this program will affect your drivers or your company. The goal of this article is to clarify some signing issues to make things a bit easier.

Signing on x64: Required
Let's start from the beginning: Starting with Windows Vista, all x64 kernel-mode modules will have to be unambiguously digitally identified as to their origin.  Specifically, this means:

• The package(s) containing the INF(s) used to install any x64 kernel-mode modules needs to be signed. Thus, a CAT (catalog) file that contains these signatures needs to be created.
• The executable images for certain x64 kernel-mode modules need to be signed.  These include the executables for any drivers that are started at boot time.

Two Types of Signing
As described in the preceding section, there are two types of signing for x64 kernel-mode code modules:

Signing the Driver Package - When signing a driver package, a catalog file is generated that contains the signatures for the various modules comprising the package. This has the dual effect of ensuring the files in the package are not tampered with and unambiguously identifying the signer. This type of signing is typically referred to as "CAT signing" because of its use of the catalog file.

Signing the Executable Image - When signing an executable image, the signature is embedded in the image header. This signature unambiguously identifies the signer and ensures that the executable image has not been modified.  Because the signature is embedded into the image header, this type of signing is typically referred to as "embedded signing."

Note that both methods of signing can be used simultaneously. The executable images within a driver package can be "embedded signed." Thereafter, the complete package can be "CAT signed."

By the way, if you're wondering how all this relates to the Driver Reliability Signature (DRS) program, you should know it looks like that program has been renamed again. The last I heard was that DRS will now be the WHQL Universal signature program. This program will apply to all types of kernel-mode modules that are not covered by another WHQL program, as long as they're installed via an INF file.

Two Types of Signatures
In the past, the only way to get a driver package CAT signed was by submitting it to WHQL and passing their tests. It will still be possible to obtain a CAT signature from WHQL in Windows Vista. In addition, starting in Vista, driver developers and publishers will be able to sign CATs and executables using a Class 3 Code Signing Certificate issued by a trusted certificate authority (CA). This process is described in the article titled, "Take Two: x64 Driver Signing".

The Tricky Part
Confused yet?  Well, the whole issue about who signs what modules can certainly be tricky.

It's important to note that WHQL only does CAT signing.  This means the only way to embedded sign a kernel-mode executable is by using your Class 3 Code Signing Certificate. Thus, even if you intend to submit your driver package to WHQL for testing and eventual CAT signing, you will need to embedded sign the submitted executable if your driver starts at boot time.

As if that twist isn't enough, note that I've been very careful to use the term "x64 kernel-mode module" and not "x64 driver." An integral part of the x64 security scheme is that every single module loaded in kernel-mode on Windows Vista x64 must be identified. This means kernel-mode DLLs, temporary drivers that load to determine system configuration, and even "internal use only" diagnostic drivers and test tools have to come from a signed driver package. Keep in mind that if these are loaded at boot time, each module also needs to be embedded signed.

But I'm x86 Only!
Maybe you're thinking that none of this applies to you or your organization because you only care about 32-bit drivers. Well, if you're submitting drivers to WHQL, it is important to remember that starting with Vista you will be required to submit a working x64 driver along with your x86 driver. So, starting with Vista, what happens on x64 is relevant to just about everybody.

There's another situation in which kernel-mode code signing for 32-bit systems becomes critical that we haven't mentioned so far - digital rights management via what Microsoft calls Protected Media Path. For example, in order for any Windows system (x64 or x86) to play what's termed "high level" protected content such as some high definition video content, all kernel-mode modules in the system have to be signed. It will not be sufficient for just the modules in the audio and video path to be signed - all the kernel-mode modules in the system will need to be signed.

Bottom Line: Practical Advice
Now are you confused?  Well, you're not alone.  When explaining the current program, one of the responsible Microsoft program mangers with whom I spoke summed it up particularly well: "It'll just be easier to sign everything than to figure out what needs to be signed."

I think that program manager's advice makes good sense. Make sure your organization has a Class 3 Code Signing Certificate from one of the "trusted" CAs.  Start now and add support for embedded driver signing into your development, testing, and build procedures. Put everything that will be installed in the kernel into a package and CAT sign the package with your Class 3 Code Signing Certificate. Note that it's entirely possible - and perfectly "legal" in terms of WHQL - to have multiple CATs and INFs beyond the one CAT and INF per architecture that installs your primary driver. Even sign the driver packages that you submit to WHQL. WHQL will CAT sign the package, and that signature will overwrite the one you provide.

Also, put procedures in place as soon as possible to sign all your kernel-mode modules. Remember that your non-shipping test tools and diagnostic drivers will need to be signed for them to load on x64. Presently you can send your driver package off to WHQL for signing just before release. However, starting with Vista, x64 code signing is something you will need to deal with throughout the development, testing, and release cycles for your product.

Finally, note that the tools needed to get your kernel-mode code signing process up and running are in the recent releases of the WDK. It doesn't hurt to embedded sign kernel-mode executable and CAT sign driver packages before Vista releases. In fact, getting experience doing this now will prevent problems later when your customers need you to get the signing right.