Back in January of 2006, Microsoft announced - much to developers' dismay - that all kernel drivers on 64-bit Windows systems must be signed. Signing is defined as:
the process of assigning an encrypted digital signature to executables in order to confirm the software's author and to guarantee that the code has not been altered or corruptedOnce I ported my client's driver code to 64-bit, I found myself in an "uh-oh" situation: how do I test the changes on my development systems without having my client's digital signing certificate? A digital certificate is:
a digital signature from a certificate authority (CA) that contains a private key used to sign some software, which must match the public key in the CA's certificate installed on a user's systemThe private key (PK) is necessary for me to sign the driver executables, and is something that the software vendor (my client) must not pass around to anyone else - including me - lest it fall into the wrong hands and be used for malicious signing. That gets us back to my dilemma: how do I test without the PK?
The answer provided by MSFT is Test Signing. The Windows WHDC site contains a good white paper on this subject that has decent step-by-step procedures. The basic idea is this: a developer can create a Test Certificate, which is used on the development systems to sign and validate executables. The catch is, the executables will only work if the target test system is configured to boot into a special Test Signing mode. This is done on the target system with the BCDEDIT command. Note that, in the past, it was also possible to boot Windows into a "Disable Driver Signature Enforcement" mode, where signatures were ignored. That option, while still visible via F8 boot options, does not actually work anymore.
Next time: Test Signing using catalog files.
