Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Dual signing drivers combined with WHQL signing in 2021?

henrik_meidahenrik_meida Member Posts: 41

Hello everyone,

Is it still possible to dual sign a driver using both SHA-1 and SHA-2 with an EV certificate, then submit it to WHQL and getting signed by Microsoft? will this still allow the driver to load on old windows 7 computers that are not updated, and still load on latest windows 10 builds?

Similar to this :

https://www.digicert.com/kb/code-signing/code-signing-dual-signing-sha256-sha1.htm

Also, does this depend on the CA? meaning, should i ask a CA to provide me with both SHA-1 and SHA-2 versions of the certificate when i purchase an EV?
If so, Which CAs still support both SHA-1 and SHA-2 and are able to give me both when i purchase a single EV certificate?

Thanks.

Comments

  • henrik_meidahenrik_meida Member Posts: 41

    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?

  • CaptainFlintCaptainFlint Member Posts: 44

    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.

  • henrik_meidahenrik_meida Member Posts: 41

    @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?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • CaptainFlintCaptainFlint Member Posts: 44

    @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. :-(

  • henrik_meidahenrik_meida Member Posts: 41
    edited March 6

    @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!

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    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, [email protected]
    Providenza & Boekelheide, Inc.

  • henrik_meidahenrik_meida Member Posts: 41

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • CaptainFlintCaptainFlint Member Posts: 44

    @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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,411

    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
    @OSRDrivers

  • CaptainFlintCaptainFlint Member Posts: 44
    edited March 9

    @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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • CaptainFlintCaptainFlint Member Posts: 44

    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.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,427
    via Email
    "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
  • CaptainFlintCaptainFlint Member Posts: 44
    edited March 10

    @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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,916

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • CaptainFlintCaptainFlint Member Posts: 44

    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.

  • henrik_meidahenrik_meida Member Posts: 41

    @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.

  • CaptainFlintCaptainFlint Member Posts: 44

    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.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online