Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Production signing driver in Visual Studio 2019

h7rh7r Member Posts: 3

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 :-)

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,699

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • h7rh7r Member Posts: 3

    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!!!

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • h7rh7r Member Posts: 3

    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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,699

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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 Viscarola
    OSR
    @OSRDrivers

  • William_J._CaseyWilliam_J._Casey Member - All Emails Posts: 53

    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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    @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

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 210

    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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,699

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 210

    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

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 354
    via Email
    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.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 354
    via Email
    MS gets no cut from certifying which CA can issue EV certs for KMCS?

    Kind regards, Dejan.
  • MBond2MBond2 Member Posts: 210

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

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,699

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 354
    via Email
    >> 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 ;)

    > 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 :)
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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)

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 354
    via Email
    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?
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,166

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,699

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 354
    via Email
    I meant signing certs.
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 354
    via Email
    >
    > > 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.
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,699

    Easily spoofed snd intercepted.

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 354
    via Email
    Malware on millions on computers before it is detected?
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE