What Is It

When a new device is installed on Win2K, and the .inf file for the driver has been found, the installer checks the .inf file to see if it has an associated Catalog (.cat) file.  If an associated Catalog file exists, the installer checks the Catalog file for a valid digital signature that matches the driver being installed.  If the digital signature matches, the installation proceeds normally.

The difficulty begins if the signature in the Catalog file doesn?t match the driver or, more likely, if the .inf file indicates that the driver doesn?t have an associated Catalog file.  In this case, the action taken by the installer depends on what hardware is being installed and system policy.

If the driver is for hardware in one of the classes shown in Figure 1, and there?s no Catalog file or the verification of the Catalog file fails, the action taken by the installer is dependent on system policy. Possible actions are:

·       Ignore ? The installation continues, and ignores the fact that there?s no valid Catalog file associated with this driver;

·         Warning ? A pop-up (shown in Figure 2) is displayed warning the user doing the installation that the driver is not signed, and asking the user if they want to continue anyways;

·         Disallowed ? A slightly different pop-up appears that indicates that the driver is not signed, and telling the user that the driver can therefore not be installed.

By default, Windows 2000 will ship with the system policy set to ?Warning?.  So, if a user attempts to install a driver in one of the indicated classes that isn?t signed, the pop-up occurs, the user clicks ?Yes? to continue, and everything is fine.

 Figure 1 ? Hardware Classes Enforcing Driver Signing

What happens for drivers that aren?t in the list of classes shown in Figure 1?  For these devices, driver signing isn?t implemented.  So, when the installer notices that a device being installed doesn?t have a Catalog file associated with it, the installation proceeds normally ? that is, no pop-ups are displayed and the installation continues.

 Figure 2 ? Warning

Getting Signed

So, how do you get your driver signed?  Presently the only way to do this is to submit your driver to WHQL and have it tested and approved.  Not only does this result in you getting a valid Catalog file, but also once a driver?s passed WHQL testing it can appear on the Windows Update web site.

But, I?m sure you?ll notice, there is a catch here.  Your driver will get signed only if it?s WHQL approved.  And WHQL has some pretty stringent rules for approval.  For example, suppose you?ve authored an NDIS driver that can only be used on Windows 2000 and that driver makes use of the native Windows 2000 DDK functions in addition to the functions provided by the NDIS library.  WHQL won?t approve such drivers.  Therefore, there?s no way (at least today) that you can get your driver signed.  Thus, every time a customer installs that driver, assuming the system policy is at the default setting, they?ll get the pop-up warning.  I?m thinkin? your technical support people will be less than pleased with the calls they?ll be getting about this.

Changing Policy

The system policy, for what to do when attempting to install a driver without a valid Catalog file, is determined by the registry key HKCU\Software\Policies\Microsoft\Windows NT\Driver Signing. Under this key, the value ?BehaviorOnFailedVerify? is a REG_DWORD with a value of 0, 1, or 2 that indicates the policy is to ignore, warn, or disallow (respectively ? as defined above) when an unsigned driver is installed.

Note that there are other keys in the Registry that have the name ?Driver Signing?, but at least as of RC2, these keys did not have any effect.  Also, there is a ?Driver Signing? option in the security policy MMC snap in, that allows you to set the system policy for driver signing.  We?ve played with this ? again at least in RC2 ?  and haven?t seen it have any effect either!  We did verify that the registry path described above actually changes the system policy, as you?d expect.

Futures

Obviously, many driver writers are concerned about what their users will think when they get a pop-up that says ?there is no guarantee that the software works correctly with Windows?.  Many IHVs don?t want to submit their drivers to WHQL as a matter of practicality, cost, or strategy.  And, as described earlier, there are a number of drivers that WHQL just plain won?t certify.  Are these groups forever doomed?

Perhaps not.  Microsoft is strongly considering an alternative level of driver signing, that would allow IHVs to attest to the authenticity of the driver being installed, but that does not imply the driver has received WHQL approval. One proposal under consideration would use something similar to the Authenticode system used on the web.  The details for an IHV signing plan are still being hashed out, but one thing is certain: No such support will be in the initial version of Windows 2000 when it ships.  As everyone knows Microsoft is strongly focused on shipping Win2K, and adding another level of support apparently doesn?t fit into the currently anticipated shipment timeframe.

Summary

So, to summarize, driver signing won?t affect IHVs who produce special-purpose PCI cards and drivers, file systems, or file system filter drivers, because these devices are not in one of the classes of device where driver signing is presently enforced.  That?s good news for many of us.

For vendors who build hardware and write drivers in one of the enforced categories, the reasonably good news is that the default action in Windows 2000 will be to warn the user only.  It will still be possible to install the driver.  However, for such vendors, the choices are still pretty clear: Get your driver WHQL certified, or be get ready to answer calls from your customers asking what the funny pop-up means.  Fortunately, the pop-up appears only during installation (and not every time the driver is loaded, as has been reported elsewhere!).

The NT Insider is grateful to Brett Miller, Microsoft?s program manager for driver signing, for providing information for this article.