Our Recommendations for Driver Signing — Windows 10 and Otherwise

Update (2 June 2016): We now appear to have some definitive guidance from Microsoft on Driver Signing for Redstone 1 and Server 2016.  See this blog post for a summary of the details.  This information supersedes the following guidance, which largely remains intact but is no longer relevant.  

“On and on and on [it] kept goin’…”

There continues to be needless confusion over Windows driver signing requirements.  The Kernel Mode Code Signing (KMCS) program is getting confused with the user-mode and SSL certification changes.  There’s a lot of FUD in the system.  To make matters worse, bloggers who don’t know the first thing about driver development (or Microsoft policy) have decided its their “community duty” to post advice to driver developers on how they should proceed.  On the Internet nobody knows that you’re a dog, after all.

Inspired by these recent events, we thought it might be helpful to clarify the state of things as well as our (OSR’s) recommendations to kernel-mode driver developers.  We do write drivers for a living, after all, and work closely with the folks at Microsoft.  And we promise we won’t tell user-mode devs what their opinions should be, because we readily admit that we don’t know the first thing about user-mode development.

At the risk of confusing everyone’s opinion with the facts, let’s review what we know for sure:

• Microsoft fully intended to implement an “EV only” code signing policy for Win10… with a “transitional policy for folks that hopefully alleviates some of the pressure” (their words).
• Managing EV certificates has proved to be much more difficult and complicated than anyone thought.  While everyone knew that small, individual, developers (hobbyists and makers) were going to have trouble qualifying and paying for EV certs.  This is still a problem that remains to be solved.  However, I don’t think anybody anticipated the problems that requiring EV certs would have for large corporations.The problem for large corporations is that the Certification Authorities apparently want to issue a single physical EV cert per corporation, and not one per group or division.  This creates all manner of difficulties.  Let’s say you’re Big Company X that’s incorporated in Ireland, with your US headquarters in California, with development teams around the world, and a product group in Colorado. How does that Colorado group get the Corporate EV cert to use for signing the products they release to the web?Apparently, time will be required to work these issues out to a reasonable conclusion.
• Microsoft has historically been sensitive to the business concerns of OEMs.  So, if the above problems with the original “EV only” Win10 code signing requirements are seriously impacting OEMs in a significant way, you can be sure Microsoft would be willing to do something to alleviate that impact.
• While we’ve seen few official statements saying EV certs are not required for Win10 KMCS, experience in the field seems to indicate that drivers that are signed and cross-signed the traditional way are not being rejected by Windows 10.  That is, Windows 10 appears to be behaving exactly the same as Windows 8.1 with regards to kernel-mode driver signing.

As a result of the above, it appears that Microsoft has material changed the implemented policy for Win10 Kernel-Mode Code Signing.  There’s even an official FAQ now (yay!) that matches the behavior we’ve all been seeing in the field.  To quote from that policy (as of the end of December 2015):

…quote from Microsoft’s most recent FAQ…

Windows 10 Desktop Attestation Signing

• A dashboard signed driver using attestation signing will only work on Windows 10 Desktop and later versions of Windows.
• An attestation signed driver will only work for Windows 10 Desktop; it will not work for other versions of Windows, such as Windows Server 2016, Windows 8.1, or Windows 7.
• Attestation signing supports Windows 10 Desktop kernel mode and user mode drivers. Although user mode drivers do not need to be signed by Microsoft for Windows 10, the same attestation process can be used for both user and kernel mode drivers.

Windows 10 Earlier Certificate Transition Signing

• A driver signed with any certificate issued after July 29th, 2015, with time stamping, is not recommended for Windows 10.
• A driver signed with any certificate that expires after July 29th, 2015, without time stamping, will work on Windows 10 until the certificate expires.

… end quote…

To summarize the above, the policy now seems to be that drivers that are signed with SHA1 certs and cross-signing in the traditional way will work on Windows 10 (until the cert used for signing expires).  The policy also continues to encourage using an EV cert for code signing on Win10.

So, what do we here at OSR make of all this?  Our recommendations are (as usual) very simple:

• If you qualify for an EV cert, and your company can manage the logistics associated with using one, by all means get an EV cert and use it to sign your drivers.  Use it to cross-sign your drivers, if those drivers are going to run on systems other than Win 10.  While Microsoft may abandon the requirement for an EV cert entirely at some point, your being proactive by using an EV cert certainly won’t hurt anything.  And if the EV cert does become required, you’ll be ready.  Not to mention, if an Enterprise Edition user enabled Device Guard and requires EV cert signing, your drivers will be ready.
• Submit your Win10 driver packages to the sysdev portal for attestation signing.
• Start running the HCKs and getting your driver to pass those tests right now.  Remember that a driver that’s passed compatibility testing (what was formerly called “logo” testing or “WHQL testing”) will work on systems all the way back to Vista.  Not to mention, the current plan is that your driver will have to pass the HCKs in order to be able to load on Windows Server 2016.Passing the HLKs can be either very easy (for most device drivers) or ridiculously challenging (for some other driver classes, such as File System Filters).  And if you DO pass the HCKs, you won’t have any of these code-signing issues… because your Microsoft-signed driver and driver package will work all the way back to Vista.
• If you need to support Windows 7 (and who doesn’t, right?) then either (a) sign with your EV cert and cross-sign, and clearly document that anybody loading your driver will need to install the Win7 patch that enabled recognition of SHA2 certs, or (b) sign with your existing SHA1 cert and cross-sign in the traditional way.

When we “net out” all of the above, the most surprising conclusion that we have come to is that “it might just be better and easier to pass the HCK tests than the fool with the rest of this crap.”  This is especially true if your driver will need to support Server 2016.We’re publishing the initial version of this post at the end of December 2015.  We will update this post when/if we get more information.  Of course, watch the OSR Dev Blog (and the OSRHints mailing list) for any changes.