Digital Signatures and PnP Device Installation (Windows Vista and Later)

On Windows Vista and later versions of Windows, Plug and Play (PnP) device installation uses the digital signature of a driver package’sВ catalog file to do the following:

Verify the identity of the publisher of the driver package. Windows uses the identity to allow users to choose whether to trust a driver’s publisher.

Determine whether the driver package was altered after it was published.

PnP device installation on Windows Vista and later versions of Windows support the following types of digital signatures for driver packages:

Signature types that can be used for drivers that are released to the general public:

Signatures generated by a Windows signing authority for:

1. Inbox drivers
2. Drivers certified and signed through the Windows Hardware Quality Labs (WHQL)
3. Windows Sustained Engineering (SE) updates.

Signatures that are not generated by a Windows signing authority, but do comply with the following:

1. The kernel-mode code signing policy for 64-bit versions of Windows Vista and later versions of Windows.
2. The PnP device installation signing requirements for 32-bit and 64-bit versions of Windows Vista and later versions of Windows.

This type of signature is generated by using a Software Publisher Certificate (SPC) that is obtained from a third-party certification authority (CA) that is authorized by Microsoft to issue such certificates.

Signatures that are not generated by a Windows signing authority and do not comply with the kernel-mode code signing policy, but do comply with the PnP device installation signing requirements. This type of signature can be used to sign kernel-mode drivers for 32-bit versions of Windows Vista and later versions of Windows. This type of signature is generated by using a commercial release certificate that is obtained from a CA that is a member of the Microsoft Root Certificate Program.

Signatures for deploying drivers only within corporate network environments, which are created by a digital certificate that is created and managed by Enterprise CA. Detailed information about how to configure an Enterprise CA is outside the scope of this documentation.

For information about how to create an Enterprise CA, see the «Code Signing Best Practices» white paper on the Driver Signing Requirements for Windows website.

Signature types that can be used in-house during the development and test of drivers:

• Signatures generated by the WHQL test signature program
• Signatures generated by a MakeCert test certificate
• Signatures created by a commercial test certificate that is obtained from a CA that is a member of the Microsoft Root Certificate Program
• Signatures generated by an Enterprise CA test certificate

Windows Vista and later versions of Windows include the following features that provide support for signatures that are generated by third parties:

Administrators can control which driver publishers are trusted. Windows Vista and later versions of Windows installs drivers from trusted publishers without prompting. It never installs drivers from publishers that the administrator has chosen not to trust.

The driver-signing policy is always set to Warn. This eliminates the Ignore and Block options that were available in Windows Server 2003, Windows XP, and Windows 2000. An administrator must always authorize the installation of unsigned drivers or a driver from a publisher that is not yet trusted.

All device setup classes are treated equally. On Windows Server 2003, Windows XP, and Windows 2000, driver packages that were signed by WHQL must have an INF file that specifies a device setup class that is defined in %SystemRoot%/inf/Certclas.inf. Otherwise, Windows treats the driver package as unsigned.

Starting with Windows Vista, when there are several compatible drivers to choose from, the ranking algorithm that the operating system uses to select the best driver includes drivers that have third-party signatures.

This algorithm ranks drivers in the following way:

• If the AllSignersEqual group policy is disabled, the operating system ranks drivers that are signed with a Microsoft signature higher than drivers that are signed with a third-party signature. This ranking occurs even if a driver that is signed with a third-party signature is, in all other ways, a better match for a device.
• If the AllSignersEqual group policy is enabled, the operating system ranks all digitally signed drivers equally.

NoteВ В Starting with Windows 7, the AllSignersEqual group policy is enabled by default. In Windows Vista and Windows Server 2008, the AllSignersEqual group policy is disabled by default. IT departments can override the default ranking behavior by enabling or disabling the AllSignersEqual group policy.

Before installing a driver, Windows analyzes the driver package’s digital signature. If a signature is present, Windows uses the signature to validate the files in the driver package. Based on the results of this analysis, Windows categorizes the digital signature as follows:

Signed by a Windows signing authority. These drivers are either included in the default installation of Windows (inbox drivers), signed for release by WHQL, or signed by Windows SE.

Signed by a trusted publisher. These drivers have been signed by a third-party, and user has explicitly chosen to always trust signed drivers from this publisher.

Signed by an untrusted publisher. These drivers have been signed by a third-party, and the user has explicitly chosen to never trust drivers from this publisher.

Signed by a publisher of unknown trust. These drivers have been signed by a third-party, and the user has not indicated whether to trust this publisher.

Altered. These drivers are signed, but Windows has detected that at least one file in the driver package has been altered after the package was signed.

Unsigned. These drivers are either unsigned or have an invalid signature. Valid signatures must be created by using a certificate that was issued by a trusted CA.

Starting with Windows Vista, when the operating system installs a driver on a computer for the first time, it preinstalls, or stages, the driver in the driver store. To preinstall a driver, Windows copies the driver package to the driver store and saves a copy of the driver package’s INF file in the system INF directory. Windows subsequently will silently install a driver for a matching device by using the copy of the driver package in the driver store. User interaction is not required when Windows installs a preinstalled driver for a device.

Whether Windows will preinstall a driver package depends on the signature category, user credentials, and user interaction, as follows:

Signed by a Windows signing authority or a trusted publisher. Windows silently preinstalls the driver package for system administrators and standard users (users without administrator credentials). Windows does not display any user dialog boxes.

Signed by an untrusted publisher. Windows does not preinstall the driver package.

Signed by a publisher of unknown trust. Windows displays a dialog box to a system administrator that informs the administrator that the publisher of the driver package is not yet trusted. The dialog box provides the administrator the option to install the driver package and the option to always trust the publisher. Windows does not display a dialog box to a standard user and does not preinstall the driver package for the standard user.

Altered or unsigned. Windows displays a dialog box that appropriately warns a system administrator that the signature could not be verified. The dialog box provides the administrator the option to install or not to install the driver package. Windows does not display a dialog box to a standard user and does not preinstall the driver package for a standard user.

For more information about driver signatures and installation, see Signature Categories and Driver Installation.

Microsoft network server: Digitally sign communications (always)

Applies to

Describes the best practices, location, values, policy management and security considerations for the Microsoft network server: Digitally sign communications (always) security policy setting for SMBv3 and SMBv2.

Reference

The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets.

Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as «session hijacking.» But misuse of these policy settings can cause data access failure.

Beginning with SMBv2 clients and servers, signing can be either required or not required. If this policy setting is enabled, SMBv2 clients will digitally sign all packets. Another policy setting determines whether signing is required for SMBv3 and SMBv2 server communications: Microsoft network client: Digitally sign communications (always).

There is a negotiation done between the SMB client and the SMB server to decide whether signing will effectively be used. The following table has the effective behavior for SMBv3 and SMBv2.

Server – Required	Server – Not Required
Client – Required	Signed	Signed
Client – Not Required	Signed 1	Not Signed 2

1 Default for domain controller SMB traffic 2 Default for all other SMB traffic

Performance of SMB signing is improved in SMBv2. For more details, see Potential impact.

Possible values

Best practices

Enable Microsoft network server: Digitally sign communications (always).

Location

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default values

The following table lists the actual and effective default values for this policy. Default values are also listed on the policy’s property page.

Server type or GPO	Default value
Default Domain Policy	Disabled
Default Domain Controller Policy	Enabled
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Disabled
Client Computer Effective Default Settings	Disabled

Policy management

This section describes features and tools that are available to help you manage this policy.

Restart requirement

None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.

Security considerations

This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.

Vulnerability

Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data.

SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of many modern features like Storage Spaces Direct, Storage Replica, and SMB Direct, as well as many legacy protocols and tools. If either side fails the authentication process, data transmission does not take place.

Countermeasure

Enable Microsoft network server: Digitally sign communications (always).

An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers’ CPUs. No such accelerators are available for SMB signing.

Potential impact

Storage speeds impact performance. A faster drive on the source and destination allows more throughput, which causes more CPU usage of signing. If you are using a 1 Gb Ethernet network or slower storage speed with a modern CPU, there is limited degradation in performance. If you are using a faster network (such as 10 Gb), the performance impact of signing may be greater.

Digital signatures and certificates

More and more people and organizations are using digital documents instead of paper documents to conduct day-to-day transactions. By reducing dependency on paper documents, we are protecting the environment and saving the planet’s resources. Digital signatures support this change by providing assurances about the validity and authenticity of a digital document.

What do you want to do?

What is a digital signature?

A digital signature is an electronic, encrypted, stamp of authentication on digital information such as email messages, macros, or electronic documents. A signature confirms that the information originated from the signer and has not been altered.

The following is an example of a signature line.

Signing certificate and certificate authority

Signing certificate To create a digital signature, you need a signing certificate, which proves identity. When you send a digitally-signed macro or document, you also send your certificate and public key. Certificates are issued by a certification authority, and like a driver’s license, can be revoked. A certificate is usually valid for a year, after which, the signer must renew, or get a new, signing certificate to establish identity.

Note: You can learn more about public and private keys in this article.

Certificate authority (CA) A certificate authority is an entity similar to a notary public. It issues digital certificates, signs certificates to verify their validity and tracks which certificates have been revoked or have expired.

Digital signature assurances

The following terms and definitions show what assurances are provided by digital signatures.

Authenticity The signer is confirmed as the signer.

Integrity The content has not been changed or tampered with since it was digitally signed.

Non-repudiation Proves to all parties the origin of the signed content. Repudiation refers to the act of a signer denying any association with the signed content.

Notarization Signatures in Microsoft Word, Microsoft Excel, or Microsoft PowerPoint files, which are time stamped by a secure time-stamp server, under certain circumstances, have the validity of a notarization.

To make these assurances, the content creator must digitally sign the content by using a signature that satisfies the following criteria:

The digital signature is valid.

The certificate associated with the digital signature is current (not expired).

The signing person or organization, known as the publisher, is trusted.

Important: Signed documents, which have a valid time stamp, are considered to have valid signatures, regardless of the age of the signing certificate.

The certificate associated with the digital signature is issued to the signing publisher by a reputable certificate authority (CA).