Driver Signing Practical Info

But… hasn’t that been the requirement forever? Not ANY class 3 Code Signing Cert, but a particular Symantec one? That’s why there was the special $100 offer for that cert that folks (including OSR) used for years.

And, yes… I agree it IS more confusing than it should be. And, it goes without saying that the cost of the EV Certificates is ridiculous to the point that it is scandalous.

Peter
OSR
@OSRDrivers

Discussed? Was it decided and delivered? I know it was requested but I have not yet found it.

Cheers
Dave Cattley

Sent from my Windows Phone


From: xxxxx@osr.commailto:xxxxx
Sent: ‎7/‎15/‎2015 10:08 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Driver Signing Practical Info

Yes… An API for this was indeed discussed.

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</mailto:xxxxx></mailto:xxxxx>

xxxxx@osr.com wrote:

But… hasn’t that been the requirement forever? Not ANY class 3 Code Signing Cert, but a particular Symantec one? That’s why there was the special $100 offer for that cert that folks (including OSR) used for years.

This is actually one of the primary reasons I asked my recent question.

Yes, creating a winqual account has always required a Symantec
certificate, although not necessarily a Symantec code-signing
certificate. Thus, you could either get a “Symantec plain” plus an
“affordable Class 3”, or you could get a gold-plated “Symantec Class 3”.

Since I don’t actually distribute any of the drivers I write, and the
winqual account has to belong to the submitting company, I’ve never had
a winqual account, so I’ve never had the Symantec certificate. Hence,
my question. In order to reproduce my client’s environment, am I now
going to be REQUIRED to get a genuine Symantec certificate in order to
create the account through which I make these submissions?


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

On 07/16/2015 01:45 AM, xxxxx@resplendence.com wrote:

However to be able to even sign up for a sysdev account, as a
requirement you need to sign a winqual.exe file with a Symantec Class
3 certificate ($795/year). If signed using a standard KMCS procedures,
the application is rejected .

The least-expensive EV code signing certificate I could find is via this
link: https://www.digicert.com/friends/sysdev/

If I could use that same certificate to sign winqual.exe, that would be
a great help. The drivers I sign under my own name tend to be pro bono
efforts (e.g. to keep old hardware working on newer versions of
Windows). It’s painful to be periodically shaken down for hundreds of
dollars for the privilege of releasing work I’m giving away for free.

Over the last decade, the requirements have become decidedly unfriendly
to lone developers taking up this craft. GlobalSign used to offer
special pricing to individuals, but they declined my most recent renewal
and told me that code signing certificates are now available only to
corporations.

Mark Fontana

When driver signing was originally implemented for x64, I spent a great deal of time arguing with the MSFT architects that it would screw hobby/community developers. I cited several examples of why this was not good for Windows. I couldn’t get one person to express any interest, or to seriously attempt to address this issue.

It will be VERY hard and almost prohibitively expensive for these devs to acquire EV cents (I read the guidelines, and I think it’s technically possible, but the dev will have to have an actual business with an address).

I think it’s a real shame, and bad for Windows, to force hobby and community devs out of the marketplace.

Perhaps somebody will form a .org to sign these kinds of projects. But that’d be a tricky business in today’s world.

Peter
OSR
@OSRDrivers

I don’t understand. If you want to release sign drivers for testing, which I think it a bad idea but whatever, you’re going to need an EV Cert. OR you’re going to have to get your client to get an EV Cert and give you access to their sysdev account (this is actually very practical… The primary sysdev account holder can create other accounts for the same company and control a fairly fine grained set of permissions associated with each account) and THEIR EV Cert. This second option is what we do now when we have clients that want the Logo and want to pay us to run the Logo tests and submit for them. It works out quite well.

Peter
OSR
@OSRDrivers

xxxxx@osr.com wrote:

I don’t understand. If you want to release sign drivers for testing, which I think it a bad idea but whatever,…

I’m curious to know why you think it is a bad idea. I’m bothered by the
idea of requiring my clients – some of whom are not as technically
sophisticated as they need to be – to run their machines in
/testsigning mode.

you’re going to need an EV Cert. OR you’re going to have to get your client to get an EV Cert and give you access to their sysdev account (this is actually very practical… The primary sysdev account holder can create other accounts for the same company and control a fairly fine grained set of permissions associated with each account) and THEIR EV Cert. This second option is what we do now when we have clients that want the Logo and want to pay us to run the Logo tests and submit for them. It works out quite well.

That’s certainly what I have done for logo submissions in the past. I
did finally go out to the WHDC web site, and it looks like you can now
use a certificate from either Symantec ($800) or Digicert ($225) to open
a sysdev account, so there does appear to be another option now.


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

xxxxx@resplendence.com wrote:

However to be able to even sign up for a sysdev account, as a requirement
you need to sign a winqual.exe file with a Symantec Class 3 certificate
($795/year).

The WHDC web site now says you can use a Digicert certificate as well,
which is $225/year. That’s good news, relatively speaking.
https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887.aspx


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

No deep thinking involved, really. I’m just concerned about pre-releases (my beta releases to clients or whatever) somehow getting out into the wild. If they’re not “release signed” accidentally releasing them won’t matter.

Peter
OSR
@OSRDrivers

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

  1. The portal accepts submissions using a Symantec certificate (I haven’t tried digicert, but they claim it’s supported as well)
  2. The signing takes anywhere between 5 - 30 min. But it can apparently take several hours based on server load
  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(v=vs.85).aspx?f=255&MSPPError=-2147217396
  4. The driver (.sys) needs to have a .inf along with it. The portal will not accept .sys files without an accompanying .inf (e.g. some non-PnP drivers)

Open questions:

  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?
  2. An API is supposed to exist - https://msdn.microsoft.com/en-us/library/windows/hardware/dn800659.aspx?f=255&MSPPError=-2147217396, but the URL it’s using, https://api.sysdev.microsoft.com is not available
  3. 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).

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.