Production signing driver in Visual Studio 2019

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

>> 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.
You believe MS did all that work for pleasure?
I would see why Apple surpassed it by value then :wink:

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.
Never was the case, still isn’t. There is a list of trusted EV
providers (the ones for which a cross-cert exists). Others will not
work.
Funny enough, Symantec/Digicert were the only ones that worked at
start, then I believe GlobalSign was added, and gradually others.
But I can tell you from several experiences, that either the cert
bodies do not follow the guidelines, or the guidelines for EV
certification are c***.

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.
And Attestation helps… how exactly?

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.
What was involved for you in getting the EV cert?
One of my companies got the certificate simply by being listed on
Google Business. That was it… that was ALL the verification that they
did.

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.
Submitting the driver, having to wait 20 minutes, downloading it and
then packaging it is not a PITA?
It took me <2 minutes to compile 18+1 different variations of my own
drivers (for different customers, architectures, windows versions,
etc…), with signing and packaging. It was all automated, and the
resulting package was ready for deployment.

Now, I have to do half the above process, then submit for attestation,
wait 20 minutes, do it 3 more times, because I always forget something
:D, and then have a file ready for deployment.

I agree the above would be a matter of opinion, whether it is a
nuisance - but so is the process of getting the EV cert. Once we get
the first token, renewals are automatic - just PAY. Nothing else!

In my opinion, the biggest drags to Attenstation signing are:

  • Cost that we see no added value to, but is an obvious way to remove
    support for older Windows versions.
  • It takes 20-30 minutes per driver package (10 to submit, unless you
    automated it via JSON API), even though the process can’t do anything
    more than verify I signed the .cab file, verify the INF, and sign the
    driver/cat. That is an <2second work on my old laptop. It should be an
    <2millisecond work on average on Azure cloud.
    What do I do when I need to submit 19 builds? Do a LOT of waiting :slight_smile: