none
Windows 10 driver signing for non-pnp software-only drivers. RRS feed

  • Question

  • I am looking for a link that clearly explains the Windows 10 driver signing process for non-pnp/non-hardware related drivers.  I understand the part about obtaining an EV certificate and opening a sysdev account.  I am looking for something that clearly disambiguates the process for driver signing from WHQL signing and addresses the needs of software only drivers related to information security applications.  Also, since the process involves giving MS access to the code bits, how will access to the binaries be restricted.  I have heard that the process is done off-shore, and that may be a problem for some customers.
    Wednesday, July 8, 2015 8:35 PM

Answers

  • Hi,

    Unfortunately the signing processes currently only support INF-based drivers. Fortunately the new requirement is only for kernel mode drivers. In addition, it may be possible for you to supply a very basic "dummy" INF that would allow signing using the existing pipeline. We are also actively looking at how we can set up support for signing non-INF drivers.

    Access to the binaries is strictly enforced through domain credentials. Only those who directly work on, or support, the signing pipelines have access to these binaries.

    Thursday, July 9, 2015 8:36 PM

All replies

  • Hi,

    Unfortunately the signing processes currently only support INF-based drivers. Fortunately the new requirement is only for kernel mode drivers. In addition, it may be possible for you to supply a very basic "dummy" INF that would allow signing using the existing pipeline. We are also actively looking at how we can set up support for signing non-INF drivers.

    Access to the binaries is strictly enforced through domain credentials. Only those who directly work on, or support, the signing pipelines have access to these binaries.

    Thursday, July 9, 2015 8:36 PM
  • Thanks for getting back to me.  Unfortunately, the information available to user mode applications is not reliable once a system has been compromised.  Even if the system has not been compromised there is no reliable way verify this without being able to run kernel mode code.  Microsoft is to be commended for the efforts that it has made to make Windows 10 more secure.  However, these efforts are worthless if their effectiveness cannot be verified.  A process that cannot be validated is inherently insecure.

    I am glad to hear that access to driver binaries will be restricted using domain credentials.  That is, after all, better than nothing (though not much better).  The problem from some of our customers' perspectives is that the "signing pipeline" may (and, as I have heard, does) extend into foreign countries with competing or hostile interests to the United States. Obviously, I am speaking from a U.S. perspective.  The Chinese doubtless will have similar concerns if the "signing pipeline" extends into the United States.  Indeed, even the French and Germans recently have voiced concerns about U.S. espionage and may have similar concerns.  In addition, some of our customers are competitors to Microsoft and may have legitimate concerns if the software that they use to defend their networks is handed over to a competitor for reverse engineering and analysis.  Even handing over just the page hashes might allow an adversary to identify our software as it loads so as to defeat it.  The whole design seems inherently insecure.

    I will be interested to see how MS addresses these concerns.  At the moment I would not recommend Windows 10 for applications where information security is a concern.

    Tuesday, July 14, 2015 12:52 PM
  • Fortunately the new requirement is only for kernel mode drivers.

    Is this as opposed to user-mode drivers, or as opposed to other kernel-but-non-driver components?

    Is there any way for us to test the new signing requirements?  I've been experimenting with Windows 10 x64 Build 10240 and all my drivers, both old and newly built, still load without error, regardless of whether they've been through the new signature process or not.  What are the exact criteria under which we should expect drivers to fail to load on Windows 10?

    In addition, it may be possible for you to supply a very basic "dummy" INF that would allow signing using the existing pipeline.

    We've been attempting to do this, so far without success. Any pointers/documents that would give some hints, or some sample INFs that would work for this process for a basic kernel service?

    We are also actively looking at how we can set up support for signing non-INF drivers.

    This would be very useful for us! We still have a number of components that meet this criteria.
    Friday, July 17, 2015 5:55 PM