Production signing driver in Visual Studio 2019

Hello all,

after some time I turned back to driver writing and got stuck with all this modern driver signing stuff.

I have an NDIS filter driver that follows the WDK example from a couple of years ago (Visual Studio 2013 at that time) that I moved to Visual Studio 2019, mainly because my OV code signing certificate from a couple of years ago finally expired. So I bought an USB token based EV code signing certificate from Sectigo (which turned out to still be issued by Comodo CA) besides another plain old OV certificate (which really is Sectigo issued).

I can nicely sign normal programs via signtool with both certificates, but I’m completely lost signing my filter driver in Visual Studio 2019 (no signtool build-step). Regardless which of the certificates I choose (the EV or the OV) I get the message “error : No matching cross certificate found for the given production signing certificate.”. For the OV certificate all the Sectigo intermediate certificates are installed and located in my certificate store (both current user and local system) while for the EV certificate “COMODO RSA Extended Validation Code Signing CA” is missing and I also didn’t find it on the web (asked Sectigo about that).

Some details: The project already in the VS2013 incarnation had configurations for W7, W8 and W8.1. After updating it to VS2019 I added a W10 configuration and changed the respective settings. All configurations compile and link. In the project settings under “Driver Signing” on the “General” tab the W7, W8 and W8.1 configurations don’t have a parameter “Cross-Signing Certificate”, while the W10 configuration has. What do I have to enter there?

Besides the fact that the production-signed driver afterwards has to be sent to MS (thanks for all the blog posts regarding Attestation Signing) how is driver signing inside Visual Studio 2019 meant to be working. Shouldn’t it even being possible to sign with a plain old OV certificate?

And something else puzzled me: In the project settings under “Driver Signing” on the “General” tab for the parameter “TimeStampServer” I can only choose from “Verisign”, “Globalsign” or “none”, nada “Sectigo” (resp. “Comodo”). Bought the wrong certificate?

Any hints very much appreciated!

PS: Please forgive my ignorance. Driver writing/signing isn’t my daily business at all and sometimes I feel the world is moving too fast :slight_smile:

For production signing, just sign your driver and your CAT file with your EV cert using signtool and submit it to MSFT for attestation signing, and you’ll be good to go for Win10.

Read about crosss-signing here.
You can any time stamp server… you can use the verisign one even if you another cert.

Peter

Just for the sake of completeness, you don’t actually have to sign your driver or your CAT file before submitting it for attestation signing. You just have to sign the cabinet. In fact, you don’t have to include a CAT file at all; Microsoft will just throw yours out and create a new one from scratch.

Hi Peter and Tim et al,

thank you so much for your help.

When studying the above link (and many other articles in the web), I was a bit disenchanted with my choice of certificate, because on the MS cross-certificate page neither Comodo nor Sectigo are listed. So I thought I need another certificate of one of the listed companies.

Anyhow yesterday I then completely disabled code signing the VS2019 way and did it by signtool as a post-build step (cat and sys). That worked like a charm (but also made the “package” project in the solution obsolete).

Then I stumbled upon a digicert article where kernel mode code signing with signtool and how to check for a valid certificate of a binary was explained. So I found out that in my driver the Microsoft root was missing and it didn’t fulfil the WIndows 10 x64 requirments. With another search on the web I found a Comodo page that offered a cross-certificate to download and with that and the /ac switch in signtool I could correctly sign.

Now the next step is creating a cabinet and submitting to MS. Gonna reread Peter’s blog article about attestation signing.

Thanks again!!!

Just to be clear: You don’t need to cross-sign for Win10… you need to attestation sign. In fact, as Mr. Roberts indicated for Win10 you don’t technically have to sign at all.

In terms of production signing with VS, we don’t use it either. We sign with signtool… much easier in the end.

Peter

Thanks again. Very much appreciated.

Well if I don’t sign at all for attestation signing:
What certificate will the driver(s) returned from Microsoft carry? Will these then be signed “Microsoft Corp.” or “Microsoft”?

If so, was buying a not so cheap EV code signing certificate then useless? because for signing programs it wouldn’t be necessary. suffices an OV certificate.

Will these then be signed “Microsoft Corp.” or “Microsoft”?

Who cares? As long as the certificate is recognized by Windows, that’s all you need. The certificate they use does not change based upon what you submit. Remember, they (1) throw away your CAT and create a new one, and (2) add their certificate to all the executable files in your package. That’s all they do. It’s a simple process.

Your certificate serves two uses. One, you can use it to sign and cross sign packages for older systems, and for Win 10 systems without “secure boot”. This is the path that is supposedly disappearing. Two, you can use it to establish your dashboard account, and to sign cabinet files that are submitted for WHQL signing and attestation signing.

was buying a not so cheap EV code signing certificate then useless

Dude… did you **read **my blog post(s) that you referenced or not?

You need an EV Cert to create a dashboard account. You need a dashboard account to get your driver Attestation Signed.

to quote my blog post:

Sooooo…

  • Get your company an EV Cert. I know it’s unreasonably expensive, but just grimace and pay the ridiculous price, it’s not your money and there’s no other alternative.
  • Using the EV Cert, sign-up for an account on the Microsoft Hardware Dev Center. This will require that you claim to have read and agree to a pile of documents, and that you sign a dummy file with your very expensive EV Cert and upload it.
  • Take your driver package and create a CAB file out of it.
  • Sign into the Microsoft Hardware Dev Center, indicate that you want to make an Attestation Signing submission, and then drag and drop your CAB file into the portal.
  • Wait a bit.
  • Download the signed package containing your signed executable.

Peter

Peter:
Been a LONG time since we corresponded but I’m afraid I’m with the ‘h7r’ respondent above. This is ENTIRELY too much BS to go thru after having gone thru all the BS to get a signed driver package in the first place! All because MS wants to control everything now. How about you guys create a service and we’ll pay you something? I’ll send my EV Cert file along with our driver package and you/OSR do it for us? Sound OK? You can blast me for being lazy but small companies like mine that are shipping hardware after having gone through the whole driver development saga don’t have the time or desire to jump back into the whole driver scenario. Like the line in the ‘Russia House’ movie: “Don’t know, don’t want to know”. Set a reasonable price and we’ll pay up :). Bill Casey

@“William_J._Casey”
Let me get this right. You want to pay somebody to:

  1. Make a CAB file from your driver package, using a GUI utility
  2. Upload it to MSFT’s site from their browser
  3. Wait 20 minutes
  4. Download the result and send it to you

Really? I don’t know what I could charge for that “service” and still sleep at night.

Oh… you DO need to create an account for your company on the dashboard using your EV cert… but you managed to create an account here, and it’s scarcely more difficult than that.

I don’t understand why people find this process (a) mystifying, (b) difficult, (c) objectionable. It’s really very simple, once you’ve done it just one time.

Peter

In my office there is a poster from the 1980’s entitled ‘Murphy’s computer law’. One of the tenants is that it is morally wrong to let naive end users keep their money. This discussion reminded me of that.

1 Like

The problem with having a service do your signing is liability. The WHOLE POINT of driver signing is legal liability. The company who issues you a certificate is asserting, legally, “I believe this company is who they say they are.” When you sign a driver package, you are saying “I wrote this, and I stand by the testing” (and that IS what you are saying – read the fine print when you make your account).

Thus, if your driver causes a blue screen in a hospital monitor that ends up injuring someone, the lawyers can hold you legally liable, with a traceable path that will stand up in court. They know you wrote it, because it was signed with your certificate.

No third party with any brains will be willing to take on that liability for another company.

1 Like

if your driver causes a blue screen in a hospital monitor that ends up injuring someone, the lawyers can hold you legally liable, with a traceable path that will stand up in court. They know you wrote it, because it was signed with your certificate.

I agree with all of this except with the “can hold you legally liable” part. They can, of course, attempt to hold you liable. Whether you are or not depends on the warranties and representations you make in licensing your software.

The point of signing isn’t liability, really… it’s accountability. Traceability. Knowing “for sure” who developed, distributed, or attested the driver.

No third party with any brains will be willing to take on that liability for another company.

Correct. But doing the submission on behalf of a company, with a dashboard account created by that company (and the necessary MSFT agreements signed by that company) is definitely possible. This is, I think, what Mr. Casey was proposing. Physically doing the submission doesn’t create any unique liability for the submitter.

Peter

there is another aspect to signing. perhaps the simplest but in my opinion the most important one - anti-tampering / corruption. CRC is good at checking for random corruption but not for calculated changes. A valid cryptographic signature is hard to forge as well as being good at detecting random corruption.

whether deliberate or as the result of bit rot, not loading binaries that contain bits other than the origionally compiled ones is a clear win.

There have been many additional requirements on top of this basic one since signing was introduced around 2003 IIRC, and mostly they can be viewed as tax i think. But Peter is right in respect to who actually clicks the button has littel legal bearing. many many organizations employ subcontractors and sub-subcontractors in every industry

You can verify the corrupt.bits with a free certificate as well, and with a
cheaper nonEV, too.

EV is a tax. It does ot even actually do any real verification.

EV is a tax. It does ot even actually do any real verification.

/rolls eyes…

The EV Cert Guidelines are public. If CAs are issuing EV Certs outside of those guidelines, then that’s a disadvantage and side effect of the Guidelines having no real legal standing, right?

The it is what it is. MSFT requires you have an EV cert to get a dashboard account, and so we get get an EV Cert. The money goes to the CA, not to MSFT. So, it’s not so much a “tax” as it is a “hoop” to jump through, or a road-block to most random people getting dashboard accounts and Attestation Signing drivers. It’s not a perfect system. But short of “everybody ask Peter at OSR who should be able to sign drivers” I’m not sure what better system we could use.

Peter

MS gets no cut from certifying which CA can issue EV certs for KMCS?

Kind regards, Dejan.

So a tax on the industry. Who collects it is irrelevant.

I’m not sure what better system we could use.

One very good example of a better system is the system we had before. I fully understand the need for signing, as we did it up through Windows 8.1, with certs and cross-signing. That provided value for consumers.

However, I do not have the slightest glimmer of understanding of what the industry gained by the change to attestation signing. It cost more, it’s confusing to describe, it slowed down the development and release process, and in exchange for what? Are there any studies that show that attestation signing has produced better drivers than cross-signing? What’s the gain? If there’s no gain, then it’s a bone-headed policy.

MS gets no cut from certifying which CA can issue EV certs for KMCS

There is no “certification” involved. I would be very surprised to discover that there was any cost associated with MSFT’s choice of CAs to trust. If there even is any such choice. I was under the impression that “any EV code signing cert” would work for creating a dashboard account.

What’s the gain?

I wasn’t in the room and (unlike when KMCS was first introduced) I haven’t had the privilege of talking with the engineers who are responsible for this new program and influencing their decisions. I don’t understand why this change was deemed desirable either… except that I know the cross-signing scheme had been thwarted multiple ways, and the availability of non-EV certs is very loose. So cross-signing wasn’t a very good way of ensuring “bad actors” didn’t create malware that end users could unknowingly load. I guess.

I know Mr. Maksimovic has repeatedly said that there’s no validation involved in getting an EV cert, but I have heard multiple stories — and our experiences getting EV Certs for OSR — that say otherwise. Getting an EV cert was a PITA. Keeping it on a hardware token is a GIANT PITA. And the funny thing is, you do not need the damn EV cert to sign your driver… you just need it to create your dashboard account to verify for MSFT who you are.

I don’t get the annoyance over attestation signing. At OSR, it just adds one small step to our release process and hasn’t proved even the tiniest bit inconvenient. Getting the EV Cert is a PITA, but that has more to do with Digicert’s gawd-awful interface (and acquisition of Symantec’s code signing business) than attestation.

I sure wish somebody could cogently explain to me the “sturm und drang” over attestation signing, because if they could I could better represent the community’s interests when I’m talking to MSFT.

Peter