Minifilter codesigning requirements (FSFilter HSM)

Hello OSR Community,
I’m looking for some clarity on the codesigning requirements for an FSFilter HSM minfilter driver.

I was previously using an OV codesigning certificate (expiring soon), with a cross-certificate, to sign the minifilter sys and cat files. This allowed the minifilter to be installed on Windows 10 client machines without any issues. I believe the cross-certificate is what allowed it to be successfully installed on Windows 10 without needing an EV codesigning certificate or attestation signing. I know these cross-certificates are being deprecated and most are set to expire in about a year, which means it is not a viable option for the future.

It appears that there will no longer be a way forward signing with an OV certificate and that it is absolutely required to:

  • Sign with an EV certificate
  • Submit the minifilter driver for attestation signing

Is this correct?

I really appreciate any assistance you folks can provide.

We get this question here once every month or so.

Here is the answer.

Peter

1 Like

Thanks Peter! I really appreciate the response.

In short, the answer to my question appears to be “yes, EV cert and attestation are absolutely required for future compatibility”. I figured as much, but the fact that things are currently working well without an EV cert and attestation prompted me to look for other potential solutions.

One of the big hurdles with EV certs and attestation is that it is much more difficult to automate. Right now I have everything automated, from git check-in to auto-building, signing, packaging, and distribution using virtual environments. EV certs require a physical system because of the hardware token and attestation sounds like a very manual process involving signing into a portal, dragging a package for upload, waiting, then downloading it after ~30 minutes.

I’ll now start looking at how I can automate, as much as possible, against these new requirements.

Again, thanks for the swift response. You have a great community here.

Thanks for the kind words.

I’d just like to note that it is true you need an EV Cert to establish the dashboard account. However, you do NOT need to sign your driver with that cert. or, at least, this WAS the case when I last talked with my pals up in Redmond.

You can register multiple certs. As long as one is an EV Cert, and you use this one to verify your dashboard account… you can use a non EV one for your submissions, precisely for the reasons you indicated.

I have not personally tried this after advocating for it ardently a couple of years back. We had a client in a particular situation who needed this badly, but their situation changed (well, actually, our situation changed with respect to this particular client ?.. but no matter).

If you investigate further and try this, let us know if it (still) works, please.

Peter

1 Like

One of the big hurdles with EV certs and attestation is that it is much more difficult to automate. Right now I have everything automated, from git check-in to auto-building, signing, packaging, and distribution using virtual environments. EV certs require a physical system because of the hardware token and attestation sounds like a very manual process involving signing into a portal, dragging a package for upload, waiting, then downloading it after ~30 minutes.

One company I am working for does the whole attestation signing process (i.e. uploading the driver to that Microsoft portal) only just before a new release. For the purpose of automated testing and continuous integration, the driver is just signed by the EV certificate (AFAIK) and that’s it. Most of the tests can be done even if the signature is not so strong.

You can automate the signing even if the private key is present only on a smart card. Since SignTool displays an extra window to receive PIN for the smart card, you can send necessary events to it in order to simulate the key srokes. Of course, the smartcard needs to be connected to the machine where the signing is happening (either directly, or via a RDP connection for example). I admit that this solution is kinda dirty and probably not exactly what security guys would be happy with… but it quite works :-).

1 Like