Signing Driver for Win7 ?

David_F.

Hi,

I had to make a minor update to a driver that works from Vista or later - hasn't been an update for a couple years. My normal process is to submit the Win10+ driver to MS for signing and using the crossed-signed-certificate for the older Windows OS versions. However, today I tried the process with my new EV certificate received July 2022 (prior one expired) and the cross-signing no longer would work.

I went to look for an updated cross-signing certificate but found they stopped issuing one. Ugh, so now the question is, how do I sign for the older OSes ? Right now I only care about Win7, my other drivers that work from NT4 onward were already running in to nobody issuing SHA1 certificates for those OSes that required signing but didn't support SHA256 (I could create a self-signed one and provide root certificate but didn't help for drivers which needed to be cross-signed). When I use MS system for signing, there is no Win7 option, it's all Win10+ from what I recall (unless I don't understand what all the weird versions list there are?).

The bottom line question is, how do I sign drivers for Win7?

Thanks!!

Tim_Roberts

It's not clear to me that it is possible at all. I will be curious to see the responses you get.

David_F.

Well Win7 UI sees it as signed and valid so maybe it will just work? But then, why do we have to tick all those boxes when signing? - I think I know, the CAT file .. so why can't they offer a Win7 / Vista option which may support SHA-2?

Xiaofan_Chen

This is an interesting topic to libusb-win32 project as well.

For libusb-1.2.7.3 release we got the MS signed driver first and then sign for Windows 7. It seems to work fine. But that was in last November.
https://github.com/mcuee/libusb-win32/releases/tag/snapshot_1.2.7.3

David_F.

Here's information digicert provides: https://knowledge.digicert.com/alerts/Kernel-Mode.html

Xiaofan_Chen

So looks we were lucky last year. Now it will not work.

`
C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64> .\signtool.exe verify /v /kp C:\temp\libusb-win32-bin-1.2.7.3\bin\amd64\libusb0.sys

Verifying: C:\temp\libusb-win32-bin-1.2.7.3\bin\amd64\libusb0.sys

Signature Index: 0 (Primary Signature)
Hash of file (sha256): 2148A71E5EF84643B11A1A528E421B3860D2D07831FB7BCECA9D0E5DE7B4AC43

Signing Certificate Chain:
Issued to: Microsoft Root Certificate Authority 2010
Issued by: Microsoft Root Certificate Authority 2010
Expires: Sun Jun 24 06:04:01 2035
SHA1 hash: 3B1EFD3A66EA28B16697394703A72CA340A05BD5

    Issued to: Microsoft Windows Third Party Component CA 2014
    Issued by: Microsoft Root Certificate Authority 2010
    Expires:   Tue Oct 16 04:41:27 2029
    SHA1 hash: 1906DCF62629B563252C826FDD874EFCEB6856C6

        Issued to: Microsoft Windows Hardware Compatibility Publisher
        Issued by: Microsoft Windows Third Party Component CA 2014
        Expires:   Fri Dec 03 06:25:28 2021
        SHA1 hash: 984E03B613E8C2AE9C692F0DB2C031BF3EE3A0FA

The signature is timestamped: Sat Nov 13 19:54:14 2021
Timestamp Verified by:
Issued to: Microsoft Root Certificate Authority 2010
Issued by: Microsoft Root Certificate Authority 2010
Expires: Sun Jun 24 06:04:01 2035
SHA1 hash: 3B1EFD3A66EA28B16697394703A72CA340A05BD5

    Issued to: Microsoft Time-Stamp PCA 2010
    Issued by: Microsoft Root Certificate Authority 2010
    Expires:   Wed Jul 02 05:46:55 2025
    SHA1 hash: 2AA752FE64C49ABE82913C463529CF10FF2F04EE

        Issued to: Microsoft Time-Stamp Service
        Issued by: Microsoft Time-Stamp PCA 2010
        Expires:   Thu Jan 13 01:28:25 2022
        SHA1 hash: A04C15E8F4C630938C2935B1375329AF93CC90D4

Cross Certificate Chain:
Issued to: Microsoft Root Certificate Authority 2010
Issued by: Microsoft Root Certificate Authority 2010
Expires: Sun Jun 24 06:04:01 2035
SHA1 hash: 3B1EFD3A66EA28B16697394703A72CA340A05BD5

    Issued to: Microsoft Windows Third Party Component CA 2014
    Issued by: Microsoft Root Certificate Authority 2010
    Expires:   Tue Oct 16 04:41:27 2029
    SHA1 hash: 1906DCF62629B563252C826FDD874EFCEB6856C6

        Issued to: Microsoft Windows Hardware Compatibility Publisher
        Issued by: Microsoft Windows Third Party Component CA 2014
        Expires:   Fri Dec 03 06:25:28 2021
        SHA1 hash: 984E03B613E8C2AE9C692F0DB2C031BF3EE3A0FA

Successfully verified: C:\temp\libusb-win32-bin-1.2.7.3\bin\amd64\libusb0.sys

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
`

David_F.

Looks like this would work for all the older OSes:

"Drivers can still be signed with a 3rd party issued code signing certificate. However, the certificate that signed the driver must be imported into the Local Computer Trusted Publishers certificate store on the target computer. See Trusted Publishers Certificate Store for more information."

The catch22 is, had I written a utility to do that and signed it in the past with both certificates (SHA1/SHA2) it would work, but a new utility couldn't be signed with something the an old OS supports.

Xiaofan_Chen

"Drivers can still be signed with a 3rd party issued code signing certificate. However, the certificate that signed the driver must be imported into the Local Computer Trusted Publishers certificate store on the target computer. See Trusted Publishers Certificate Store for more information."

That is what libwdi is doing. It works from Windows 7 to Windows 11. But some Windows insider build breaks this.
https://github.com/pbatard/libwdi/wiki/FAQ#what-are-these-usbvid_pid_mi_-autogenerated-certificates-that-libwdi-installs-in-the-trusted-certificate-stores

But the pre-requisite is that the .sys driver has already been signed. So it is again a catch-22 situation.

David_F.

Unfortunately it's not working on my test of a Win7 x64 (6.1 build 7601: SP 1) - ensured it was in localmachine store, even put the "DigiCert Trusted Root G4" (which is top of my EV certificate) in the Trusted Root Certification Authority store, no change.

net start drivername
"Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damage
d, or that might be malicious software from an unknown source."

David_F.

Turns out you have to enable testing mode in Win7 to use driver that is not crossed signed. So scratch that. What about the VHLK, can that be used to create whatever is needed to get Win7/Vista driver signed? I read somewhere that the HCK/HLK method would end Jan 2023, so I don't want to waste my time with all the complicated stuff when all I want to do is sign something. Would me setting up another system with the date set way back to sign things without a timestamp work or is a signed timestamp needed? Or better, can someone convince MS to add the tick boxes for the catalog to support vista/win7 (and server equivalents) - It's the same driver that works in Win10. Also be nice to allow SHA1 for older OS (signed MS SHA1) - since all the new Windows versions ignore SHA1 anyway, generating one for old OS that needs them isn't a security issue. That would solve everything!

David_F.

The timestamp is needed or says expired. Win7 is still widely used. I forgot about Win8.x but signing would cover those as well. Between Win 8/7 it is 15 to 20% of the install base.

vlpast

Hi David,

Have you solved this puzzle?
I'm in a similar situation now - need to update our old WFP callout driver. And we still have a pretty large customer base who use pre-8.1 systems.
Using DefaultInstall INF installation, not P&P, no hardware device.

Ensured that our Win7/8 test systems have SHA-2 updates installed, nonetheless EV-attestation signed drivers can't load - same "net start" error as above. Also there's a record in the Windows Security log, generated by System process: "Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error." As if the kernel does not see sha256 hashes.

Has the HCK method worked for you?