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

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

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/


Minifilter codesigning requirements (FSFilter HSM)

RogerWilcoRogerWilco Member Posts: 2

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.

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,807

    We get this question here once every month or so.

    Here is the answer.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • RogerWilcoRogerWilco Member Posts: 2

    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.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,807
    edited March 14

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Martin_DrábMartin_Dráb Member - All Emails Posts: 81

    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 :-).

    Martin Dráb

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!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA