|
Digital Signatures for Kernel Modules on Systems Running Windows Vista -
Digital Signatures for Kernel Modules on Systems Running Windows Vista
July 25, 2007
Abstract
For Windows Vista® and later versions of the Windows® family of operating systems:
Kernel-mode software must have a digital signature before it will load on x64-based computer systems.
Boot-start drivers should contain an embedded signature.
Certain configurations of x86 systems require kernel-mode software to have digital signatures to access next-generation premium content depending on content protection policy.
This paper describes how to manage the signing process for kernel-mode software for Windows Vista.
This information applies for the following operating systems:
Windows Vista
Windows Server® 2008
The current version of this paper is maintained on the Web at:
http://www.microsoft.com/whdc/winlogo/drvsign/kmsigning.mspx
References and resources discussed here are listed at the end of this paper.
Contents
Introduction 3
Digital Signatures as a Best Practice 4
Kernel-Mode Code-Signing Options 4
The Kernel-Mode Code-Signing Process 6
How to Obtain a Software Publishing Certificate 6
Guidance for Safeguarding Code-Signing Keys 7
Using Cross-Certificates with Kernel-Mode Code Signing 7
Verification during Driver Installation and Loading 8
Generating Test Certificates 9
Creating a Signed Catalog File 10
How to Create a Catalog File 10
How to Create a Catalog File by Using Inf2Cat 11
How to Create a Catalog File Manually 12
How to Sign a Catalog File 12
Signing the Self-Extracting Download file 13
How to Install a Signed Catalog File 14
Adding an Embedded Signature to a Driver Image File 14
How to Verify an Embedded Signature 15
How to Disable Signature Enforcement during Development 15
How to Use Test Signing 15
Using the WHQL Test Signature Program 16
Enabling Test Signing 16
Troubleshooting 17
Detecting Driver Load Errors 17
Enabling Code Integrity Diagnostic System Log Events 18
System Audit Log Events 20
Informational Events in the Verbose Log 20
Driver Verification Debugging Options 21
Code Integrity Event Log Messages 21
Resources 22
Disclaimer
This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.
© 2006–2007 Microsoft Corporation. All rights reserved.
Microsoft, Win32, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Introduction
For both consumer and enterprise users of Windows® around the world, protecting personal and corporate data remains a top concern. Microsoft is committed to implementing new ways to help restrict the spread of malicious software. Digital signatures for kernel-mode software are an important way to ensure security on computer systems.
Digital signatures allow the administrator or end user who is installing Windows-based software to know whether a legitimate publisher provided the software package. When users choose to send Windows Error Reporting data to Microsoft after a fault or other error occurs, Microsoft can analyze the data to know which publishers’ software was running on the system at the time of the error. Software publishers can then use the information that Microsoft provides to find and fix problems in their software.
Windows Vista® relies on digital signatures for kernel-mode code to increase the safety and stability of the Windows platform and to enable new customer experiences with next-generation premium content:
Drivers must be signed for devices that stream protected content. This includes audio drivers that use protected user-mode audio (PUMA) and protected audio path (PAP), and video device drivers that handle protected video path-output protection management (PVP-OPM) commands.
Unsigned kernel-mode software will not load and will not run on x64-based systems.
Boot-start drivers must contain an embedded signature.
The scope of the new kernel-mode code-signing policy is far reaching. For developers who publish kernel-mode software, this policy has the following effects:
For any kernel-mode component that is not already signed, publishers must obtain a software publishing certificate (SPC) and use the SPC to sign all 64-bit kernel-mode software that runs on x64-based computer systems running Windows Vista. This includes kernel-mode services software.
Publishers that provide 64-bit device driver or other kernel-mode software that is already signed through the Windows Logo Program must have their driver catalog files signed with a Windows Hardware Quality Labs (WHQL) signature. To fully test the driver package before submission to WHQL, they must use an SPC to sign the driver catalog file.
In the special case of boot-start drivers, publishers must use an SPC to embedded-sign the driver binary image file for optimal system boot performance. This requirement applies to x86 and x64 versions of Windows.
A driver is said to be boot start if it is loaded by the Windows Vista operating system loader. Boot-start drivers are identified when the driver's INF specifies the start type as “Start=0” or a kernel service is configured with a ServiceType as Kernel Driver or File System Driver and StartMode is “boot”.
The kernel-mode code-signing policy applies to all kernel-mode software on x64-based systems running Windows Vista and to boot-start drivers for both x86 and x64 systems. However, Microsoft encourages publishers to digitally sign all software, including device drivers for both 32-bit and 64-bit platforms. Windows Vista performs kernel-mode signature verification on x86 systems to support protected media content.
This paper describes how to manage the signing process for kernel-mode code for Windows Vista, including how to obtain an SPC, guidelines for protecting keys, and how to sign a driver package by using the tools in the Windows Driver Kit (WDK).
Digital Signatures as a Best Practice
Since the release of Windows 98, Microsoft has promoted driver signing for designated device classes as a way to advance driver reliability, to provide a better user experience, to reduce support costs for software and hardware vendors, and to lower the total cost of ownership for customers.
For device drivers and other kernel-mode software, drivers signed as part of the Windows Logo Program increase end-user confidence in the quality of the software and improve the user experience because a driver's Windows logo indicates that the driver was tested and that the digital signature that accompanies the Windows logo confirms has not been altered since testing.
For most kernel-mode driver packages, a digital signature is provided in a signed catalog (.cat) file. WHQL provides a Microsoft-signed catalog file to distribute with a driver package that meets the requirements of the Windows Logo Program.
The process of creating signed kernel-mode software consists of two distinct but related activities. These can be done in parallel because the software usually is not required to be signed until relatively late in the development process.
Managing the signing process. This is typically handled by publishers’ program management and software release services and includes:
Selecting the appropriate signing option.
Obtaining the necessary certificates.
Managing the digital signature or code-signing keys.
To digitally sign image binary files or catalog files, a software publisher must have a certified code-signing key, which means that a certification authority (CA) has sufficiently established the identity of the publisher.
Implementing the driver to be signed. This is typically handled by the publisher’s development team and includes:
Implementing the driver itself.
Creating a signed driver package for internal testing or release.
These processes are documented for earlier versions of Windows in the WDK and the Platform SDK. This paper describes additional options related to kernel-mode code signing for Windows Vista.
Kernel-Mode Code-Signing Options
Multiple options are available for working with the kernel-mode code signing (KMCS) requirements in Windows Vista. Signing driver files is not required for Windows Vista to load drivers while developing kernel-mode code. Instead, developers can use one of the mechanisms to temporarily disable load-time checks by the kernel on development and nonautomated test systems. However, test signing of driver packages is required to automate installation of a driver package on test systems without having driver installation pop-up menus. The Driver Management Infrastructure (DMI) verifies the driver package signature during installation and warns users of unsigned drivers.
Table 1 compares options for digitally signing kernel modules that Windows Vista supports.
Table 1. Options for Signing Kernel Modules
Signing options
|
Functionality verified to meet logo requirements
|
Identity verified
|
Intended use
|
Windows Logo Program
|
Yes
|
Yes
|
Release
|
KMCS by using an SPC
|
No
|
Yes
|
Release
|
WHQL Test Signature program
|
No
|
Yes
|
Testing
|
KMCS test signing
|
No
|
No
|
Testing
|
The Windows Logo Program verifies correct driver functionality and ensures high quality and reliability. Microsoft digitally signs the driver packages that are submitted to this program. The Windows Logo Program accepts device packages that are installed via INF file for hardware that meets the logo requirements. The driver publisher submits the driver package after completing driver verification tests. Drivers that qualify for the logo receive a Microsoft-signed catalog file. For information about the Windows Logo Program, see “Resources” at the end of this paper.
Developers can sign the driver image file or driver catalog file with an SPC for testing before submitting to WHQL to verify that the driver loads and operates correctly.
KMCS that uses an SPC provides identifiability of the publisher of a kernel module loading into Windows Vista. KMCS does not provide any level of certification of functionality or reliability of the kernel module. If drivers do not qualify for the Windows logo or the logo is not one of the product requirements, the publisher can create a catalog file for the driver package and sign it with the publisher’s SPC.
Important: KMCS does not replace the WHQL program. Microsoft encourages publishers to use the Windows Logo Program to ensure driver quality. KMCS does not require the software publisher to pass the Windows Logo Program testing requirements associated with WHQL.
A signed catalog file is all that is necessary for most driver packages to install and load correctly. The only exception is packages that contain a boot-start driver, which is loaded by the Windows Vista boot loader. These drivers must be signed in two ways:
The kernel-mode driver binary file that is loaded at boot time must have an embedded signature in the binary signed with an SPC. For simplicity, it may be easier to embedded-sign all driver image files in the package.
The driver package installed by using an INF file must also have a signed catalog file—just like driver packages that do not contain a boot start driver—for signature verification during installation.
Manufacturers should ensure that hardware vendors acquire an SPC and sign any boot-start drivers that will be installed on manufacturer-installed systems.
For testing purposes during the development cycle, code signing using a “test” certificate is recommended instead of signing with a release certificate. Windows Vista systems recognize a test-signed binary only when a boot configuration option that allows use of test signing certificates is enabled. Test signing is not enabled by default, and test signatures are not trusted by the majority of Windows Vista systems.
The WHQL Test Signature program is also supported for test signing. Participants in the program can submit driver packages for WHQL test signing. The signature on the test-signed catalog files are generated by a certificate issued under the Microsoft Test Root Authority. The Microsoft Test Root Authority is accepted when the Windows Vista boot configuration setting enables test signing. For information about the WHQL Test Signature program, see “Resources” at the end of this paper.
For both “test” and “release” signing, the development team should follow best practices for key management, as described in “Guidance for Safeguarding Code-Signing Keys” later in this paper.
Test signing is discussed in more detail in “How to Use Test Signing” later in this paper.
The Kernel-Mode Code-Signing Process
Digitally signing a kernel-mode image file or catalog file establishes the integrity of the signed file or files. Software modules should never be modified after the code-signing operation has been performed. Modification of the image file after code signing results in installation-time and load-time signature verification failures. There is one exception to that rule: you can add an embedded signature to an image file after its hash value has been incorporated into a signed catalog file. This does not invalidate the signed catalog file because the code-signing tools do not include the digital signature section of the file when they calculate the file's hash value.
A driver package containing multiple files may be signed by using a catalog file. The driver package must have a signed catalog file that is used to identify the publisher when the driver package is installed and to verify the driver image when it is loaded into the kernel. The catalog file contains a digital certificate that identifies the publisher, plus hashes of the package contents that allow the system to verify that files in the package have not been altered.
As previously mentioned, boot-start drivers must have embedded signatures in the driver image file. Embedded signatures in boot-start driver image files optimize operating system boot performance by eliminating the need to locate the appropriate catalog file when the operating system loader verifies the driver signature.
Driver signing is not required for every build during the driver development process. Developers can disable driver signing enforcement as described in “How to Disable Signature Enforcement during Development” later in this paper.
For step-by-step instructions for kernel-mode code signing see the white paper titled “Kernel-Mode Code Signing Walkthrough.”
The following sections discuss how to obtain and manage certificates. The mechanics of signing driver packages are discussed later in this paper.
| 