Driver code signing

Currently we are in the process of moving our product to Windows 10 x64 OS. We have kernel-mode driver built in VS2015, it is test-signed and successfully runs on the target OS. We need to buy a new code signing certificate and sign this driver. Since this is first time we make such a procedure, I want to ask for details.

Microsoft article “Get a code signing certificate” https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate contains the list of certificate authorities. So, we want to buy a new EV coding certificate from Sectigo: https://sectigo.com/products/signing-certificates/code-signing

Having this certificate, I want to sign the driver as described in this article: “Signing a Driver for Public Release” https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/signing-a-driver-for-public-release

Is this correct and enough to install our driver on Win10 x64 computers?

According to the article “Driver Signing Policy” https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later- the driver should be signed by the Dev Portal. We hope to use our drivers without this additional steps, by setting Secure Boot to OFF in the BIOS. Is this correct?

If you do not intend to sign on the portal, you don’t need an EV certificate, just a regular SHA-256 certificate.

Even if you do support portal signing in the future, you only need to register the EV certificate on the portal and you can use a regular SHA-256 certificate to sign (as long as that certificate is also registered on the portal). This is convenient because it is hard to automate EV signing since you need to have a user logged in on the console to unlock the EV certificate (which is why Microsoft later dropped the requirement to sign with the EV certificate, at least according to my understanding).

And, yes, portal signing only matters if you want to support Secure Boot.

Eric

Alex_Farber wrote:

Currently we are in the process of moving our product to Windows 10 x64 OS. We have kernel-mode driver built in VS2015,…

According to the article “Driver Signing Policy” https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later- the driver should be signed by the Dev Portal. We hope to use our drivers without this additional steps, by setting Secure Boot to OFF in the BIOS. Is this correct?

IF you will only install your driver on computers that you control,
where you have the option of turning “Secure Boot” off, then you do not
need Microsoft’s involvement at all.  The old-style
sign-plus-cross-certificate method will work just fine. You don’t even
need an EV certificate.  You just need a class 3 code-signing
certificate from one of the authorities for which Microsoft has  a cross
certificate, and that list is longer than the EV list:

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cross-certificates-for-kernel-mode-code-signing

Note, however, that if you ever expect to release your driver outside of
your organization, this won’t work.  You CANNOT require your customers
to disable “Secure Boot”.  Many large corporate IT departments mandate
the use of “Secure Boot” in order to tick a checkbox on a PowerPoint
presentation.  So, if that is ever going to be a possibility, then you
might as well get an EV certificate, because you will need one to set up
your dashboard account.

The attestation signing process is not all that onerous, once you get
the account set up.

The attestation signing process is not all that onerous

What Mr. Roberts said. Once you’ve done it, getting your driver Attestation Signed is, quite literally, a less than 10 minute process from signature, through submission, and to the ultimate download of your signed driver.

Don’t be afraid!

Peter

Thank you for this information. This is what I understand now:

Driver attestation signing (dashboard signing) is not as painful as WHQL signing, and just requires some additional steps to minimal cross signing.

We are in the situation described by Tim Roberts as “only install your driver on computers that you control”. So, we need at least a regular SHA-256 certificate. But if we want to keep an option to make an attestation signing, it is better to use the EV certificate.

Additionally, as mentioned by Eric Berge, EV signing is hard to automate, because it requires to insert a dongle and unlock the EV certificate.

Is my summary correct?

On May 29, 2019, at 9:49 PM, Alex_Farber wrote:
>
> We are in the situation described by Tim Roberts as “only install your driver on computers that you control”. So, we need at least a regular SHA-256 certificate. But if we want to keep an option to make an attestation signing, it is better to use the EV certificate.

I think you have it.

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.