Using HLK - Do you sign driver being tested?

Hello,

Two questions for getting Win Vista/7/8/8.1/2008/2008r2/2012/2012r2 signed:

1 - Do we sign the driver being tested with our own certificate? One EV and SHA1 self-signed with our own CA ? Or just leave it unsigned?

2 - When submitted for signature by MS, does it get signed with both SHA2 and SHA1 signatures so that it works even if SHA2 support hasn’t been applied via a windows update?

I’m not of the view I should care what OS and updates my customers are running, just that our software simply works.

  1. You do not need to sign your driver, although many people do. You just need to sign the cabinet that you upload.
  2. Microsoft adds an SHA2 signature. Do you really need to support the original Win 7 release? Once you get to Win 7 SP1, SHA2 is supported. Even if you add your SHA1, you’ll still have to get the user to add your certificate authority.

Thanks, a couple more things…

1 - does MS then remove (replace) the signature provided once it’s submitted?

2 - Well, you can’t really get the updates (at least via normal windows update) to get SHA2 so someone might be stuck at SHA1. You said we can add our SHA1 CA to the Trusted Root Authority but testing Win7 x64 with SHA2 (new for mid 2022 - has SHA3) that is not cross-signed doesn’t work - you have to enable testing mode. Maybe the old OS that only supports SHA1 would work even if not crossed-signed?

It just seems so simple and logical that MS should change the signing portal to add an option for a SHA1 signature and ability to target of the old OSes (SHA1 or SHA2) for the .cat file. It’s established, not going to change, not a security issue since all the new OSes ignore SHA1 and all would be coming from Microsoft CA so they work in the old OSes out of the box.

does NS then remove (replace) the signature …

In the case of the CAT file, which is the important one for P&P drivers, they throw out your CAT file and create a new one from scratch. In the case of the binaries within the cabinet, there is conflicting information. I believe they just append their signature to yours.

Well, you can’t really get the updates …

If you have Windows 7 original, then upgrading to Windows 7 SP1 should do this.

It just seems so simple and logical that MS should change the signing portal to add an option for a SHA1 signature…

No, it’s not logical, because it doesn’t make financial sense. Windows 7 was released in 2009, and became an orphan in 2020. Microsoft would far prefer that Win 7 customers who are inconvenienced just upgrade to Win 10. They have absolutely no incentive to improve the experience for users of antiques.

Well, they don’t need to improve the experience or even provide technical support, just not put in road blocks to prevent someone from being able to keep using it or stopping software from running on it. I would imagine the reason given will be due to the CA being expired and back dating would be best, but there may be another route… Thanks, I think I’ll try this HLK thing at some point for at least SHA2 support in older OS, but for now can just release the old drivers for the old OS since nothing really changed in the code, was more of an .inf fix (which the .cat file didn’t like unless signing again). Thanks for the info…

Just FYI to confirm that it’s my understanding too that the SHA-2 support is – and remains – a separate post-SP1 update, “KB3033929 Windows 7 SP1 SHA-2 Support”. While we’re talking about it, I’ll also give a shout-out to “KB2921916 Windows 7 Publisher Verification Prompt SHA-256”, if you find your “always trust software from xxxxxx” selection isn’t working after applying SHA-2 support.

I don’t know definitive answers to the “what does Microsoft do for SHA-1”, but the answer USED to be that Microsoft still provided an SHA-1 signature when you’re testing and submitting for an SHA-1 dependent platform like Windows Server 2008. (Which will be an HCK testing process, not HLK.) You didn’t get it “regardless of platform”, but did get the signature required for the platform you were tested and signing for.

I say “used to be the answer” since SHA-1 has been deprecated since then, and I don’t know what Microsoft might do or no longer do. Nor do I perform HCK testing of any drivers myself to have encountered what this answer might be. If HCK testing and signing for these down-level platforms is still allowed, it would seem like Microsoft “has to be” still providing an SHA-1 signature. But who knows.

Regarding what will happen to the existing signature on individual binary files, at least in the Attested Signing process it would append Microsoft’s signature to whatever signature was already on the binary. We directly relied on this behavior with our product, and knew it was true.

But, that “existing signature in the binary” was also a Microsoft cross-signing signature, and Microsoft cross-signing has also been deprecated at this point. So it’s not possible to submit a binary with a pre-existing kernel-policy signature any more, since you can’t cross-sign your binary. What Microsoft’s process might do with an unverifiable self-signed certificate signature, or other private CA certificate signature, or what they might do with any non-kernel-policy signature (non-cross signed, normal Authenticode signature) on the binary file is unknown to me.

That’s maybe the final thing to point out: If you’re getting a Microsoft SHA-2 signature on your signed binary files, you want to NOT SIGN those binary files before submission to Microsoft if you want to have any chance of those files being used on an SHA2-compatible down-level platform. The down-level platforms do not successfully traverse “what is the SECOND signature on the binary file”, and will be stuck looking only at whatever your non-Microsoft first signature was.

1 Like