Technology Overview

Applies To: Windows 7, Windows Server 2008 R2

The following sections provide a brief overview of the core technologies discussed in this guide.

Digital signatures and certificates

Because device drivers run with system-level privileges and can access anything on your computer, it is critical that you trust the device drivers that you install. Trust, in this context, includes two main principles:

• Authenticity is an assurance that the driver package came from its claimed source. It cannot be malicious code masquerading as something legitimate.

• Integrity is an assurance that the package is 100 percent intact, and has not been modified by anyone after it was released.

Windows uses digital certificates and digital signatures to provide support for these principles. A digital certificate identifies an organization, and it is trustworthy because it can be checked electronically by a certification authority (CA). A digital signature uses information in the organization's digital certificate to encrypt specific details about the package.

The encrypted information in a digital signature includes a thumbprint, or hash, for each file included with the package. The thumbprint is generated by a special cryptographic algorithm referred to as a hashing algorithm. The algorithm generates a thumbprint that can only be recreated by using that file's contents. Changing a single bit in the file changes the thumbprint. After the thumbprints are generated, they are combined together into a catalog, and then encrypted.

The following figure shows the process used to sign a driver package.

In this process the following steps take place:

The original driver package has no signature, and no .cat file in which a signature can be placed. In Step 1 of the diagram the Inf2Cat tool is run to create the .cat file, in which it places a thumbprint for each file identified as part of the driver package, as specified in the .inf file. In Step 2, the SignTool tool is run, specifying a digital certificate to encrypt, and thus sign, the .cat file. In Step 3, the digitally signed .cat file is included with the driver package and deployed to client computers.

The recipient computer confirms the identity of the package originator by using a copy of the certificate to decrypt the signature on the package. A successful decryption proves that the owner of the certificate is the signer of the package.

The same hashing algorithm used to create the thumbprints is used again during the confirmation process. Windows generates a thumbprint for each file received in the package. If the thumbprints generated by the receiving computer are identical to the ones found encrypted in the signature, then the recipient can be sure that the received package is identical to the original. If the thumbprints do not match, then the files were altered in some way after they were signed, and should not be trusted.

On each computer, Windows maintains a store for digital certificates. As the computer administrator, you can add certificates from publishers that you trust. If a package is received for which a matching certificate cannot be found in the certificate store, then Windows presents a page asking the user to confirm that the publisher is trusted. By placing a certificate in the certificate store on all of your client computers, you are telling Windows that all packages signed by that certificate are trusted.

Guidance for Safeguarding Code Signing Keys

The cryptographic keys that are at the heart of the Authenticode signing process must be well protected and treated with the same care as the organization’s most valuable assets. These keys represent an organization’s identity. Any code that is signed with these keys appears to Windows as if it contains a valid digital signature that can be traced to the organization. If the keys are stolen, they could be used to fraudulently sign malicious code and possibly result in the delivery of code that contains a Trojan or virus that appears to come from a legitimate publisher.

For detailed information about safe guarding private keys, see the "Code Signing Best Practices" document referenced in the Additional Resources section at the end of this guide.

Device installation

A device is a piece of hardware with which Windows interacts to perform some function. Windows can communicate with a device only by using a piece of software called a device driver. Device and device driver installation in Windows 7 and Windows Server 2008 R2 operate as shown in the following diagram. "PnP" in the diagram refers to the Plug and Play service running in Windows. If any of the described security checks fail, or if Windows cannot find an appropriate device driver package, then the process stops.

The diagram shows the default behavior. Group Policy settings can move the Windows Update search to before or after the DevicePath folders, or prevent Windows Update from being used at all.

1. When a user inserts a device, Windows detects the new hardware, and then signals the Plug and Play service to make the device operational.

2. Plug and Play queries the device for identification strings.

3. Plug and Play searches the driver store for a driver package that matches the identification strings.

4. The computer searches Windows Update for a better driver package than is already present. If a better driver is found, skip to step 6. If a better driver is not found, then proceed to step 5.

5. The computer searches the folders specified in the DevicePath registry key for a better driver package. If a better driver is found, then proceed to step 6. If a better driver is not found, then skip to step 8.

6. Windows downloads the driver package.

7. Windows stages the downloaded driver package in the driver store.

8. Windows compares all matching driver packages now staged in the driver store, selects the best one, and proceeds to step 9. If a suitable driver is not found in the driver store, then proceed to step 10.

   For more information about how Windows selects the “best” driver, see the article "How Setup Selects Device Drivers" document referenced in the Additional Resources section at the end of this guide.

9. Windows installs the selected driver package from the driver store. The device is now operational.

10. If no driver package was found, then Windows generates a Windows Error Report that identifies the device for which no driver package was discovered. If a solution is available, then it is displayed to the user as an Action Center message. The solution can be a vendor provided link to a Web page from which the user can download the driver.

For more information about this process, see Device Manager Help in Windows 7 or Windows Server 2008 R2.

Staging, as referenced in step 7 in the previous flowchart, involves Windows performing all required security checks, and then placing the driver package in a secure location so it can be accessed by the Plug and Play service. Staging can be performed by an administrator as a separate step. After a driver package has been staged, any user that logs on to that computer can install the device driver in the driver store by plugging in the appropriate device. There are no prompts, and no special permissions are required. The user plugs in the device and it works, without administrator or helpdesk intervention.

For more information about the driver store see the Additional Resources section at the end of this guide.

Group Policy

Group Policy is the means by which an administrator can centrally enforce security and configuration settings on managed client computers throughout an organization. It also supports automatic deployment of digital certificates to computers that are members of a domain. Instead of having to visit and manually configure settings on each client computer, or write complicated logon scripts, you configure the desired settings once and distribute them to your managed computers using the Active Directory® directory service that is available with Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, and Windows 2000 Server.

This guide demonstrates procedures that involve manually configuring the client, including the manual installation of the certificates used to sign driver packages. However, in a production environment with many client computers, using Active Directory Group Policy is a much more efficient, less error-prone, and more secure method for enforcing company policy and security settings on your managed computers.

For more information about Group Policy and Active Directory, see the Additional Resources section at the end of this guide.