Kernel mode signing for Class Upper Filter driver [WDF]

NTDEV
1

Hello Everyone,

I am writing a volume class upper filter driver [WDF] and am following the co-installer method for installation. The goal is to have the driver certified for meeting Kernel mode code signing requirements (so that testsigning need not be enabled on the machine where driver would be used). I have read some of the OSR posts and MSFT links (mentioned in 'Readings Done' section below) and my understanding is that :

  1. To abide by the Kernel mode driver signing requirements, for a volume class filter driver, one needs to obtain a "Software Publisher Certificate" and cross sign the driver as detailed here : Certificate Deprecation - Publisher and Commercial - Windows drivers | Microsoft Learn

  2. To use HCK as a testing methodology for finding problems with the driver, one can use HCK 8.1 and from HCK Studio, select one or more volume instances in the "Selection" tab under "Device Manager" and run the tests. However, one cannot submit the results for getting a certificate for the filter driver.

Is my understanding correct or am I missing something ? Has anything changed that renders the information in the links I am referring to be outdated ?

Thanks in advance.

Regards,
Anand.

Readings done :

I have read threads similar to what I am asking :
http://www.osronline.com/showthread.cfm?link=261913
http://osronline.com/showThread.CFM?link=234517

I have also seen the following MSFT link :

Some quoted text from the above link :

Class filter driver testing:
You must use the Windows HCK 2.1 to test filter drivers that attach to device drivers for network, storage, or other device classes. This includes driver verifier switches being applied for testing. Testing includes all tests normally scheduled for the device that the class filter driver is attached to.
For relevant tests to be scheduled, vendors need to manually select the correct physical target device that their filter driver is associated with.

Catalog visibility for HCK for Windows 8.1 ?Other? products :
Because of improvements to testing class filter drivers in Windows HCK for Windows 8.1 and to other types of drivers that don?t have a PnP ID associated, customers to be able can see these products submitted for Windows Server. These products will be listed in the ?Other? section of the catalog, even though no certification was awarded.

2

Yes, and why a coinstaller is necessary? Just update the registry and reboot.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hello Everyone,
>
> I am writing a volume class upper filter driver [WDF] and am following the co-installer method for installation. The goal is to have the driver certified for meeting Kernel mode code signing requirements (so that testsigning need not be enabled on the machine where driver would be used). I have read some of the OSR posts and MSFT links (mentioned in ‘Readings Done’ section below) and my understanding is that :
>
> 1) To abide by the Kernel mode driver signing requirements, for a volume class filter driver, one needs to obtain a “Software Publisher Certificate” and cross sign the driver as detailed here : https://msdn.microsoft.com/en-us/library/windows/hardware/ff552299(v=vs.85).aspx
>
> 2) To use HCK as a testing methodology for finding problems with the driver, one can use HCK 8.1 and from HCK Studio, select one or more volume instances in the “Selection” tab under “Device Manager” and run the tests. However, one cannot submit the results for getting a certificate for the filter driver.
>
> Is my understanding correct or am I missing something ? Has anything changed that renders the information in the links I am referring to be outdated ?
>
> Thanks in advance.
>
> Regards,
> Anand.
>
> -------------------
> Readings done :
> -------------------
> I have read threads similar to what I am asking :
> http://www.osronline.com/showthread.cfm?link=261913
> http://osronline.com/showThread.CFM?link=234517
>
> I have also seen the following MSFT link :
> https://msdn.microsoft.com/en-us/library/windows/hardware/dn609875(v=vs.85).aspx
>
> Some quoted text from the above link :
> ==================================================
> Class filter driver testing:
> You must use the Windows HCK 2.1 to test filter drivers that attach to device drivers for network, storage, or other device classes. This includes driver verifier switches being applied for testing. Testing includes all tests normally scheduled for the device that the class filter driver is attached to.
> For relevant tests to be scheduled, vendors need to manually select the correct physical target device that their filter driver is associated with.
>
> Catalog visibility for HCK for Windows 8.1 ?Other? products :
> Because of improvements to testing class filter drivers in Windows HCK for Windows 8.1 and to other types of drivers that don?t have a PnP ID associated, customers to be able can see these products submitted for Windows Server. These products will be listed in the ?Other? section of the catalog, even though no certification was awarded.
> ===================================================
>
>

3

Thank you Maxim for the response.

We will be moving towards an install process that does what you have suggested and I am reading further on the same. The OSR link I read earlier seemed to suggest using coinstaller :
http://www.osronline.com/article.cfm?article=446

Regards,
Anand.

4

You can now skip the coinstaller if you’re targeting a version of Windows
that comes with the version of KMDF that you need. The table is here:

https://msdn.microsoft.com/windows/hardware/drivers/wdf/kmdf-version-history

For example, if you have a KMDF 1.11 driver and want to install it on
Windows 8 and later you don’t need the coinstaller. However, to install it
on Windows 7 you need the coinstaller.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntdev…

Thank you Maxim for the response.

We will be moving towards an install process that does what you have
suggested and I am reading further on the same. The OSR link I read earlier
seemed to suggest using coinstaller :
http://www.osronline.com/article.cfm?article=446

Regards,
Anand.

5

Thank you Scott for the details.

Regards,
Anand.

6

Apologies for revisiting this question after a week.

After reading more about MSFT announcements related to driver signing changes for Windows 10, I am a bit confused.

  1. https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887(v=vs.85).aspx#Code_Signing_FAQ
    It says “A dashboard signed driver that has passed the HLK tests will work on Windows Vista through Windows 10, including Windows Server editions. This is the recommended method for driver signing, because it allows a single process for all OS versions.”

If that is the OS matrix I want the driver to support (on Server side i.e. Server 2008, 2008 R2, 2012, 2012 R2 and upcoming 2016), how best to go about signing the drivers using SPC ? This would be the first release of the driver, so currently the company does not have SHA1 or pre-EV SHA2 code signing certificates.
– Should I get the SHA 256 EV certificate directly ?
– How will I support Windows Server 2008 with that ? Is my understanding correct that from the EV certificate, a re-keying would be needed to get the SHA-1 ? Something like what is explained here :
https://www.digicert.com/code-signing/rekey-ev-code-signing-certificate.htm

  1. I have also read Peter’s blog on OSR recommendation :
    https://www.osr.com/blog/2015/12/29/recommendations-driver-signing-windows-10-otherwise/
    Here, again, he has mentioned that “the current plan is that your driver will have to pass the HCKs in order to be able to load on Windows Server 2016”. So, how to create an HCK 8.1. submission package for volume class filter ? I understand that Server 2016 is in technical preview mode right now, so things may change but is there something I am missing right now itself ? Does HCK 8.1 already support submitting results and getting volume class filter driver certified ?

Regards,
Anand.

7

Ok, looks like I got an answer for (2). Would request for help with (1).

For (2), I see the answer in another blog from Peter:

Excerpt :

Peter: How do we sign drivers that are not necessarily traditionally installed with an INF? For example, kernel services (non PnP software only drivers) or certain filter drivers?
James: This is another issue that we?re treating as a bug internally. The Microsoft signing pipelines are inherently reliant on an INF to determine the correct signing behaviors. The best solution I can offer currently is to create a ?dummy? INF that the service can use as an anchor to provide the correct signing.

Kindly let me know if something has changed already WRT the above.

Regards,
Anand.

8

xxxxx@gmail.com wrote:

Apologies for revisiting this question after a week.

After reading more about MSFT announcements related to driver signing changes for Windows 10, I am a bit confused.

Do not feel bad. EVERYONE is confused.

  1. https://msdn.microsoft.com/en-us/library/windows/hardware/hh801887(v=vs.85).aspx#Code_Signing_FAQ
    It says “A dashboard signed driver that has passed the HLK tests will work on Windows Vista through Windows 10, including Windows Server editions. This is the recommended method for driver signing, because it allows a single process for all OS versions.”

If that is the OS matrix I want the driver to support (on Server side i.e. Server 2008, 2008 R2, 2012, 2012 R2 and upcoming 2016), how best to go about signing the drivers using SPC ? This would be the first release of the driver, so currently the company does not have SHA1 or pre-EV SHA2 code signing certificates.
– Should I get the SHA 256 EV certificate directly ?
– How will I support Windows Server 2008 with that ? Is my understanding correct that from the EV certificate, a re-keying would be needed to get the SHA-1 ?

The first major question you have to answer is this: Do you always
intend to submit your driver packages through WHQL? That is, do you
ever expect to release a self-signed driver package?

If you will ALWAYS submit your drivers through WHQL using the sysdev
dashboard, then all you need is an EV SHA-256 certificate to create your
sysdev account. You don’t have to sign the packages yourself. WHQL
will sign the package for you, and the package you get back will work on
all of the systems since XP, including Server 2016.

If you intend to release self-signed packages, then the situation is
more complicated. The combinations and permutations are enough to make
your head spin.

  • Vista and Server 2008 only support SHA1, and that will never change.
  • Windows 7 and Server 2008R2 do SHA1, and can do SHA256 if all
    available updates have been applied.
  • Windows 8, 8.1, 10, Server 2012 and 2012R2 do SHA1 and SHA256.
  • Server 2016 will not allow self-signed drivers at all. You must go
    through WHQL.

So, for right now, if you want to release a single self-signed package
for the widest coverage, the best plan is to use an SHA1 certificate.
That works with all systems released so far.

This situation changes in a few months, when the “anniversary update” of
Windows 10 (also known as Redstone) is released. On that system, with a
bare-metal (non-upgrade) installation, when “secure boot” is set,
self-signed packages are not allowed. The package must go through the
sysdev “attestation” signing, which requires an EV certificate. The
attestation-signed packages will ONLY work on Windows 10, so you will
need to distribute at least two driver packages.

Something like what is explained here :
https://www.digicert.com/code-signing/rekey-ev-code-signing-certificate.htm

That isn’t useful. An EV certificate is always SHA-256. You would only
use re-keying if your original certificate was stolen, or something like
that.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

Thank you Tim for the elaborate response.

The first major question you have to answer is this: Do you always
intend to submit your driver packages through WHQL? That is, do you
ever expect to release a self-signed driver package?

  1. Eventually, I would LIKE to sign the drivers through WHQL but as I mentioned earlier, it is volume class upper filter for which I did not see any submission category in HCK 8.1. As I mentioned in my opening post, I understand that I can use HCK 8.1 and from HCK Studio, select one or more volume instances in the “Selection” tab under “Device Manager” and run the tests. However, I cannot submit the results for getting a certificate for the filter driver.
    This understanding is based on some references I posted earlier. So, if I am mis-understanding something, kindly correct me.

So, for right now, if you want to release a single self-signed package
for the widest coverage, the best plan is to use an SHA1 certificate.
That works with all systems released so far.

  1. In the absence of WHQL path, I would like to go for self signed drivers. I have read the SHA-1, SHA-256 requirements for various releases. I also see information like :
    https://www.globalsign.com/en/blog/microsoft-announces-updates-sha-1-code-signing-policy/
    http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx

It seems that :
I) After Jan 1, 2016, Windows Server 2008 R2 onwards will not accept SHA-1
II) With the exception of issuing certificates to developers who intend to develop only applications for Windows Vista, Windows Server 2008, CAs may not issue new SHA-1 code signing certificates after January 1, 2016.

With the above details, I have a few questions :
a) Should I ask the CA for both SHA-1 and SHA-2 certificates ?
b) If SHA-2 is also needed, then, is it better to get SHA-2 EV ?
c) Will getting SHA-1 be problematic because of 2(II) above ?

Thanks,
Anand.