Yet another query about driver signing

Like a lot of people, I need to sign drivers so that they will load on all platforms from Vista/Server 2008 onwards, including Server 2016. As such, I need to go through the WHQL signing process and am putting together a hardware environment in which to run the various tests.

Will it be good enough just to run the tests on, for example, a Vista machine and a Server 2016 machine or must the tests be run on every single platform that I want to target?

To ask the question another way, are signatures provided on the basis of test results from one OS version ever valid on other OS versions, e.g. running the tests on Win 7 and loading the driver on Win 8? If not, what is the mechanism that prevents this? I appreciate that not all systems can or will accept certain signatures due to the hash algorithm that was used but would expect that a Microsoft signature is valid on any system that’s capable of verifying it.

Any guidance would be appreciated - if I have to set up a physical machine for every version of Windows we support this is going to get expensive and time-consuming!

I was going to answer this post. Then I Googled a little bit to make sure my answer was correct, and to perhaps give you a page URL for more info.

I was so confused by what I read, I have nothing I can share.

Now, for sure, I’m not the guy at OSR who does HLK/HCK testing. But to say this stuff is confusing is a considerable understatement.

Peter
OSR
@OSRDrivers

I have no problem installing drivers on Server 2016 that are not HLK signed.
They do use the portal to get signed. These drivers are not PNP drivers.
These same drivers would not load under the eval version of Server 2016. I
assume that this is because the SHA1 cert was issued prior to Jan., 2016.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Wednesday, November 2, 2016 3:37 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Yet another query about driver signing

I was going to answer this post. Then I Googled a little bit to make sure
my answer was correct, and to perhaps give you a page URL for more info.

I was so confused by what I read, I have nothing I can share.

Now, for sure, I’m not the guy at OSR who does HLK/HCK testing. But to say
this stuff is confusing is a considerable understatement.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at:
http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>

@Peter: Thanks, if even you don’t know the answer then I feel less stupid for asking the question!

@Bill: Interesting. I did wonder if non-PNP drivers would somehow be exempt from the blanket statement that all drivers must be WHQL-signed before they’ll load on Server 2016. Our drivers are non-PNP so that is good news that you’ve had success, but I worry that Microsoft still plan to enforce the WHQL requirement but haven’t done so with the initial drop - like what they did with attestation signing not being enforced until Redstone. We’ve found that some of the things we thought were hard and fast rules (e.g. attestation-signed drivers refusing to load on anything prior to Windows 10) simply weren’t true, at least for our drivers, as they load without issue on 8.1 after being signed by the portal.

A couple of follow-on questions then:

  1. Has anybody seen definitive statements from Microsoft relating to signing requirements for non-PNP drivers? Does anybody know of any specific reason why PNP and non-PNP requirements would be different?

  2. Is secure boot relevant when considering signing for Server 2016?

It would be really useful if Microsoft provided a web page where you could input all of the parameters specific to your situation (target OS set, secure boot settings, driver type etc.) and be told exactly what signing methods will and won’t work for you and why. Similarly it would be useful to be able to input information about a driver you’ve produced and signed and be told which target platforms it will load on and why/why not. It doesn’t feel like such a tool would be difficult to create as long as you had a complete understanding of the signing logic, which Microsoft presumably do even though they’re not communicating it particularly well.

> 2) Is secure boot relevant when considering signing for Server 2016?

According to reports here, the actual behavior of drivers on S16 is the same as the behavior of drivers on Win10 RS1. IOW, you need an MSFT signature if the Secure Boot is enabled but not otherwise.

Peter
OSR
@OSRDrivers

xxxxx@osr.com wrote:

> 2) Is secure boot relevant when considering signing for Server 2016?
According to reports here, the actual behavior of drivers on S16 is the same as the behavior of drivers on Win10 RS1. IOW, you need an MSFT signature if the Secure Boot is enabled but not otherwise.

And it’s important to remember here that, for now, “MSFT signature” can
be either attestation or WHQL.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Ishan, did you find the answer about testing for multiple systems?

Thanks,
Roney

Roney, no I didn’t unfortunately. I’m currently trying to decide if what Peter and Tim have said about S2016 signing requirements being the same as Win 10 signing requirements means that I don’t have to bother with WHQL (thanks both).

It appears that today we can get away with just attestation signing, but who’s to say that Microsoft won’t change the rules with the next drop of S2016?

Also keep in mind that your enterprise customers can use Device Guard and enforce WHQL signing regardless of Microsoft’s default policy.

My guess is that for S16, they are playing the same game as for RS1: Anything signed before 2016 gets a 100% free pass. As of today, you can still load an expired, SHA1 driver without any problems (except if Device Guard is active with certain policies).


Best regards,
Alex Ionescu

Good point, thanks Alex.

Coming back to the non-PNP issue, it feels like they could well be excempt from the WHQL signing requirement. I’d be interested to know whether my logic below seems reasonable to other people or not.

Non-PNP drivers don’t have .cat files, therefore can’t have WHQL signatures. As such, attestation signing is the highest level of trust that a non-PNP driver can ever achieve. This must mean that either:

  1. Non-PNP drivers might become disallowed at some point in the future if WHQL signing is strictly enforced. I guess this would mean non-PNP drivers would need to be transformed into PNP-like packages using MakeCat (https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/creating-a-catalog-file-for-a-non-pnp-driver-package)

or

  1. WHQL signing is simply not relevant for non-PNP drivers and they will continue to load without issue on Windows 10 and Server 2016 as long as they are attestation signed.

> Non-PNP drivers don’t have .cat files, therefore can’t have WHQL signatures.

It depends on what you mean by “having a WHQL signature.” If you mean having a WHQL-signed catalog file, then, yes, that is true. However, it could still have a WHQL signature embedded in the binary. (The information at the bottom of https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/whql-release-signature is dated.) We have had success with this by including a dummy INF in our HLKX package for non-PnP drivers, much as we have to do for signing similar drivers using attestation.

The details for the MS signature that is embedded reveal the following key usage:

Code Signing (1.3.6.1.5.5.7.3.3)
Windows Hardware Driver Verification (1.3.6.1.4.1.311.10.3.5)
Windows Hardware Driver Extended Verification (1.3.6.1.4.1.311.10.3.39)

The details for an attested MS signature are as follows:

Code Signing (1.3.6.1.5.5.7.3.3)
Windows Hardware Driver Verification (1.3.6.1.4.1.311.10.3.5)
Windows Hardware Driver Attested Verification (1.3.6.1.4.1.311.10.3.5.1)

So, it’s possible that the OS could discriminate based on the WHQL-ness of even non-PnP drivers. What do you lose by not having the catalog file? All of the OS version compatibility information that’s in the meta-data, for one.

Also note that in the particular case of Boot Start drivers (of the PNP or non-PNP variety), none of the new Windows 10 driver signing stuff is currently enforced. This will change in the future. (https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/)

We’ve found that some of the things we thought were hard and fast rules (e.g. attestation-
signed drivers refusing to load on anything prior to Windows 10) simply weren’t true, at least
for our drivers, as they load without issue on 8.1 after being signed by the portal.

Now *that* only applies to drivers with an INF and CAT. The catalog file contains the OS compatibility information, so anything that’s only signed for Windows 10 will be blocked at PNP install time on older OSes. The embedded signature in a driver binary has no such information, however, so installing it (with SCM or cramming some keys in the registry or whatever) works fine.

Actually, “blocked” is too strong a term. On Windows 7 you first get the red dialog saying that the publisher cannot be verified. If you choose to cancel, you get the “Windows encountered a problem installing the driver software for your device” dialog with the explanation “The software was tested for compliance with Windows Logo requirements on a different version of Windows, and may not be compatible with this version.” However, you can choose to proceed with the install, and the driver will work fine save for the device properties showing “Not digitally signed.” On Windows 8.1 you only get the latter dialog, and no way to force an install of the driver.

That does make me wonder, though: What are the technical benefits of WHQL signing for anything other than the oldest OS your driver supports? If you don’t care about the logo or any of the other business benefits, is there any reason to go through the pain of HCK/HLK tests on every single supported OS?

Thanks for the valuable information Gabe. Since my last post one of my colleagues has done some more research and investigation on a S2016 machine and concluded that WHQL signing was definitely necessary for our non-PNP drivers but it’s good to hear from somebody who’s actually done this; we’re still waiting for our HCK/HLK testing environment to be built.

But not necessarily a WHQL signature resulting from running the HLK tests, right? An attestation signed driver should work… have you had a chance to test that? You might as well while you’re waiting.

Peter
OSR
@OSRDrivers

My colleague was trying an attestation signed driver on a Server 2016 machine with Device Guard’s option ‘2 Required:WHQL’ enabled (https://technet.microsoft.com/en-us/itpro/windows/keep-secure/deploy-code-integrity-policies-policy-rules-and-file-rules).

When he ran Device Guard’s audit mode (which just logs rather than actually blocking) he had log messages coming through saying that the driver failed the WHQL signature check.

Hello everyone,

My team is in the process of testing our wfp callout (non-pnp, kmdf) in Windows Server 2016 and as you can imagine the question regarding signing requirements brought me here.

We’ve done some tests with our callout in server installed with secure boot and without secure boot and as long as we use sysdev attestation signature (which you get simply by uploading cab in sysdev. no HCK/HLK tests required) everything is working like a charm. Even when Device Guard is enabled. We also tried it with some legacy WDM driver and it also works well.

So, my obvious question is: how come it works for us and it does not work for some of the people from this thread?

Volodymyr - the driver we tested is also a non-PNP KMDF WFP driver. The only possible difference I can think of between our tests and yours is that we had Device Guard explicitly configured to enforce WHQL signing. Did you do the same?

Well sure if you set the server to explicitly require whql signed drivers
then one would expect that to be enforced.

MSFT made noises around the release of server 2016 that it was pushing the
switch that made WHQL signed mandatory. Or not. Or maybe only on all new
installs. Or not. Or maybe only new installs with secure boot enabled. Or
not. See the response by PeterGV upthread.

Mark Roddy

On Mon, Nov 21, 2016 at 7:50 AM, wrote:

> Volodymyr - the driver we tested is also a non-PNP KMDF WFP driver. The
> only possible difference I can think of between our tests and yours is that
> we had Device Guard explicitly configured to enforce WHQL signing. Did you
> do the same?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:></http:>