Questions and Answers: Windows 10 Driver Signing

Update (2 June 2016):  Traditional cross-signing works for all Windows versions prior to Windows 10 Anniversary Update and Windows Server 2016.  Whether you need a SHA1 or SHA2 certificate depends on the version of Windows.  All versions of Windows from Windows 7 onward, when properly updated, will accept SHA2 certificates.  You do not need to SIGN with an EV certificate, but you’ll need an EV Certificate to submit drivers to the SYSDEV portal (for either Attestation Signing or for WLK/WHQL Signing).

The latest information on driver signing requirements for RS1 (Windows Anniversary Update) and Windows Server 2016 can be found in our recent blog post on this subject. This appears to be the definitive word… until we hear otherwise.

Having said that, the following interview with Mr. Murphy is still a pretty interesting read.  Enjoy.

Back in March we described the basic information about the changes to driver signing requirements for Windows 10.  Recall that the big news was that a Microsoft signature would be required by Win10 to load kernel-mode drivers.  To get that signature, you have to sign a submission using an Extended Validation (EV) Code Signing Certificate and upload your driver package to the Microsoft SysDev portal.  You do not need to run or pass any Microsoft certification, logo, or compatibility tests.  You just need to sign your driver appropriately, agree to some conditions, and submit your package to Microsoft via SysDev for signature.  This procedure is called “attestation signing” because when you upload you declare (that is “attest”) that you’ve tested the driver, will monitor sysdev for driver problems, and will fix any issues that are reported.

Recently, we started hearing from the community, via NTDEV and elsewhere, that there was confusion about these changes. When we sat down to work through the details ourselves, we discovered that there were lots of things we didn’t understand regarding the implementation details of this program.

So, we sought out answers.  And Microsoft Program Manager James Murray was quick to help!  Earlier this week James spent several hours in a Q&A with OSR’s Peter Viscarola.  Here’s what they discussed:

Peter: When will the requirement for a Microsoft signature start to be enforced on Win10 Client systems There’s a ton of confusion in the community about this.

James: The enforcement of this requirement will begin on Windows 10 RTM.  The requirement will be enforced at both install and load times. The intent of the enforcement is to raise the bar for who can run trusted code in the Windows Kernel.

Some caveats to the above:

• Only Kernel Mode drivers are affected by this. User mode drivers can continue being signed the same way they are today.
• We do support a transitional policy for folks that hopefully alleviates some of the pressure. Windows 8 style kernel mode code signing will continue to work, as long as the cross-signing [?? See the Corrections and Updates section below for comments– editors] certificate was issued prior to Windows 10 RTM (the cut off). The default state for this policy is turned on, but IT admins can choose to turn it off using a new feature in Windows 10 called configurable code integrity. That’s a good thing for folks to be aware of before making the decision to continue using their cross-signing certificates. This document gives a high-level of these changes. 

Peter: Does the new Win10 signing policy apply to x64 only, x64 and x86 with UEFI Boot only, or ALL x64 and x86 platforms?

James: The short answer to this one is that it applies to both 32 and 64 bit platforms. The longer answer is that, as long as Secure Boot is enabled both platforms will enforce the same requirements. Disabling Secure Boot will open up x86 to unsigned drivers, while x64 will still enforce signed drivers – but not that they are Microsoft Signed (cross-signing is sufficient).

Also many details of the driver signing policy for x86, x64, and ARM (as well as links to things like the policy for ELAM) are described here.

Peter: Once the Microsoft signature is required, is it required to install a driver (the signature on the package) or is it required on the image to load the driver?

James: The signature will be evaluated at both times. When PNP installs the driver, and when the platform attempts to load that driver into memory for execution. The Sysdev signature will satisfy both of these scenarios.

Peter: Let’s talk a bit about the new signing process itself for a minute.  What are the requirements for getting a sysdev account – Do you now need an EV Cert for that?  Can the EVCert be from any CA?  Previously, people were required to have a specific cert from Verisign/Symantec.

James: The requirement for a Sysdev account is any codesign certificate. However, some workflows on the website will only be accessible if your submission package is signed with an EV certificate. These workflows are: UEFI Submission, LSA module submission, and – beginning 90 days after RTM – Hardware Compatibility and Driver Signing. Said another way, EV will let you do anything on the site, where a standard certificate will limit your participation somewhat.

The certificate must come from one of our supported CAs. Today those are Digicert and Symantec. However, we are adding more CAs at RTM — support is coming for Globalsign and WoSign.

Peter: The new driver signing procedure indicates you have to build a CAB file to upload for signing, and you sign that CAB file with your EV Cert.  Why a CAB file (and not something common like a ZIP archive)?  How do you build the CAB file?  Is there a particular process or tool to use?

James: CAB was chosen as CABs themselves are PE files. This simplifies the signing process somewhat, as signtool.exe has “native” support. If we had chosen a ZIP Archive (note, we’d still like to move that direction), we would have needed to provide a separate signing mechanism. Something akin to the HLK studio, a small tool with the capability to sign ZIP or OPCs.

The CAB can be built with makecab.exe, which is a utility built into Windows. However, there is no particular requirement for the tool that’s used. Any process which results in an archive with the correct structure would be great. I’ve provided an example (show at the right) that could be used as a starting point for folks who are new to makecab.

Peter: Does test signing still work the way it did before Win10?

James: Testing signing is fully supported and does not require a Microsoft signature. More information on how to test-sign a package can be found here. 

Of course, enabling test signing does require making configuration changes to the target machine, such as turning off secure boot. Therefore, it’s truly only a method for development and testing. Once the developer decides to release a driver and update it in the field, they must return and sign that release candidate through Microsoft.

Peter: Can a single driver package contain executables for multiple architectures?  For example, it’s common to create a SINGLE driver package that works on either x86 or x64 systems.  Is this still allowed (there’s been some talk that each package can only be a single architecture)?

James: Multiple-architecture is fully supported. Folks should feel free to continue that behavior. There’s a limitation in our new “attestation” signing pipeline, but that does not prevent dual-architecture packages. The limitation is that all driver packages included in the submission cab must support the same set of architectures. If you submit one submission package with three driver packages that all support both x86 and x64, then everything will be great.

The problems only arise when you try to mix-and-match and create one submission CAB that contains multiple driver packages with different architectures. Said another way, instead of creating one submission with two driver packages – each that support one of x86 and x64 – you should submit two separate submission CABs.

Peter: Is it possible to get a Microsoft signature for an uploaded package that applies to down-level operating systems also?  In other words, I want to create a single driver package that works for Windows 7 through Windows 10.  How can I do that?  Currently, the sysdev portal only allows you to select Windows 10 Client x86 and Windows 10 Client x64.

James: This is definitely possible, but you need to use the Hardware Compatibility route (that is, you need to pass the HLK tests). By design, the new “attestation” route only supports Windows 10.

Peter: Has any thought been given to how hobbyist, “maker”, or “community” developers will be affected by the new policy of requiring EV Certificates?  If I write a driver for a device as a “maker”, there’s no way I can qualify for an EV Cert.  How will I be able to share my cool new doodad and benefit the community?

James: This is an area that has been a little bit of an ongoing struggle for us internally. Of course we love “makers”, and we want very much to support them. However, we’re also trying to balance that with the security of the platform. It’s a difficult struggle. If we make it easy for “makers”, then we’ve likely also made it easy for folks to run code we’d rather not have in our Kernel.  I don’t have an easy answer for this off-hand, but I can assure you that it is not lost on us and we want to do something to support this community.

Peter: Do the new signing rules for Windows 10 apply to both kernel-mode drivers and user-mode drivers, or are user-mode drivers exempt?

James: User mode is exempt. This is a kernel-mode only change.

Peter: What are the rules for driver code signing for ARM-based systems, for example, for Windows 10 IOT SKUs?

James: IOT will follow the Windows Ingestion Client for driver signing. This has historically been the mobile signing pipeline, but IOT will also follow that route. And, yes, we want very much to converge those pipelines in the future.

Peter: How do we sign drivers that are not necessarily traditionally installed with an INF?  For example, kernel services (non PnP software only drivers) or certain filter drivers?

James: This is another issue that we’re treating as a bug internally. The Microsoft signing pipelines are inherently reliant on an INF to determine the correct signing behaviors. The best solution I can offer currently is to create a “dummy” INF that the service can use as an anchor to provide the correct signing.

Peter: Can you tell us anything about what the signing requirements will be for drivers for Windows Server V.Next?  There have been some public statements by third parties that all drivers loaded on Windows Server V.Next systems will not only need to be signed by Microsoft, but they will have to pass the WLK tests (what was formerly referred to as “Logo testing” or “Certification”).  Is this true?

James: As far as I’m aware, the signing requirements for Server vNext will be the same as those for Windows 10 Client.  However, they are more restricted in one important aspect. The new “attestation” driver signing workflow is not supported on Server. Drivers signed with that pipeline will not work on Server systems. The only Microsoft signing pipeline that supports Server is the HLK Compatibility route.

Peter: Will attaching a debugger still bypass code signing checks?

James: Yes, it will. There’s no changes in this behavior for Windows 10.

Peter: How do I make programmatic driver signing submissions? If I can’t, is there a plan to allow that? If so, when?

James: Today, there’s an API for Hardware Compatibility submissions. This means that you can programmatically create submissions, poll for status, and download your signed files upon completion. Instructions for getting started are here.

However, the new “attestation” Driver Signing pipeline is not part of the initial wave of APIs. We’ve heard your feedback loud and clear, and are working to come up with a plan and an ETA on when the APIs will be enhanced to include support for the new pipeline. Unfortunately I don’t have a finalized roadmap or date to share at this time.

Peter: James, thanks.  You’ve been very helpful.  Just one more question: If folks out in the community still have questions, where can they get answers?

James:  The best way to get support on your Microsoft Driver Signing and Compatibility submissions is to contact sysdev@microsoft.com. For hardware and driver testing, and use of the HLK, there’s the MSDN Hardware Testing and Certification forum.  And finally, for general driver development questions, there’s the MSDN WDK forum and, of course, OSR’s NTDEV list.

OSR’s Recommendations

[12 January 2016]  In the past few months, things have gotten increasingly confusing regarding this topic.  For a review of our recommendations regarding Kernel Mode Driver Signing, please see our most recent blog post on this topic.

Corrections and Updates

The original interview text, reviewed and approved by Mr. Murray, used the text that currently appears in the article. That is, it said “as long as the cross-signing certificate was issued prior to Windows 10 RTM” (emphasis added) — This generated some significant discussion in the community and as a result of that discussion we later removed the phrase “cross-signing” from the article thinking it was in error.  As time has passed, other discussions indicate that the original wording may have been correct.  We have thus restored the original wording.  We’ll update this article when we have more information.

 

---

OSR thanks James Murray for being so helpful and generous with his time on short notice.