Driver Signing.

[basil00]

I am looking for a new sponsor for driver signing. The high-level requirements are:

• Willing to sign new releases of the WinDivert32.sys and WinDivert64.sys driver (probably about 1-2 releases per year).
• Have an Extended Validation (“EV”) Code Signing Certificate as required by Windows 10.

Note that there is no immediate problem as the current release is already signed. This is for anticipated future releases or bug fixes.

If you can help then please contact basil at reqrypt.org.

[TechnikEmpire]

It's looking like I'm going to be getting an EV cert to sign WinDivert for my own purposes within the next month or so. It's not 100% but I'll contact you when I'm at that point.

[basil00]

That'd be great. Please let me know one way or the other.

[TechnikEmpire]

@basil00 any suggestions or advice on which cert to buy and where? I find lots of ev certs but some of them make different claims about code signing.

[basil00]

I find lots of ev certs but some of them make different claims about code signing.

Usually you just want the cheapest that will do the job. I found this page that has a list of EV certificate authorities that should work (given they are directly linked to by Microsoft).

[TechnikEmpire]

@basil00 I remember some info you had about special rights for sponsors. Can you link to that info? I'm also curious if it's possible to add in some sort of mechanism to prevent tampering. For example, a content filter or AV scanner that uses WinDivert to capture all data, if there's something at the driver level where you can prevent a forced shut down of the driver. This way you could open a capture all handle that drops all by default, and someone can't just run sc.exe stop WinDivert1.XX to get by it. Thoughts?

Thanks for your time.

[basil00]

@TechnikEmpire, I am not sure what info you are referring to. Perhaps contact me via email and we can discuss.

For example, a content filter or AV scanner that uses WinDivert to capture all data, if there's something at the driver level where you can prevent a forced shut down of the driver. This way you could open a capture all handle that drops all by default, and someone can't just run sc.exe stop WinDivert1.XX to get by it. Thoughts?

This might not be a good idea as part of a general WinDivert release that can also be used by malicious applications, e.g. AdWare. In such cases it is important that the user/Administrator be able to disable WinDivert as a last resort.

It might be okay for a specialized WinDivert that is locked down to a specific application (e.g. AV). I am not sure how it can be implemented though.

[thalomatt]

@TechnikEmpire Do you know if you need an INF file to submit to the new driver signing standards?

[TechnikEmpire]

@thalomatt I'm not sure. I've never gone through the process myself.

[TechnikEmpire]

I'm in touch with an EV cert supplier. It's going to take some time because as a sole proprietor I need to jump through more hoops (signing oaths basically) but when I manage to get an EV I'll sign new releases.

[basil00]

Thanks, there really should be a new release that includes #92. Also I have some other minor driver improvements on my todo list. One thing I want to change is not having WinDivertSend() block on injection complete, which may be a performance bug.

[TechnikEmpire]

Yeah I know there's a few things emerging, plus I'd like to see if I can fork it and make some additions you may be interested in. That aside, I'm pretty heavily relying on your work here for my own open source project so I'd like to contribute back somehow if I can. It may be a bit but I am getting one and will definitely sign once I do.

[thalomatt]

@TechnikEmpire , When you've got your cert, let me know if I can help - it wasn't a trivial matter packaging it up for Microsoft to sign the driver. At least not trivial to this non-Windows developer. But seems to work for all of our users - a few Windows 7 users said it didn't work for them, but after asking if they had all the updates, they didn't reply, so I'm guessing they updated and it started working.

[basil00]

@thalomatt I'd guess the Windows 7 problem is because you built WinDivert with a newer version of WDK. I assume this is a requirement from Microsoft? The newer driver will work under Windows 7 only after the user has installed the latest updates.

[TechnikEmpire]

I believe the group I'm working with has an EV cert inbound. We had troubles with initial orders, the company ended up reneging on their offer to issue to an individual after the fact. Will update when it comes in.

[basil00]

@TechnikEmpire, that sounds promising. I am also in contact with another company that has recently expressed interest in helping out. The driver signing process is not as simple as before (now has hardware tokens, SHA1 versus SHA256, dev portal step), so I don't know how long it will take.

Also, it seems that Windows Server 2016 has even stricter driver signing requirements, requiring HLK testing.

[basil00]

@thalomatt writes...

But seems to work for all of our users - a few Windows 7 users said it didn't work for them, but after asking if they had all the updates, they didn't reply, so I'm guessing they updated and it started working.

Actually, I now think the problem is that you have signed the driver using the newer SHA2 algorithm, which is not supported by non-updated versions of Windows 7. To fix this problem, you are supposed to "rekey" your EV code signing certificate to allow duel SHA1/SHA2 signing. To rekey you need to contact your certificate provider. Otherwise, you can not bother and just not support non-updated Windows 7.

[basil00]

There is a new release which contains EV certificate signed drivers: https://github.com/basil00/Divert/releases/tag/v1.3.0

It has also been signed by the Microsoft dev portal, so should work for Windows 10 with secureboot enabled. I have not had the time to verify this since my virtualization environment doesn't support secureboot.

There are caveats:

• The signature uses the SHA2 algorithm which is not supported by Windows 7 unless a patch is installed. If your Windows 7 system is up-to-date the patch should already be installed.
• The drivers will not work for Windows Server 2016 unless you disable secure boot. This is because even stricter driver signing requirements including passing the HLK tests. This is on the TODO list.

Note also that version 1.3.0 is essentially the same as version 1.2.0-rc but with bug fixes. The latest performance patches have not been included in this release.

[TechnikEmpire]

@basil00 Just curious, will we lose Vista compat with the new driver signing requirements?

[basil00]

Vista and unpatched Windows 7 support should be possible by "rekeying" the EV certificate to SHA1, then dual signing with SHA1/SHA2. That said, Vista is no longer officially supported by Microsoft, so I do not intend to "officially" support it anymore either.

[nefarius]

Heya @basil00 I'd like to hop in on the driver signing train 😄

[basil00]

Great, if you want to help then contact me via email.

[joveice]

Status on this?

[basil00]

The project currently has two sponsors who have expressed willingness to sign the driver. There has not been a new version for a while, but this may change in Q2 2018.

[arifulhuq]

@basil00 What is the status on this? I'd like to help as a sponsor and/or explore possibilities to fast track this work.

[basil00]

@arifulhuq If you'd like to help sign the driver then please contact me via email (see email here). I'd certainly welcome more sponsors.

Currently the project has two sponsors but I've yet to contact them regarding WinDivert2.0, but probably will do soon.

[dhaavi]

I spent the last weeks/months working on a driver that is somewhat similar to WinDivert - it's geared more towards firewall applications and will be open sourced on Github soon. I am now trying to figure out how to sign this thing (got the EV cert!).

If anyone here would be willing to give a quick overview how to go about this, that would be great. Would also be nice to have this documented better for WinDivert. (We used the build environment of WinDivert.) How have WinDivert signers done this in the past?

Anyway, as soon as I get the hang of this, I'd also be happy sign WinDivert releases.

(PM via Twitter or Email)

[basil00]

You'll need to go through all the Microsoft documentation on how to do it. I've never done it personally.

The gist of it is that you need to create and sign (with your EV certificate) a driver package (sys + inf) and upload it do the dev portal for attestation signing. Microsoft will then sign the driver and it is ready for use.

[dhaavi]

Yes, I have gone through the Microsoft documentation until my head hurt. 😏

I almost wanted to start with the attestation signing, but then I read here that An attestation signed driver will only work for Windows 10. It will not work for other versions of Windows, such as Windows 8.1, Windows 7, or any Windows Server versions.

After checking with Statcounter and realizing that Win10 still only has a Windows market share of 55%, I though that it would be really great to at least also sign it for Win7.

Going further down that road, the docs also explain here how to sign for all Windows versions: Use the Hardware Lab Kit (HLK) to test your submission against Windows 10 and use the Hardware Certification Kit (HCK) to test against earlier versions of Windows. [...] This is the only way to make a submission apply to all Windows versions.

So the two questions that arose, were:

• Does attestation signing really only work for Win10? I mean, this is an internal network filter driver. There are compatibility guarantees across Windows versions, and there is no interaction with custom hardware.
• How much work is HLK/HCK testing? Is there any way to automate this? A DevOps pipeline maybe?

I should have been more clear in my first comment.

Also, the docs say that attestation signing is more complicated, but still a valid option. I have the feeling that HLK/HCK testing is way more complicated.

If this is going to much off topic for this issue, I'll happily move this somewhere else. I didn't think of this becoming a huge thread and hoped to ping the right people by commenting here.

[TechnikEmpire]

That's odd cause those docs are from 2017 yet I've gone through attestation signing and AFAIK this is how releases here are done. You zip it, upload it in the dashboard and Microsoft spits out a signed version. Its fast and easy. Just make sure you zip it right. 32 and 64 bit need to be in folders in the zip named the same way windivert names them. (Amd64 or whatever etc).

[dhaavi]

Thanks @TechnikEmpire, you are right. This actually worked, contrary to the official docs. I suspect that it works because Microsoft certifies the driver as Universal, because it only uses internal APIs.

The repo is now online, here is the description of the semi-automated signing process: https://github.com/Safing/portmaster-windows-kext/tree/master/release

To be explicit: I verified that the signature works on Windows 7, 8.1 and 10. I had to first install updates on the Win7 VM, as it was from 2015 or so.

I guess this means I am available for WinDivert signing now! 😉

[basil00]

@dhaavi

Does attestation signing really only work for Win10? I mean, this is an internal network filter driver. There are compatibility guarantees across Windows versions, and there is no interaction with custom hardware.

Strictly speaking, yes, but your driver will also be dual signed by your EV certificate, and the latter will work for Windows 7, 8.

How much work is HLK/HCK testing? Is there any way to automate this? A DevOps pipeline maybe?

I've never tried it, but from what I read it seems like a hassle to set up. Certainly much more work than attestation signing.

The only outstanding question is whether Windows Server 2016 accepts attestation signed drivers, or if a WHQL release signature is required (i.e., HLK). The docs state that HLK is required, but there is a lot of confusion on the topic, as it seems attestation signing also works fine. From what I read it only makes a difference if the driver package uses a .cat file, which WinDivert does not.

I guess this means I am available for WinDivert signing now!

Great, if you want to help sign, then please contact me via email (see bottom of page here).

[dhaavi]

Strictly speaking, yes, but your driver will also be dual signed by your EV certificate, and the latter will work for Windows 7, 8.

My driver worked on Win7, Win8.1 and Win10 with just the Microsoft signature, but did not work with just my signature. I use the Microsoft signature as the primary one (Win7 only detects the primary signature), and then add mine afterwards for improved transparency.

The only outstanding question is whether Windows Server 2016 accepts attestation signed drivers

I am currently downloading Windows Server 2016 and 2019, will report back.

[dhaavi]

The Universal driver signature also works on Windows Server 2016 and 2019. Both with only the Microsoft signature and with my EV sig added. 🎉 Nice!

[basil00]

Did you test with Secure Boot enabled? Otherwise I think it will work without WHQL regardless.

[dhaavi]

Um. I don't know. I ran everything in Virtualbox and didn't turn anything off. What would be the default for this environment?

without WHQL

Do you mean that just my EV cert should work when Secure Boot is disabled?

[basil00]

@dhaavi I'm not sure if it is possible for VirtualBox to emulate secureboot for the guest. This is part of the reason I never tried, since it might require a physical machine to test.

Btw, to what extent is PortmasterKext a derivative work of WinDivert? Much of the code appears different but the README mentions "based on/influenced". If there is some WinDivert code, it is important not to remove copyright notices at least for the relevant portions.

[nefarius]

That's one of the many caveats; a cross-signed driver will not load on Secure Boot enabled systems due to more restrictive Code Integrity Policies.

[dhaavi]

Thanks for the hint about Secure Boot. To clarify: the driver is signed directly by Microsoft and then also by me. The driver then has two distinct signatures. I will investigate further and check if the driver is accepted if signed that way.

[nefarius]

That's another pitfall: since Secure Boot is available since Windows 8 the Windows 10 signature won't work there and your cross-signed cert will also be denied.

[ronshah90]

@dhaavi you can use Hyper-V to emulate Windows 2016 with Secure Boot. @nefarius According to this comment: https://github.com/MicrosoftDocs/windows-driver-docs/issues/1068#issue-382747909 it might actually work

[dhaavi]

Sorry, forgot to update you guys with the most recent findings: I had my colleague test the signatures on his Secure Boot enabled Windows 10 machine - the signatures, both only from Microsoft and with mine added to it, worked fine. I don't have access to a machine with Win8.1 and Secure Boot at the moment.

So, to sum it up - I have two versions of the driver: one is only signed by Microsoft, the other has my EV signature added to it for transparency. Both work on:

• Windows 7
• Windows 8.1
• Windows 10 (also with Secure Boot)
• Windows Server 2016
• Windows Server 2019

Thanks for the hint about Hyper-V, I may take that route for future testing.

[basil00]

Windows Server 2016

It'd be interesting to also try this one with Secure Boot.

[TechnikEmpire]

@basil00 It seems none of the drivers are dual signed with sha1 anymore. Is this intended? I assume that attempting to support non-updated Windows 7 is simply not a thing anymore.

[basil00]

Yes pretty much. Also because the SHA1 signature seemed to cause more problems than it solved, such as mysterious revocation errors.

[helloray]

I have KB3033929 patch installed on Win7 but run WinDivert-2.2.0-A/B/C with an error: failed to open the WinDivert device (577). WinDivert-1.4.3-A is running well without any problem. Any suggestions? Thanks.

[basil00]

@helloray Try this version: https://reqrypt.org/download/WinDivert-2.2.0-D.zip

[helloray]

@basil00 Same result. error: failed to open WinDivert handle (err = 577)

[basil00]

I forgot to mention that you should reboot before trying the new version. If not, then Windows will attempt to reuse the previous driver with the signature it did not like.

[helloray]

Hi @basil00 , I have already rebooted before try WinDivert-2.2.0-D. Any other possible reasons?

[basil00]

I am not sure. As a last resort, you can try manually deleting any WinDivert entry in the registry. That seemed to have worked for other people.