Today in Driver Signing

Latest Update (2 June 2016):  As further proof that the state of the world DOES change every day, there is now a very useful video on Microsoft’s Channel 9 that answers many of our questions.  See our latest blog post for a description of the changes and a link to the MSFT presentation from PlugFest.

If you’ve been following the events of the past couple of years regarding driver signing, you’ll know that there’s been a lot of stuff that’s unclear.  For those of you who don’t live and breathe Windows driver policies, let me summarize for you:  Prior to the introduction of Win10 (TH1… can’t remember which version, code name, or build of Windows is which?  Us either… Check out this handy blog post), Microsoft announced that Windows 10 would not allow installation of drivers unless the driver was signed via the SysDev portal (that is, signed by Microsoft, though this will not require the driver to pass the HLK tests).  With the help of Microsoft PM James Murray, we tried to flesh out the details of this policy.  Throughout the Windows 10 release cycle, this policy changed.  The current policy is murky, even with the clarifying statements that have been issued, but seems to suggest that in Win10 TH1 and TH2, you can still install drivers using the long-standing, traditional method of cross-signing.  This is supported by lots of real-world experience.   The driver development community breathed a collective sigh of relief.

Fast forward to recent times.  The pending release of Windows 10 Anniversary Edition (code name Redstone 1, RS1 for short) scheduled for release in July of 2016, once again raises the question of “will the long-standing driver signing policy change”? Community experience as described in this NTDEV thread seems to indicate that the requirement that newly installed kernel-mode drivers be signed by the SysDev portal will indeed start to be enforced in RS1.  There are also reports that this will only be the case if Secure Boot is enabled on the platform.  Various people have tested this.

But, for you dear reader, I decided to test things myself.  My goal was to be able to make some definitive statements about what was going on.  The results were not what I expected.

Can You Install a Cross-Signed Driver on RS1?  Yes.

I started my testing on a spare Surface Pro 1 we had kicking around.  Because the Surface Pro 1 isn’t super-happy about booting random USB drives (no, I don’t know why… but I don’t know anybody who’s managed to get it to work), I reimaged the system using the standard Windows 8 restore disk.  I then downloaded Build 14295 from the Windows Insider web site and attempted a clean-install from the ISO (running the install from the Windows 8 system).    I then waited for the “Fast Ring” to push me Build 14332, which dates from 22 April 2016.  Note: Secure Boot was enabled on the system. The debugger was not attached, and kernel debugging was not enabled.  Test Signing was not enabled.  We’re talking a standard system install of a “Fast Ring” system here.  Nothing cute.

Just to make sure things were sane, I started by trying to install my software-only driver.  I didn’t sign anything. The results were as expected, and shown in Figure 1.  The driver wouldn’t install.

The setupapi.dev.log file (Figure 2) had the usual error messages stating “Driver package catalog file does not contain a signature, and Code Integrity is enforced” and “Driver package failed signature validation” — All good so far, right?

Then, I signed the driver executable and catalog files in the “traditional” way using the appropriate cross-signing certificate with one of OSR’s Release Signing certificates (for the record, this is a Verisign issued Class 3 Code Signing certificate issued in March of 2016 using SHA-256, but without Extended Validation).  I copied the signed package to the RS1 system and attempted the install.  I was greeted with the familiar message box shown in Figure 3.  And the installation worked perfectly (Figure 4).

Whoa!  Wasn’t this supposed to fail?  Isn’t this the whole point we’re trying to demonstrate?  Isn’t RS1 supposed to require newly installed drivers to be signed by Microsoft?  Hmmm… well, in this test, not so much.

After doing this test, I remembered that there was some speculation that if the system was an upgrade from a previous version, it would load and install drivers that were signed in the “traditional” way.  To test this out, I downloaded the latest Insider Program ISO (build 332) and installed it to a brand-new VMware virtual machine.  That should fail, right?  A new install of the latest RS1 build? See Figure 5.

Sigh.  It still works.  So, let’s summarize:

• You can’t install an unsigned x64 driver. Duh.
• Upgraded RS1, Build 14332: Traditionally signed (and cross-signed) driver installs fine.
• New install of RS1, Build 14332: Traditionally signed (and cross-signed) driver installs fine.

So… at least based on tests of the latest Insider builds available, no unique signing procedure is necessary to get drivers to load on Windows 10 Anniversary Update.

However, according to that same thread on NTDEV thread that I referred to previously, the requirement may kick-in if the system is both newly installed and booted in “Secure Boot” mode.  Unfortunately, we weren’t able to try this.  Why?  Because we couldn’t find a system at OSR that was both (a) capable of booting in Secure Boot Mode, and (b) able to be clean-installed.  (And here’s an interesting digression: Have you ever tried to do a clean install on a Surface Pro 1?  No?  Let me just say that you should give it try sometime when you have a few days to waste.  In short, it’s not happening no matter what you do.  Upgrade?  Yes.  Actual clean install?  No.  It’s maddening.  Why can’t the damn system boot a USB drive with the install kit on it, like a normal system?  Arrrgh!)

Does Attestation Signing Work?   Is it a PITA?

While we were wasting our time, we did have one more thing that we wanted to try.  We wanted to walk through the Attestation Signing process to see if it’s as easy as it should be… and to see on which systems you could install Attestation Signed drivers.

The Attestation Signing process is reasonably well described on MSDN, in a Dev Center post by Don Marshall.  We’ll walk you through the process and try to make it a bit easier.

Before you can upload your drivers to the Microsoft SysDev portal for Attestation Signing, you have to take your driver package and bundle it into a CAB file.  Right.  Not a ZIP file.  A CAB file.  Microsoft provides the lovely MakeCab utility, which works but is the very definition of Royal Pain In The Ass.  For example, just to put stuff into a CAB file using MakeCab, you have to create a separate DDF file that describes what you want MakeCab to do.  Screw that, I say.  I recommend that you use a very nice little GUI utility named IZArc (that’s an “I” not an “L”), that you can download from here.  No, I have no relationship to and don’t know anything about the author.  But his utility worked swell for me.

So, first… sign (and cross-sign) everything you can in your driver package.  Sign the CAT file, sign the SYS file (or files), sign any DLLs, applications… just sign everything.  It’s yours, you wrote it, you should sign it.  Note that the Attestation Signing signature will overwrite (not add to) the signature on your CAT file (very annoying), but will actually be added to the signature(s) you provide in your SYS file.

So, use IZArc to stuff everything in your driver package into a CAB file.  Be careful in formatting the CAB file:  Put the driver package in its own directory.  Do not put any files in the root directory of the CAB file.

Recall that in order to be able to submit your CAB file to SysDev, you need to sign it using your super-special SysDev EV Code Signing Certificate.  So, off I went to OSR’s vault to retrieve our EV Code Signing Cert hardware token from its ultra-secure location (Figure 6). I signed the CAB file I created using this certificate. You can see what I put into the CAB file, the CAB file itself, and the signature info for the CAB file, in Figure 7.

So, to begin the Attestation Signing process itself, it’s off to the Microsoft SysDev Portal at https://sysdev.microsoft.com.  Oh… by the way… we couldn’t get IE 11 to work properly with SysDev.  We had to use either Chrome or Edge.  So, Chrome it was.  Note that we had previously arranged for SysDev access, signed all the necessary agreements, and verified our EV Code Signing Certificate.

When you first login to SysDev, you’re greeted with the interface shown in Figure 8.

To upload a driver to sign by “Attestation”, click the Create Driver Signing Submission option indicated by the red arrow in Figure 8.

You’ll next be taken to the File Signing Services page where you can fill out the “Create driver signing submission” form shown in Figure 9.  It’s pretty simple to fill out.  Nothing tricky here at all.  Click “Submit” and you’re on your way.

You’ll get a submission ID and you can monitor the progress of your submission via the “Manage submissions” page.  It took me less than 30 minutes to get an email from “sysdev@microsoft.com” telling me that my driver had been signed and was ready for download (Figure 10).

From there, all I had to do was to go back to the Manage Submissions page, click on the submission ID, and download the signed package (see Figure 11).

That’s all there is to it.  Finished!

Just to make sure that Attestation Signing actually worked, we successfully installed the driver package on a newly installed RS1 system.  It was nice to see that there was no pop-up asking “Do you trust this vendor?” – The installation procedure worked silently, just as it would if the driver had passed HLK testing.

We only had one question left:  Will the Attestation Signed driver install on down-level version of Windows?  To test this, we tried to install the driver on a newly installed Windows 8 system.  And, predictably but unfortunately, this installation did not work as shown in Figure 12.

Wrap Up

So, in terms of signing, that’s where things stand as of today.   Life would be much easier if Microsoft would just tell us what the signing policy is going to be.  However, until that time, we get to spend our time testing out different theories.

We wish we were able to test a newly installed RS1 system for you… perhaps if an OEM or IHV would like to send us a system that supports Secure Boot, we can do that testing.