12.3. Windows Digital Driver Signing and Certification

12.3.1. Overview

Before distributing your driver, you can digitally sign and/or certify it, either by submitting it to the Microsoft Windows Logo Program, for certification and signature, or by having the driver Authenticode signed.

Some Windows operating systems, such as Windows XP and below, do not require installed drivers to be digitally signed or certified. There are, however, advantages to getting your driver digitally signed or fully certified, including the following:

  • Driver installation on systems where installing unsigned drivers has been blocked
  • Avoiding warnings during driver installation
  • Full pre-installation of INF files [12.1] on Windows XP and higher

64-bit versions of Windows Vista and higher require Kernel-Mode Code Signing (KMCS) of software that loads in kernel mode. This has the following implications for WinDriver-based drivers:

  • Drivers that are installed via an INF file must be distributed together with a signed catalog file (see details in Section 12.3.2).
  • Drivers that are not installed using an INF file must contain an embedded driver signature.

During driver development, you can configure Windows to temporarily allow the installation of unsigned drivers.

For more information about digital driver signing and certification, see Authenticode Driver Signature

The Microsoft Authenticode mechanism verifies the authenticity of driver's provider. It allows driver developers to include information about themselves and their code with their programs through the use of digital signatures, and informs users of the driver that the driver's publisher is participating in an infrastructure of trusted entities.
The Authenticode signature does not, however, guarantee the code's safety or functionality.

The WinDriver\redist\windrvr6.sys driver has an Authenticode digital signature. WHQL Driver Certification

Microsoft's Windows Logo Program — http://www.microsoft.com/whdc/winlogo/default.mspx — lays out procedures for submitting hardware and software modules, including drivers, for Microsoft quality assurance tests. Passing the tests qualifies the hardware/software for Microsoft certification, which verifies both the driver provider's authenticity and the driver's safety and functionality.

Device drivers should be submitted for certification together with the hardware that they drive. The driver and hardware are submitted to Microsoft's Windows Hardware Quality Labs (WHQL) testing in order to receive digital signature and certification. This procedure verifies both the driver's provider and its behavior.

Jungo's professional services unit provides a complete WHQL pre-certification service for Jungo-based drivers. Professional engineers efficiently perform all the required tests in the Jungo WHQL test lab, relieving customers of the expense and stress of in-house testing. Jungo prepares a WHQL submission package containing the test results, and delivers the package to the customer, ready for submission to Microsoft.
For more information, refer to http://www.jungo.com/st/whql_certification.html.

For detailed information regarding the WHQL certification process, refer to the following Microsoft web pages:

Note: Some of the links require Windows Internet Explorer.

12.3.2. Driver Signing and Certification of WinDriver-Based Drivers

As indicated above [], The WinDriver\redist\windrvr6.sys driver has an Authenticode signature. Since WinDriver's kernel module (windrvr6.sys) is a generic driver, which can be used as a driver for different types of hardware devices, it cannot be submitted as a standalone driver for WHQL certification. However, once you have used WinDriver to develop a Windows driver for your selected hardware, you can submit both the hardware and driver for Microsoft WHQL certification, as explained below.

The driver certification and signature procedures — either via Authenticode or WHQL — require the creation of a catalog file for the driver. This file is a sort of hash, which describes other files. The signed windrvr6.sys driver is provided with a matching catalog file — WinDriver\redist\wd1100.cat. This file is assigned to the CatalogFile entry in the windrvr6.inf file (provided as well in the redist directory). This entry is used to inform Windows of the driver's signature and the relevant catalog file during the driver's installation.

When the name, contents, or even the date of the files described in a driver's catalog file is modified, the catalog file, and consequently the driver signature associated with it, become invalid. Therefore, if you select to rename the windrvr6.sys driver [12.2] and/or the related windrvr6.inf file, the wd1100.cat catalog file and the related driver signature will become invalid.

In addition, when using WinDriver to develop a driver for your Plug-and-Play device, you normally also create a device-specific INF file that registers your device to work with the windrvr6.sys driver module (or a renamed version of this driver). Since this INF file is created at your site, for your specific hardware, it is not referenced from the wd1100.cat catalog file and cannot be signed by Jungo a priori.

When renaming windrvr6.sys and/or creating a device-specific INF file for your device, you have two alternative options regarding your driver's digital signing:

  • Do not digitally sign your driver. If you select this option, remove or comment-out the reference to the wd1100.cat file from the windrvr6.inf file (or your renamed version of this file).
  • Submit your driver for WHQL certification or have it Authenticode signed.
    Note that while renaming WinDriver\redist\windrvr6.sys nullifies the driver's digital signature, the driver is still WHQL-compliant and can therefore be submitted for WHQL testing.

    To digitally sign/certify your driver, follow these steps:

    • Create a new catalog file for your driver, as explained in Microsoft's WHQL documentation. The new file should reference both windrvr6.sys (or your renamed driver) and any INF files used in your driver's installation.
    • Assign the name of your new catalog file to the CatalogFile entry in your driver's INF file(s). (You can either change the CatalogFile entry in the windrvr6.inf file to refer to your new catalog file, and add a similar entry in your device-specific INF file; or incorporate both windrvr6.inf and your device INF file into a single INF file that contains such a CatalogFile entry).
    • If you wish to submit your driver for WHQL certification, refer to the additional guidelines in Section
    • Submit your driver for WHQL certification or for an Authenticode signature.

      Note that many WinDriver customers have already successfully digitally signed and certified their WinDriver-based drivers. WHQL DTM Test Notes

As indicated in the WHQL documentation, before submitting the driver for testing you need to download Microsoft's Driver Test Manager (DTM) (http://www.microsoft.com/whdc/DevTools/WDK/DTM.mspx) and run the relevant tests for your hardware/software. After you have verified that you can successfully pass the DTM tests, create the required logs package and proceed according to Microsoft's documentation.

When running the DTM tests, note the following:

  • The DTM test class for WinDriver-based drivers should be Unclassified — Universal Device.
  • The Driver Verifier test is applied to all unsigned drivers found on the test machine. It is therefore important to try and minimize the number of unsigned drivers installed on the test PC (apart from the test driver — windrvr6.sys).
  • The USB Selective Suspend test requires that the depth of the under-test USB device in the USB devices tree is at least one external hub and no more than two external hubs deep.
  • The ACPI Stress test requires that the ACPI settings in the BIOS support the S3 power state.
  • Verify that the /PAE switch is added to the boot flags in the PC's boot.ini file.
  • Before submitting the file for certification you need to create a new catalog file, which lists your driver and specific INF file(s), and refer to this catalog file from your INF file(s), as explained above [12.3.2].