Production signing driver in Visual Studio 2019

@“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:

Cost: I just noticed that SSL.COM is offering EV Code Signing Certs for US$250/year… IIRC, that’s less than we paid for our (non-EV) Symantec Class 3 Code Signing cert.

Peter

(Conflict of interest statement: Neither I nor OSR have any relationship with or knowledge of SSL.COM, nor do we derive any revenue or consideration from SSL.COM)

I am not sure SSL.com will work, but there are 290$ones.

We paid less for our first EVs.

But, do tell what the verification was like for a US company?

SSL.COM will indeed work. I got it from the MSFT web site.

do tell what the verification was like for a US company

It required us to give Digicert an address and a phone number that they could look up and cross-check that it was listed as our business, they had to call that phone number and physically talk to the exact person we said they could reach at that number, and I believe that we had to give them something to verify our business (I think it was our D‑U‑N‑S Number).

And then they would only mail our token to the address that we gave them and that they had previously verified.

That felt sufficiently rigorous to me.

Peter

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.

Nope, you are wrong. The certificate requirements for doing cross-signing are entirely different from the certificate requirements for setting up your dashboard account. The dashboard account cert does not need to be a code-signing certificate at all. Until the EV thing, the cheapest Symantec certificate available worked just fine. Now, as a developer, it was more convenient to get one certificate that worked in both cases, but the dashboard will work with ANY legitimate EV cert. It doesn’t have to be on a trusted list.

I meant signing certs.

>

> do tell what the verification was like for a US company

It required us to give Digicert an address and a phone number that they
could look up and cross-check that it was listed as our business, they had
to call that phone number and physically talk to the exact person we said
they could reach at that number, and I believe that we had to give them
something to verify our business (I think it was our D‑U‑N‑S Number).

And then they would only mail our token to the address that we gave them
and that they had previously verified.

That felt sufficiently rigorous to me.

Easily spoofed snd intercepted.

Easily spoofed snd intercepted.

Easily? I don’t think so. Possible, but the cost/benefit ratio doesn’t make much sense.

Malware on millions on computers before it is detected?