Use the following steps to obtain an SPC for signing your kernel-mode software that meets the mandatory kernel-mode code-signing policy:
1. Obtain an SPC from a commercial CA that issues digital certificates for signing kernel-mode code. The list of CAs who provide SPCs (or code-signing certificates) that can be used for kernel-mode code signing is available at the “Microsoft Cross-certificates for Windows Vista Kernel Mode Code Signing” Web page listed in “Resource” at the end of this paper.
2. Download a corresponding cross-certificate from the “Microsoft Cross-certificates for Windows Vista Kernel Mode Code Signing” Web page for the root CA that issued the SPC. The cross-certificate is used in the digital signature for kernel-mode code so that the signature can be verified up to a trusted root authority known to the Windows Vista kernel.
When you request an SPC from a commercial CA, follow the instructions on the CA’s Web site for how to acquire and install the code-signing certificate on the machine where you will use the private key to sign code.
Guidance for Safeguarding Code-Signing Keys
The cryptographic keys that are the primary part of the code-signing process must be well protected and treated with the same care as a company’s most valuable assets. These keys represent a company’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 company. 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 on safeguarding private keys, refer to the white paper titled “Code Signing Best Practices.”
Using Cross-Certificates with Kernel-Mode Code Signing
KMCS uses cross-certificates as part of the code-signing process. A cross-certificate is an X.509 certificate issued by one CA that signs the public key for the root certificate of another CA. The Windows Vista operating system loader and kernel recognize cross-certificates in verifying driver signatures. The cross-certificates allow the kernel to have a single trusted Microsoft root authority, but also provide the flexibility to extend the chain of trust to multiple commercial CAs that issue SPCs.
Cross-certificates are issued by the Microsoft Code Verification Root authority, which is trusted by Windows for kernel-mode validation. Figure 1 illustrates the certificate chains for a cross-certificate issued by the Microsoft Code Verification Root for a commercial certification authority, the “XYZ Root CA”.
Figure 1. Cross-certificates
Cross-certificates enable developers and publishers to use SPCs to sign kernel-mode software. Developers who use KMCS download the correct cross-certificate (.cer) file to the system where the digital signature operation is performed. Publishers are not required to distribute the cross-certificate file with their software or driver package. The cross-certificate is included with the digital signature on the driver image file or driver package catalog file. Users who install the driver package are not required to do any configuration steps for Windows Vista to verify the digital signature that includes a cross-certificate.
Important: The version of SignTool in the WDK or Windows Vista Platform SDK is the only one that currently supports adding cross-certificates to a digital signature. Previous versions of SignTool in the Windows Server 2003 Platform SDK or DDK do not support adding cross-certificates.
Cross-certificates for multiple CAs to use for kernel-mode code signing are available for download from the Microsoft WHDC Web site. For more information, see “Microsoft Cross-certificates for Windows Vista Kernel Mode Code Signing” in “Resources” at the end of this paper.
Details on how to add the cross-certificate to the digital signature is described in “How to Sign a Catalog File” and “Adding an Embedded Signature to a Driver Image File" later in this paper.
Verification during Driver Installation and Loading
When a driver is installed on a system, Windows verifies the digital signature on the driver package. During installation, the contents of the driver package are copied to the correct system locations and the system configuration is updated. However, the driver is not actually loaded into the running kernel. To verify the driver package, the digital signature on the driver package is verified and each certificate in the certificate path is checked, up to a known trusted root CA. For driver installation checks and Device Manager signature checks, the known trusted root authorities are defined in the local machine Trusted Root Certification Authorities certificate store.
When a driver is loaded into kernel memory, Windows Vista verifies the digital signature of the driver image file. Depending on the type of driver, this can be either the signed hash value in the catalog file or an embedded signature in the image file itself. The cross-certificates that are used when signing the kernel driver package are used for the load-time signature verification; each certificate in the path is checked up to a trusted root in the kernel. The load-time signature check does not have access to the Trusted Root Certificate Authorities certificate store. Instead, it must depend on the root authorities that are built into the Windows Vista kernel. The Microsoft Code Verification Root is one of the root authorities trusted by the Windows Vista kernel and operating system loader.
Figure 2 is an example of how certificate paths are validated during digital signature checks for a driver with a signed catalog file. When the driver package is installed, the certificate path validation verifies up to the Trusted Root Certification Authorities in user mode (shown on the left side of the figure). When the driver image file is loaded into the kernel, the certificate path is validated by using the cross-certificate to the Microsoft Code Verification Root in the kernel-mode trusted roots.
Figure 2. Certificate path verification for driver installation and loading
Generating Test Certificates
Test certificates are used in place of SPCs for test signing kernel-mode software modules that are not for distribution or release outside your organization. Test signing involves applying a digital signature to kernel-mode binaries or driver package catalog files for internal testing purposes. Test signing is discussed in more detail in “How to Use Test Signing” later in this document. A cross-certificate is not required when using a test certificate for kernel-mode code signing.
Test certificates can be generated by using an enterprise CA or using the Certificate Creation Tool (MakeCert). For more information about using an enterprise CA for issuing test-signing certificates within your organization, see the white paper titled “Code Signing Best Practices.”
In the following example, MakeCert generates a test certificate issued by the default test root, stores the private key in a key container, and outputs the certificate to a certificate store and a certificate file:
Makecert -r -pe -ss SubjectCertStoreName -n “CN=CertName” OutputFile.cer
The arguments to MakeCert in the example do the following:
-r
Creates a self-signed certificate, that is, a root certificate.
-pe
Makes the private key that is associated with the certificate exportable.
-ss SubjectCertStoreName
Specifies the name of the certificate store that contains the root certificate.
-n "CN=CertName"
Specifies a name for the certificate. If a certificate name is not supplied, the default name of the certificate is "Joe's Software Emporium".
OutputFile.cer
Denotes the name of the file in which the root certificate is saved.
An example command script that uses MakeCert is available in the WDK. The script file name—selfsign_example.txt—is located under the “bin\selfsign” directory.
Before you can install your driver package, you must add your test certificates into the certificate store on the target test machine. The following example shows how to add the test certificates to the Trusted Root certificate store and the Trusted Publishers certificate store on the target test machine.
certmgr.exe -add OutputFile.cer -s -r localMachine root
certmgr.exe -add OutputFile.cer -s -r localMachine trustedpublisher
The arguments to the Certificate Manager Tool (CertMgr) in the example do the following:
-add
Adds the certificate in the certificate file to a certificate store.
-s
Indicates the certificate store is a system store.
-r
Indicates that the registry location of the system store is under the HKEY_LOCAL_MACHINE key.
Root or trustedpublisher
Indicates the name of the system certificate store.
For more information on MakeCert and CertMgr, see “Resources” at the end of this paper.
| 