Driver Signing Practical Info

Thanks Peter. I’ve been actively following this discussion as I have many of the same questions raised here.

I’ve got my shiny new EV cert in house and am changing my build processes to appropriately sign with the EV cert only for release builds. However, I have yet to go through the sysdev submission process.

If you could get some clarity on the API (does it exist?, how do we use it?, etc.) that’d be highly valuable for me. I do continuous integration nightbuilds and need to utilize that same system for my release builds; which means I need to account for the extra submission steps.

On a slightly related note it’s been difficult working through the details of how to get our new cert installed as part of the installation process. It could be very useful for people to get the end-to-end descriptive summary of what it takes to get a new cert, integrate it into your workflow, use it with sysdev, and get your end product ready for distribution.

xxxxx@osr.com wrote:

OK folks… There are obviously a lot of gaps in our knowledge about how this is going to work.

I’m trying to gather some detailed and definitive technical answers… I’ll write-up whatever I learn and publish it either (a) in our blog, or (b) in The NT Insider … probably both.

In the meantime, if you have specific questions, feel free to post them here.

I’ve started trying to explain this to my clients, and that has pointed
out several additional gaps in my understanding. It would be nice to
have a Lync/Skype Q&A session with someone who knows the One Truth.

I am assuming that the new web-service signing requirement only applies
to driver PACKAGES, and hence only applies to the PnP install-time
signature check. Specifically, I assume that the KMCS requirements are
unchanged. Still 64-bit only, still Class 3 Code-Signing Cert with
cross certificate, still SHA1. True?

Assuming that is true, where does the EV Cert come in to play? In the
past, when WHQL signed a CAT file, it replaced whatever vendor
certificate was there. Does the CAT file we submit have to be signed by
our EV Cert? Will it still be replaced? Or is the EV Cert only used to
establish the winqual account itself?

If I want to have both SHA1 and SHA256, will I have to add an SHA1 cert
onto the CAT file after I get it back? Or does that happen before?


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

> I am assuming that the new web-service signing requirement only applies

to driver PACKAGES, and hence only applies to the PnP install-time
Specifically, I assume that the KMCS requirements are
unchanged. Still 64-bit only, still Class 3 Code-Signing Cert with
cross certificate, still SHA1. True?

Any platform that does UEFI secure boot requires a KMCS signature on drivers - even 32-bit platforms. This has been true of Win8+. Basically one should be KMCS drivers for any (all) architectures. period.

A cute little Acer tablet that was SWAG at //Build a few years ago taught me that lesson. It is an anemic little x86 system and it flat out refused to load my driver until it was KMCS signed. I now cherish the toy as the only x86 UEFI secure boot platform I have to test that scenario with.

As for the other points I am among the increasingly befuddled.

Cheers,
Dave Cattley

It’s my understanding you can no longer purchase a SHA1 signing certificate, and all existing ones will expire by 1/1/2016, so after that date the issue of how to do SHA1 signatures (or dual SHA1/SHA2) will be moot. Drivers already signed with a SHA1 signature will continue to work until some future point that Microsoft decides SHA1 is too vulnerable and releases a patch disabling SHA1.

This does mean older OS versions that didn’t support SHA2 KMCS will not support new/updated drivers unless they are patched with the correct SHA2 support. If you already have a SHA1 cert, I assume you have until the end of the year to update/sign any drivers for these unpatched systems.

Jan

On 7/22/15, 3:48 PM, “xxxxx@lists.osr.com on behalf of Tim Roberts” wrote:

>I am assuming that the new web-service signing requirement only applies
>to driver PACKAGES, and hence only applies to the PnP install-time
>signature check. Specifically, I assume that the KMCS requirements are
>unchanged. Still 64-bit only, still Class 3 Code-Signing Cert with
>cross certificate, still SHA1. True?
>
>Assuming that is true, where does the EV Cert come in to play? In the
>past, when WHQL signed a CAT file, it replaced whatever vendor
>certificate was there. Does the CAT file we submit have to be signed by
>our EV Cert? Will it still be replaced? Or is the EV Cert only used to
>establish the winqual account itself?
>
>If I want to have both SHA1 and SHA256, will I have to add an SHA1 cert
>onto the CAT file after I get it back? Or does that happen before?
>

According to what I’ve been told just yesterday, that would be an incorrect assumption.

Hang on for a bit longer… I should have a Q&A up with answers to most of your questions within the next day.

Peter
OSR
@OSRDrivers

> It?s my understanding you can no longer purchase a SHA1 signing certificate

It looks like this was going to be the case but Microsoft changed the policy so that developers could still support the legacy operating systems:

http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx

“CAs must stop issuing new SHA1 SSL end-entity certificates by 1 January 2016. Update: For code signing certificates, CAs may continue issuing new SHA1 code signing certificates to ensure that developers targeting Windows Vista and Windows Server 2008 are properly supported.”

> In the meantime, if you have specific questions, feel free to post them here.

Peter, thanks for doing this. Questions, in no particular order and as they come to mind:

  1. How do we handle non-PnP drivers with no INF? We’ve been mocking up a dummy INF to get a signature on such a binary, but that seems a bit hacky.

  2. Will KMCS be enforced on 32-bit Windows 10 in general?

  3. The REST API for driver signing doesn’t seem to be operational. We’ve been trying to use the sample code without success. (“401 unauthorized”) When will it start working, or could it be that we are doing authorization incorrectly?

  4. How do we accomplish prerelease signing? Will putting Windows 10 in test signing mode obviate the need for the Microsoft signature on a kernel driver, or will we need a driver with a Microsoft test signature? If the latter, how do we accomplish that with the REST API? The API lists a “Production” type (https://msdn.microsoft.com/en-us/library/windows/hardware/dn800659.aspx). I assume there is an equivalent “Preproduction” type, but it is not documented.

  5. How do we initiate a failure due to lack of an appropriate Microsoft signature? Do we have to wait until after July 29? When it is allowing exceptions for drivers signed prior to July 29, exactly what timestamp is Windows looking at?

  6. We are very concerned about the impact of this on our build times and thus our continuous integration. If we only need to have Microsoft sign our finals that’s at least only a one-time thing, but (going back to question #4) if we have to do preproduction signing through MS servers that will very much impinge on our current workflow. If prerelease signing is required for test signing mode, will it at least be much quicker than the potential hours that I’ve seen listed for release signing?

You had questions… we went to the Microsoft authorities get answers. Thank you, everyone, for your patience while we went out to gather the facts.

Here’s what we know: http:

Hope you find this helpful… I wrote this instead of the driver I’m supposed to be working on. Now I’m behind schedule. Again… :wink:

Peter
OSR
@OSRDrivers</http:>

Awesome, thanks.

//Daniel

Peter,

Thanks for the effort of putting this all together.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, July 24, 2015 3:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver Signing Practical Info

You had questions… we went to the Microsoft authorities get answers.
Thank you, everyone, for your patience while we went out to gather the
facts.

Here’s what we know: http:

Hope you find this helpful… I wrote this instead of the driver I’m
supposed to be working on. Now I’m behind schedule. Again… :wink:

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer</http:>

Thanks for getting us the answers, Peter. These issues are potentially very impactful to our organization. Still trying to digest it all…

Thanks for all your work, Peter. This is very useful information.

My pleasure folks.

You know you can count on OSR to get you the info you need.

Peter
OSR
@OSRDrivers

Hell yes

mm
On Jul 24, 2015 6:27 PM, wrote:

> My pleasure folks.
>
> You know you can count on OSR to get you the info you need.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Many thanks Peter for getting those answers, though it’s disappointing to
see that Microsoft have reneged on the original statement in their April 1
blog that the attestation portal would allow drivers to be signed for
earlier versions in addition to 10. Looks like we’re going to need a
separate driver package for 10 and everything else, which is further
complicated by Vista / Server 2008 not recognising EV certificates.

Of greater concern is the logo certification requirement for Server vNext.
Our products no longer fall within what Microsoft considers to be a “proper”
audio device, as they don’t have 3.5mm jacks with jack sensing and aren’t,
in fact can’t be, based on the HD Audio architecture. Looks like anything
that isn’t a generic consumer-grade sound card will be excluded.

We live in interesting times.

Jeff

Hey Jeff,

Yes, I thought the info about server requiring passing the WHQL tests was the biggest news in that interview, actually.

You sure you have to logo as a Windows audio device? Given your products aren’t “normal” consumer audio stuff, can you fit in another category? I bet you can work this issue… No way they intend to make it impossible for professional audio to be connected to Windows. That’s just my feeling… I don’t have any special knowledge in this regard…

Peter
OSR
@OSRDrivers

Thanks Peter. I’ve just emailed sysdev at Microsoft with that very question,
and will pass on their response.

Jeff

Having worked on a a number of bleeding edge server technologies over the years, which initially didn’t have any matching WHQL category to get certified under (Infinband RDMA and FCOE come to mind), not being able to even load a driver unless it passes WHQL certification seems like a way to assure Windows will get left behind by vendors of interesting new technology.

Jan

On 7/26/15, 6:39 PM, “xxxxx@lists.osr.com on behalf of xxxxx@osr.com” wrote:

>Yes, I thought the info about server requiring passing the WHQL tests was the biggest news in that interview, actually.
>

Please DO pass on what they say.

Plus, do your own investigation. Read the WHQL requirement carefully and interpret them truthfully, but in the best possible way for your product. Remember: YOU run the tests and send-in the results. I’m not saying to lie. But it’s like the tax laws. There’s absolutely nothing wrong with working the rules to the best of your advantage.

One thing people at smaller vendors typically fail to take into account is that what gets signed is ultimately a matter for negotiation. I’ll tell you a story: There is a very large vendor (who shall remain nameless) who had a driver that violated an extremely fundamental policy rule for its category of device. They knew it and Microsoft new it, and the violation was absolutely intentional by design (I know all this to be fact, it’s not speculation). Microsoft WHQL’ed that driver for YEARS… like ten years… as a result of negotiation. The result was not bad for the community in any way, not bad for interoperability, not bad for Windows, not bad for the vendor, not bad for for Microsoft. So it was a win-win for everyone involved. But OTHER people? THEY had to follow the rules. Unless they made their OWN deal.

The WHQL process has a built-in waiver system for precisely this reason. Smaller vendors need to work this system. It’s a PITA, and can require a lot of person-to-person dickering… but there’s always a path forward.

I’m not in favor of what they’re doing for server, not in any way. But don’t forget that there’s always “unclassified”… which is a pretty reasonable set of tests (if any of these tests can be termed “reasonable”).

What scares me is that the WHQL tests (arrrgh… we’re supposed to say the “Windows Lab Kit” Compatibility Tests now, aren’t we…) are a mixture of basic correctness tests and policy-based tests. Some of the policy-based tests are more of a “we think this is best practice for device” type of thing, and preventing drivers loading based on their hardware’s lack of adherence to what one vendor considers “best practice” seems to be… well… awfully extreme.

For example, PCIe devices for server *must* support AER, though it is optional in the Express spec and several of the available FPGA cores don’t support it. Sure, supporting AER is good. But refusing to load drivers for devices that don’t support AER seems to me to be a really bad policy. How about all those devices that were built before AER was required?

Peter
OSR
@OSRDrivers

“there’s always unclassified”

It would be interesting to know if Microsoft would accept a device tested
under “unclassified” for a signature valid on server.

I mainly work on PCIExpress devices, targeted at the ISM market, for which
there are no appropriate device specific Microsoft tests: it’s far too
specialist.

Best regards

Chris Read