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
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.
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.
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.
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.
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.
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:
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:
Make a CAB file from your driver package, using a GUI utility
Upload it to MSFTâs site from their browser
Wait 20 minutes
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.
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.
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.
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.
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
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.
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.