Driver Signing Practical Info

You obviously need to change your release management into the at least the 1990s and let your clients know it is BETA. :slight_smile:

We have many Clients that want to come to our facility to test with a “NON DEBUG” version of our software before release in the wild. Our lab is setup like their live system and they run tests. Now they may want 10 different adjustments but want to test them 1 at a time, again NON DEBUG, turn around time is important to our SCM department.

Larry C

All these new signing practices may be useful en valuable , but it kills my current business. I’ve decided not to support Win10 (
although my driver software installs and works perfectly on Win10 Insider preview ) , and I am even thinking about stopping driver
development it all. I pay now yearly for a MSDN membership and a Sha1 certificate. Additionally payments for a Sha2 EV certificate
and a dashboard ( winqual ) account exceeds the yearly income of providing the software. I also worked out a method whereby each
user received a “branded” ( with name , e-mail address , etc ) *.sys file as a sort of license identification. Compilation ,
signing , packaging en sending takes only a few minutes. All this collapses due the time needed when to submit it to the dashboard.
All my customers receive currently updates for free. Now , I will send a note to all of them not to expect updates anymore ( unless
they keep using pre-Win10 versions ) and suggest them to send their complaints about this to Microsoft.

Christiaan

Mr. Clawson: Debug vs non-debug builds don’t have anything at all to do with driver signing.

So, I really don’t know what your talking about. Let them come to your office, and let them run an unsigned copy with the kernel debugger attached, or (as of today) a test signed copy with the signature loaded on the machine.

Release signing is for released code. You start release signing betas, then you have to release sign beta updates, the you have to release sign private builds… All because nobody at your customer can enable test signing or disable signature enforcement? That’s a lot of versions to be kicking around, waiting to escape into the wild accidentally.

Peter
OSR
@OSRDrivers

>1. (this is the biggest open question) The latest preview build of Windows

10 does not enforce this check. My >drivers, which are NOT signed by
Microsoft, still continue to load fine. When will we start seeing failures?
Only >after July 29 when Windows 10 releases?

This is my biggest concern as well. I have to update my software for Windows
10. I don’t know if I can still ship a fixed driver or if I should include
the old buggy driver in there for Windows 10 only ?

It’s pretty bizarre that the information is so contradictory and unclear,
is it too much effort to post a real date or some thing or is that on
purpose ? All this leads me to believe EV isn’t quite ready for it’s prime
time. But still, I don’t like to be playing with dice, it’s nice if we can
keep at least some level of control.

In any case, being a DBA, I’m not going to incorporate (with legal
implications) just to be able to buy a certificate. Just before the
announcement I bought a 5 year nonEV certificate of which I hope it got me
settled and I haven’t quite recovered from the pain of getting that (it
wasn’t the money that hurt).

//Daniel

Right. According to the announcements at WinHEC, as described in my blog post at: http:</http:>

“Drivers signed before Windows 10 RTM will be able to use the older signing mechanisms. But once Windows 10 ships, if you want your driver to run on Windows 10 desktop systems, you?ll need to (a) get an EV certificate, (b) using that signature submit your driver to sysdev to get Microsoft?s signature.”

That’s why we thought it was pretty important for people to start dealing with this back in March, months before Win10 RTM. Get your stuff updated, signed the old way before Win10 RTM, and you SHOULD be GTG for Win10 according to this announcement.

ALTERNATIVELY, get an EV Cert, work through the new procedures, and get your stuff signed at your leisure and you’re GTG. That’s what WE chose to do.

That’s all *I* know. I haven’t heard anything to the contrary in the intervening months, but then again, I haven’t done anything to specifically follow-up on this either.

Of course, this *does* beg the question as to how you ever update your drivers after Win10 RTM if you don’t get an EV Cert and have them signed by MSFT’s program. According to what’s been announced so far, the answer to that is “you don’t… After Win10 RTM you have to get an EV Cert and get your drivers signed by MSFT’s program.” Well see if that sticks. Like I said, I haven’t done anything to follow-up on this personally.

There is absolutely nothing in the guidelines that says you have to incorporate.

This isn’t that mysterious… just Google “Guidelines For The Issuance And Management Of Extended Validation Certificates” and read what the requirements are for an EV cert.

NOW… what a given Certification Authority may be willing to do CAN be more limited than these guidelines allow. But non-incorporated business entities are certainly allowable (consider all the general partnerships that would be ruled-out if this were not possible).

Peter
OSR
@OSRDrivers

vikram.parthasarathy@ni.com wrote:

I’ve been looking into Windows 10 kernel driver signing for a while now and this is what I’ve found so far:

3. The cab that you upload for signing needs to be in a specific format - https://msdn.microsoft.com/en-us/library/windows/hardware/dn962252.aspx

Uh-oh. That page says each driver package can only support one
architecture. I have always preferred to release one package with one
INF supporting multiple architectures, just because that reduces the
redundancy and hence the opportunity for errors. Does this mean such an
architecture is simply no longer possible?

  1. Will it be possible to sign .sys files on their own without an inf? I think the workaround until then would be to create a dummy inf (which hasn’t worked for me yet).

That’s an important question, and it leads to something that I’m not
clear about. As I have written previously, in a brilliant article
published in the NT Insider, there are two entirely different signature
checks in Windows. We have the PnP install-time check, which happens on
all systems, but only happens when the driver package is installed.
Then we have the KMCS check, which only applies to 64-bit systems, but
happens every time the driver is LOADED.

Reading on this page about CAB files and driver packages makes me start
to wonder if this change only applies to the PnP install-time signature
check, and NOT to KMCS. If that is the case, then that eases some of my
fears. That would mean that once I get a driver installed, I can do
updates to my heart’s content by copying the new files into place. It
would also mean that service-based drivers and device filter drivers
aren’t affected.


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

Tim Roberts wrote:

> vikram.parthasarathy@ni.com wrote:
> > I’ve been looking into Windows 10 kernel driver signing for a while now and this is what I’ve found so far:
> > …
> > 3. The cab that you upload for signing needs to be in a specific format - https://msdn.microsoft.com/en-us/library/windows/hardware/dn962252.aspx
>
> Uh-oh. That page says each driver package can only support one
> architecture. I have always preferred to release one package with one
> INF supporting multiple architectures, just because that reduces the
> redundancy and hence the opportunity for errors. Does this mean such an
> architecture is simply no longer possible?

That was a surprising and concerning limitation when we read it, too.

When both the .INF format and seemingly “the intention” of installing
software via .INF is to easily and transparently support multiple
architectures from a single .INF and installation set, the “single
architecture” statement seems very arbitrary and limiting.

But I can’t be sure what it truly means at a technical level, yet.
e.g. Does “single architecture” only refer to what platform the .INF
sections target, but still supports a mix of 32-bit and 64-bit binary
images being part of the driver set? Is it only concerned about
kernel-mode driver images, or all binary images including .DLLs?

For example, we have a “NetClient”-class software-only driver set that
includes a network redirector & the associated supporting network
provider DLL.

Never mind that we support installation on Windows 32-bit versus
Windows 64-bit using the same single .INF and the appropriate section
decorations. Even if we supported only Windows 64-bit in this .INF,
we would /still/ be including both 64-bit and 32-bit files in that
package, because you install the 32-bit network provider so that WNet
APIs on 32-bit processes can access your network redirector services,
etc.

Still waiting to see how this turns out. Noted that when you make a
new “Create driver signing submission” in SysDev, you are able to put
a checkbox beside both:

> Qualifications:
> Signed for Microsoft Windows 10 Client family, x86
> Signed for Microsoft Windows 10 Client family, x64

I’m stymied from completing the submission for now, due to unrelated
certificate complications still being worked out within the company.

But I’m interested to see what the system kicks back once I
successfully upload our existing multi-platform “NetClient”-class .INF
“as-is”, but having selected both “Signed for Microsoft Windows 10
Client family, x86” and “Signed for Microsoft Windows 10 Client
family, x64” during the submission.

Alan Adams
Novell Client CPR Group
xxxxx@novell.com

Novell, Inc.
www.novell.com

I’m also confused by this portal thing. In the 1st of April blog, they said you could select earlier operating systems (like Vista, 7, etc.) as well as 10, but the only platform options on the portal are Windows 10 32-bit and Windows 10 64-bit. Will the portal’s signature be recognised by earlier versions? I’d hate to think we have to have separate drivers for 10 and everything else.

I’m also scratching my head about the .cab requirement. Do we have to use makecab and create a ddf file to do this, or is there some automated way to cab a driver package?

Jeff

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’ll spend some time trying to engage with the right person at Microsoft, and bring the answers back to the community.

Peter
OSR
@OSRDrivers

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…