Dual signing drivers combined with WHQL signing in 2021?

Also i forgot to ask :

If the CA only supports SHA-2, will i still be able to load it in windows 7 versions that don’t support SHA-2, with the help of WHQL? meaning, does the WHQL provide an option to dual sign the driver itself?

This is quite a diverse topic, there may be different answers depending on what you are trying to achieve. If you send to WHQL for Windows 7, Microsoft uses SHA-1 certificate for signing CAT, and SHA-256 for signing the driver. So if you are using CAT, it will still load in non-updated Win7, no dual signing needed from either you, or Microsoft.

Dual-signing is normally used, when you don’t use WHQL, but sign the drivers yourself and distribute them as a single package, suitable for all OS versions. This mechanism still works, provided that you have the appropriate certificates and cross-certificates which have not expired. If you don’t have an SHA-1 certificate, this can be a problem. Technically, you can select the SHA-1 signature algorithm even when using an SHA-256 certificate, but as far as I remember, non-updated Windows 7 doesn’t understand it, so it’s no use doing dual-sign in such a manner, you need an actual SHA-1 certificate (it need not be an EV one; I’m not even sure if SHA-1 EV certificates exist at all). Last time, 3 years ago, we could obtain a normal SHA-1 in addition to our EV SHA-256, and used them both for dual signing. This year, both Digicert and Entrust said, they did not provide SHA-1 anymore. Maybe some other CAs still agree to issue it, but to be honest, I don’t see much point in trying too hard. On Jul 1, 2021 cross-signing is going to be deprecated anyway, and you won’t be able to distribuite your signed drivers without risking the certificate to be revoked.

@CaptainFlint said:
This is quite a diverse topic, there may be different answers depending on what you are trying to achieve. If you send to WHQL for Windows 7, Microsoft uses SHA-1 certificate for signing CAT, and SHA-256 for signing the driver. So if you are using CAT, it will still load in non-updated Win7, no dual signing needed from either you, or Microsoft.

Dual-signing is normally used, when you don’t use WHQL, but sign the drivers yourself and distribute them as a single package, suitable for all OS versions. This mechanism still works, provided that you have the appropriate certificates and cross-certificates which have not expired. If you don’t have an SHA-1 certificate, this can be a problem. Technically, you can select the SHA-1 signature algorithm even when using an SHA-256 certificate, but as far as I remember, non-updated Windows 7 doesn’t understand it, so it’s no use doing dual-sign in such a manner, you need an actual SHA-1 certificate (it need not be an EV one; I’m not even sure if SHA-1 EV certificates exist at all). Last time, 3 years ago, we could obtain a normal SHA-1 in addition to our EV SHA-256, and used them both for dual signing. This year, both Digicert and Entrust said, they did not provide SHA-1 anymore. Maybe some other CAs still agree to issue it, but to be honest, I don’t see much point in trying too hard. On Jul 1, 2021 cross-signing is going to be deprecated anyway, and you won’t be able to distribuite your signed drivers without risking the certificate to be revoked.

So, what should i do if i just want to sign my driver file with SHA-1 with WHQL? if it’s not possible, then how can someone load their drivers in non updated windows vista, 7?

Also, I haven’t used WHQL yet, but shouldn’t we first sign our driver with the EV cert, then send it to them? if so, then if we double sign it then send it to them, wouldn’t this load on old windows 7’s?

Why would you need to support a system on which a single KB cannot be installed so that SHA-256 is properly supported? Cuz that’s all it takes… one KB.

Seriously, don’t support such foolish configurations.

Peter

@henrik_meida said:
So, what should i do if i just want to sign my driver file with SHA-1 with WHQL? if it’s not possible, then how can someone load their drivers in non updated windows vista, 7?

Do you mean, sign the actual driver, not the CAT? Then I don’t know; it seems to me, this is impossible. I have not found any means of controlling what kind of signature you get from WHQL.

Also, I haven’t used WHQL yet, but shouldn’t we first sign our driver with the EV cert, then send it to them? if so, then if we double sign it then send it to them, wouldn’t this load on old windows 7’s?

No, you only need to sign the package that you are sending. The drivers inside the package may remain unsigned. Although, if you do sign them, then Microsoft adds another signature on top of the existing one(s). Therefore, if you dual-sign the drivers before sending them to WHQL, the resulting driver will be able to load in non-updated Windows 7, without using CAT. But as I said, the problem here lies in the fact that vendor-signing is going to be deprecated, and that it’s very hard (if possible) to get an SHA-1 certificate these days.

There are still many questions about what happens after July 1. For example, MS threatens to revoke your certificate, if you use it for cross-signing after that date. But what happens if you sign the driver, send it to WHQL, and then distribute that driver? Your signature is still there. Is this a violation of the program’s agreement? Or will MS be deleting all the existing signatures in WHQL after that date? Or will this kind of signature be an exclusion from the agreement, WHQL being considered the “main” signature? I just don’t know. :frowning:

@“Peter_Viscarola_(OSR)” said:
Why would you need to support a system on which a single KB cannot be installed so that SHA-256 is properly supported? Cuz that’s all it takes… one KB.

Seriously, don’t support such foolish configurations.

Peter

But the update isn’t available for XP, Vista, 2003, or 2008 ( https://support.globalsign.com/ssl/ssl-certificates-life-cycle/sha-256-compatibility )
And some of our customers use these. its not that uncommon. last time i heard even some branches of U.S military use XP for security reasons.

@CaptainFlint said:
But as I said, the problem here lies in the fact that vendor-signing is going to be deprecated.

But even after the date of expiration for CAs, we can still sign the driver ourselves without timestamping it and then send it to Microsoft right? because i assume timestamping after expiration will not work anymore, but we can still sign it without timestamping it, and i doubt its a violation of anything, considering we are the one who is sending it to Microsoft!

some branches of the U.S military use XP for security reasons

XP doesn’t give a crap about signed drivers. You get the “danger Will Robinson!” dialog when you install, but after installation an unsigned driver loads without complaint. The same is true with Vista-32 and 2003-32.

But even after the date of expiration for CAs, we can still sign the driver ourselves without timestamping it and then send it to Microsoft right?

Those are two unrelated items. What’s expiring is the cross-certificates. If you are submitting to Microsoft, NOTHING CHANGES. You sign the package with your EV cert and timestamp it. Cross-certificates are not part of the equation.

Even if you’re doing cross-signing, timestamping won’t be affected. “signtool” is not changing. It does your signing, and then attaches a timestamp certificate.

There are still many questions about what happens after July 1.

No shit. If they do revoke the cross certs, who would care? What part of the process breaks down? When the kernel loads a driver, all it looks for is the “Microsoft Code Verification Root” at the tip, which is what the cross-certs link to. As far as I know, it doesn’t go through the whole chain.

@Tim_Roberts said:

some branches of the U.S military use XP for security reasons

XP doesn’t give a crap about signed drivers. You get the “danger Will Robinson!” dialog when you install, but after installation an unsigned driver loads without complaint. The same is true with Vista-32 and 2003-32.

But what about 64 bit version of Vista, 2003, and 2008 (non R2) ? Does this mean that i cannot use WHQL to somehow sign the driver so it can be loaded it these systems?

Those are two unrelated items. What’s expiring is the cross-certificates. If you are submitting to Microsoft, NOTHING CHANGES. You sign the package with your EV cert and timestamp it. Cross-certificates are not part of the equation.

What happens if i sign the driver without timestamping it with a SHA-1 cert, then send it to Microsoft so they sign it as well, does this mean that the final driver will get loaded on these old non updated systems?

The 64-bit systems will INSTALL unsigned packages (after the warning), but the drivers will not LOAD unless the driver binaries are signed.

You need to take timestamping out of your computations. I don’t know how you got that entangled with these other topics, but it’s not part of the question here. Use timestamping. Always.

As I understand it, and I will surely be corrected if I am wrong, systems prior to Windows 7 SP1 will not recognize dual-signed drivers. And remember that Microsoft will throw away your CAT file and build a new one from scratch with their signature, so the package signature will not survive. In general, you’d need two packages.

@henrik_meida said:
But what about 64 bit version of Vista, 2003, and 2008 (non R2) ? Does this mean that i cannot use WHQL to somehow sign the driver so it can be loaded it these systems?

XP and 2003, even in 64-bit, don’t require the drivers to be signed. They show scary warnings, but agree to load the drivers in the end.
I’m not sure what the WHQL program status for 2008 and Vista is, I’ve worked only with Win7 targets and higher. If MS dropped the option to WHQL sign for 2008, then this OS is, sadly, completely screwed, no new drivers for it. One small chance: there is an update for 2008, which adds some SHA-2 support, but it’s unclear whether kernel-mode signature check is included. All over the Internet people say, that SHA-2 for drivers in 2008 is not supported, period, so the chance is very slim. But I have not tested it myself; I don’t have a suitable machine right now.

@Tim_Roberts said:
As I understand it, and I will surely be corrected if I am wrong, systems prior to Windows 7 SP1 will not recognize dual-signed drivers.

Dual signing was designed to work both in old and new systems, it was its whole purpose. So it is supported by at least WinXP, maybe even earlier. XP recognizes the SHA-1 signature, and does not see the SHA-256 one, but since SHA-1 is all it needs, it’s OK.

XP and 2003, even in 64-bit, don’t require the drivers to be signed

With all due respect, that’s not the case. Kernel mode code signing was instituted with the very first release of, and is still required for, 64-bit systems.

systems prior to Windows 7 SP1 will not recognize dual-signed drivers

I can tell you from my recent experience, that Windows 7 RTM + the KB for SHA-256 support, will not look at multiple signatures for validation. Try it yourself: sign a driver package and binary, then attestation sign it and try to install it on Win7. It will not work. Now try it without having first signed the binaries. Now it works. Ergo…

Peter

@“Peter_Viscarola_(OSR)” said:

XP and 2003, even in 64-bit, don’t require the drivers to be signed

With all due respect, that’s not the case. Kernel mode code signing was instituted with the very first release of, and is still required for, 64-bit systems.

Just a few weeks ago I’ve seen the same claim on another resource, and specifically for checking it I installed a WinXP x64 SP2 virtual machine (as we know, it’s based on the same kernel that Win2003), and installed a test-signed driver into it. Loaded and started without any issue.

systems prior to Windows 7 SP1 will not recognize dual-signed drivers

I can tell you from my recent experience, that Windows 7 RTM + the KB for SHA-256 support, will not look at multiple signatures for validation. Try it yourself: sign a driver package and binary, then attestation sign it and try to install it on Win7. It will not work. Now try it without having first signed the binaries. Now it works. Ergo…

Wait, what does attestation signing have to do with it? Dual signing is a set of two signatures, both using a cross-certificate, first is SHA-1, second is SHA-256. Attestation signing is a completely different procedure. I have never checked how adding attestation signature affects the OS ability to load drivers, I was talking only about pure, classic dual-signing.

Was your XP64 system in “test mode”? I am with Peter. EVERY 64-bit Windows system has had KMCS checks.

No test mode. At least, I did not turn it on myself. Even more, I have always been sure there was no such thing as “test mode” until Vista (exactly for the reason of WinXP not requiring any driver signatures). How do I check it? There is no bcdedit in WinXPx64. The booting line from boot.ini looks like:
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP Professional x64 Edition" /noexecute=optin /fastdetect
I don’t see any unusual parameters here.

I remember extremely clearly, how I was put aback by the news about Vista requiring driver signatures in x64. It was one of the many reasons why I stayed on XP for as long as possible (and on one of my machines I was using XP x64). I highly disliked the idea (and still dislike it, to be honest), that from then on you would be unable to just install and run any software you liked, whether downloaded freeware, or built from source code you yourself have developed; that developers now had to spend money to simply be allowed to run their own creations, they’ve already spent lots of time and effort on…

It is possible, however, that Microsoft pushed it into XP/2003 x64 in one of the updates after SP2 (although I have never heard of that). I cannot check it right now, because Windows Update in XP no longer works, and I failed to find a solution within a reasonable timespan. Just in case it was something wrong with the OS I was testing in; or that XP and 2003 had different kernel signing policies; or that legacy non-PNP drivers were checked differently; I have also taken time to install a fresh 2003 x64 SP2 onto a qemu-kvm VM. Inside it I installed an unsigned netkvm driver for the network card. Without the driver, the card did not work at all. The driver was successfully installed and started, the device displayed as working, showing that netkvm driver is being used, and that it is indeed unsigned; the network went up and running; sc query netkvm is showing STATE: RUNNING. And I’ve re-checked: there is no digital signature at all, either on the SYS, or on the CAT file. I’m sorry, but all my experiments show that unsigned drivers are working in XP/2003 x64. If you have any real-world examples of the opposite, please, share.

“I remember extremely clearly, how I was put aback by the news about Vista
requiring driver signatures in x64. It was one of the many reasons why I
stayed on XP for as long as possible (and on one of my machines I was using
XP x64). I highly disliked the idea (and still dislike it, to be honest),
that from then on you would be unable to just install and run any software
you liked, whether downloaded freeware, or built from source code you
yourself have developed; that developers now had to spend money to simply
be allowed to run their own creations, they’ve already spent lots of time
and effort on…”

As long as there has been a digital signature requirement there have been
options for development installation that don’t require anything more
elaborate than a test cert and test mode. Developer installs are not the
issue.

Also this world is full of state sponsored black hats ransacking systems
for sport bounty and apparently World Domination. So yeah, sign your damn
drivers.

Mark Roddy

@Mark_Roddy said:
As long as there has been a digital signature requirement there have been
options for development installation that don’t require anything more
elaborate than a test cert and test mode. Developer installs are not the
issue.

Test cert and test mode are for development stage. I finished developing and want to just use my own driver. In Linux, surprisingly, I can, ransacking blackhats or not. In Windows I have to open my own company first, spend huge amount of time on paperwork, pay additional taxes, pay for the bookkeeping, and also pay for the certificate. Just to run my own software on my own machine. I can rant about it for hours, so let’s just simply agree to disagree. It’s not on topic; I only mentioned it to stress that it caused such a huge emotional response for me, that it made the whole event of adding the signature requirement unforgettable, and that’s why I’m sure it was in Vista and not before.

It’s not on topic;

I disagree. This is perhaps the one forum in the world today where this discussion is on topic. All hail OSR.

This forum - definitely yes. This particular thread - with all due respect, I would say, no. It’s about dual signing and acceptance of signatures in different OS versions, not about personal opinions on the driver signing requirements.

@CaptainFlint said:
This forum - definitely yes. This particular thread - with all due respect, I would say, no. It’s about dual signing and acceptance of signatures in different OS versions, not about personal opinions on the driver signing requirements.

I started the thread, but i don’t mind the discussion honestly. I am learning so much from experts on this forum, and was reading all the discussions that you guys were having, and I’m pretty sure there are a lot of people who don’t mind either. at the end of day its all about sharing thoughts and experiences and learning in OSR.

I wrote earlier:

If you send to WHQL for Windows 7, Microsoft uses SHA-1 certificate for signing CAT, and SHA-256 for signing the driver. So if you are using CAT, it will still load in non-updated Win7, no dual signing needed from either you, or Microsoft.

Sorry, but as it happens, it was a complete lie. When I checked that information I looked at our WHQL-signed drivers, and didn’t notice they were over a year old. At that time, indeed, the Win7 drivers were signed using SHA-1, but that MS certificate expired in March 2020. When I sent some Win7-drivers today, I noticed they received SHA-256 (on both SYS and CAT files).

Therefore, as of now, if you don’t have an active SHA-1 certificate, there is no official way to sign a driver, which would load in a non-updated Windows 7/2008r2 and in any Vista/2008. And after July 1, there will be no official way of doing it, even if you do have an SHA-1 certificate.