Driver Signing for Vista 32

I’m a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I’ve performed the following task, but always get a driver not signed error.

  1. created a self signed test cert, loaded the public key version on the target machine, loaded both on my dev machine
  2. created a cat file using inf2cat (from the latest win ddk)
  3. signed the cat file using the test cert and signtool
  4. verified the signature using sign tool
  5. viewed the cat file and all looks ok
  6. configured the vista machine to use test certs (test shows in all 4 corners)
  7. tried loading the driver using devcon, pnputil and snetcfg – always get the security error

repeated the process but signed the .sys file, also no avail.

our normal install is:
snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf

however, I get the error if I use devcon to install ourinf.inf directly

Someone told us we need to go through whql to resolve this, but the documentation seems to indicate otherwise. I’m guessing that there is something wrong with the .inf file?

Thanks for all your help,

Bob Sisson

Robert Sisson
Product Development Technical Specialist
NCR Corporation

xxxxx@ncr.commailto:xxxxx | www.ncr.comhttp:</http:></mailto:xxxxx>

32 bit drivers do not have to be signed, but to load silently you need a
WHQL signature not a selfsign. See
http://www.microsoft.com/whdc/winlogo/default.mspx for details.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Sisson, Robert” wrote in message
news:xxxxx@ntdev:

> I’m a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I’ve performed the following task, but always get a driver not signed error.
>
> 1) created a self signed test cert, loaded the public key version on the target machine, loaded both on my dev machine
> 2) created a cat file using inf2cat (from the latest win ddk)
> 3) signed the cat file using the test cert and signtool
> 4) verified the signature using sign tool
> 5) viewed the cat file and all looks ok
> 6) configured the vista machine to use test certs (test shows in all 4 corners)
> 7) tried loading the driver using devcon, pnputil and snetcfg – always get the security error
>
> repeated the process but signed the .sys file, also no avail.
>
> our normal install is:
> snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf
>
> however, I get the error if I use devcon to install ourinf.inf directly
>
> Someone told us we need to go through whql to resolve this, but the documentation seems to indicate otherwise. I’m guessing that there is something wrong with the .inf file?
>
> Thanks for all your help,
>
> Bob Sisson
>
> Robert Sisson
> Product Development Technical Specialist
> NCR Corporation
>
> xxxxx@ncr.commailto:xxxxx | www.ncr.comhttp:</http:></mailto:xxxxx>

  1. Did you put the certificate in the local machine’s TrustedPublisher and Root stores (and it must be localmachine, not the logged-in user’s store it will otherwise default to, as parts of the install run in a system and not a user context)? That may be what you meant by “loaded it” but that’s not at all clear to me.

  2. Signing errors are always accompanied by some fairly comprehensive logging information as to why a driver was deemed unsigned (e.g. file not in the catalog, file altered from what was cataloged, etc), in %windir%\inf\setupapi.dev.log. What does it say Is wrong with your signature?


I’m a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I’ve performed the following task, but always get a driver not signed error.

  1. created a self signed test cert, loaded the public key version on the target machine, loaded both on my dev machine
  2. created a cat file using inf2cat (from the latest win ddk)
  3. signed the cat file using the test cert and signtool
  4. verified the signature using sign tool
  5. viewed the cat file and all looks ok
  6. configured the vista machine to use test certs (test shows in all 4 corners)
  7. tried loading the driver using devcon, pnputil and snetcfg – always get the security error

repeated the process but signed the .sys file, also no avail.

our normal install is:
snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf

however, I get the error if I use devcon to install ourinf.inf directly

Someone told us we need to go through whql to resolve this, but the documentation seems to indicate otherwise. I’m guessing that there is something wrong with the .inf file?

Thanks for all your help,

Bob Sisson

Robert Sisson
Product Development Technical Specialist
NCR Corporation

xxxxx@ncr.commailto:xxxxx | www.ncr.comhttp:</http:></mailto:xxxxx>

With all due respect, Don (and I hope you realize I really do respect you, man) - the method he wants to use to “silently load” his driver works for me, and has for years (we began using it regularly in automated testing in 2007).

For maximum flexibility in our automated tests, we literally assemble test content, including many driver packages, from multiple sources- including quick fix builds from our own machines in a pinch (worse yet, sometimes we have stale old drivers nobody builds anymore- not that such a situation is allowed to last long). We automatically catalog everything and self-sign it AFTER it has been assembled on the test machine in the lab. Literally we (fully automated) assemble everything, sign it on the fly, and start running. We don’t use any secret techniques to do this- I worked from the KMCS docs everyone refers to when I put this together.

I don’t/won’t do UI automation, so I have to have “signed drivers” (and I have tests where bus drivers report HWIDs that get matched and the drivers for those also have to silently install, and even some where those drivers are in turn busses). I wouldn’t use this method if it had any serious flaws- I have enough bugs to triage most of the time as it is.

I’m certain the logo information can be inferred to apply to end-user systems, which will not / should never be enabling test signing. There a self-signed cert will definitely not work.

-----Original Message-----

32 bit drivers do not have to be signed, but to load silently you need a WHQL signature not a selfsign. See http://www.microsoft.com/whdc/winlogo/default.mspx for details.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Sisson, Robert” wrote in message
news:xxxxx@ntdev:

> I’m a newbie with driver signing. We have a an existing driver that needs to be signed to load silently on Vista32. I’ve performed the following task, but always get a driver not signed error.
>
> 1) created a self signed test cert, loaded the public key version on
> the target machine, loaded both on my dev machine
> 2) created a cat file using inf2cat (from the latest win ddk)
> 3) signed the cat file using the test cert and signtool
> 4) verified the signature using sign tool
> 5) viewed the cat file and all looks ok
> 6) configured the vista machine to use test certs (test shows in all 4
> corners)
> 7) tried loading the driver using devcon, pnputil and snetcfg –
> always get the security error
>
> repeated the process but signed the .sys file, also no avail.
>
> our normal install is:
> snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf
>
> however, I get the error if I use devcon to install ourinf.inf
> directly
>
> Someone told us we need to go through whql to resolve this, but the documentation seems to indicate otherwise. I’m guessing that there is something wrong with the .inf file?
>
> Thanks for all your help,
>
> Bob Sisson
>
> Robert Sisson
> Product Development Technical Specialist NCR Corporation
>
> xxxxx@ncr.commailto:xxxxx |
> www.ncr.comhttp:</http:>


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer</mailto:xxxxx>

On 32 bit, you should not need to sign the driver for it to load and
function. All 64 bit drivers MUST be signed. However, what you way be
getting is the WHQL warning and that you cannot absolve until you submit the
driver to WHQL and the driver is then signed with the WHQL certificate.

Gary G. Little

H (952) 223-1349

C (952) 454-4629

xxxxx@comcast.net

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Sisson, Robert
Sent: Wednesday, November 03, 2010 11:20 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Signing for Vista 32

I’m a newbie with driver signing. We have a an existing driver that needs
to be signed to load silently on Vista32. I’ve performed the following
task, but always get a driver not signed error.

  1. created a self signed test cert, loaded the public key version on the
    target machine, loaded both on my dev machine

  2. created a cat file using inf2cat (from the latest win ddk)

  3. signed the cat file using the test cert and signtool

  4. verified the signature using sign tool

  5. viewed the cat file and all looks ok

  6. configured the vista machine to use test certs (test shows in all 4
    corners)

  7. tried loading the driver using devcon, pnputil and snetcfg – always get
    the security error

repeated the process but signed the .sys file, also no avail.

our normal install is:

snetcfg.exe -v -l ourinf.inf -m ourinf_m.inf -c s -i nt_ourinf

however, I get the error if I use devcon to install ourinf.inf directly

Someone told us we need to go through whql to resolve this, but the
documentation seems to indicate otherwise. I’m guessing that there is
something wrong with the .inf file?

Thanks for all your help,

Bob Sisson

Robert Sisson
Product Development Technical Specialist

NCR Corporation

mailto:xxxxx xxxxx@ncr.com |
http:</http:> www.ncr.com


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Information from ESET Smart Security, version of virus signature
database 5588 (20101103)


The message was checked by ESET Smart Security.

http://www.eset.com</mailto:xxxxx>

Thanks everyone, I’m still a little confused:

Our original plan to eventually sign the drivers with a cross certified key. We have already purchased the certificate for this. There are instructions in the technet documentation for this, including the “Windows Kernal-Mode Code Signing Walkthrough” document and the step by step guide for signing and staging device drivers.

I get no errors when signing the cat or sys files, and the signatures verify fine with the signtool. I have loaded the certs in trusted root store, but not the trusted publisher store – I will try that next.

We are also looking at whql for this, but I would like to avoid that if possible.

Thanks again – appreciate any more pointers

Also did not work. Looking at references from MS (from above) I should be able to do this:

Windows Vista solves these problems by allowing vendors and IT departments to sign and publish drivers by using an Authenticode signature. IT departments can configure Windows to treat drivers that they signed as equivalent to drivers that were signed by Microsoft, thus allowing an IT department to silently deploy drivers across their corporation, even updating in-box drivers. Vendors can quickly deploy emergency fixes to their customers without waiting for a signature from Microsoft. Meanwhile, because these drivers are signed, IT departments and end users can be secure, knowing that the drivers have not been altered in any way since they were published. Further, users know the source of the drivers because the signature also identifies the publisher.
These third-party signatures complement the signatures that Windows Hardware Quality Labs (WHQL) gives. The third-party signatures guarantee driver integrity, but do not imply any level of testing or quality. The signatures that are given as part of the Windows Logo Program not only verify driver integrity, but also indicate a level of quality that is based on tests run by WHQL.

xxxxx@ncr.com wrote:

Our original plan to eventually sign the drivers with a cross certified key. We have already purchased the certificate for this. There are instructions in the technet documentation for this, including the “Windows Kernal-Mode Code Signing Walkthrough” document and the step by step guide for signing and staging device drivers.

That works fine for KMCS, but this has no effect on “silent install”.
The install-time signature checking is entirely separate from the 64-bit
KMCS checking. There was an article on this very topic by someone very
dear to me in this month’s NT Insider.

I get no errors when signing the cat or sys files, and the signatures verify fine with the signtool.

That’s fine for 64-bit KMCS, but is useless for install-time checking.

We are also looking at whql for this, but I would like to avoid that if possible.

If you hope to release this outside of your own office, WHQL is the only
way to get silent installs.


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

On Wed, Nov 3, 2010 at 3:02 PM, Tim Roberts wrote:
> If you hope to release this outside of your own office, WHQL is the only
> way to get silent installs.

Well no it isn’t. You have to pre-install an acceptable cert on the
target machine and then install your driver. No pop-uppys. This is
covered under ‘how to release sign a kernel module’ in the walk
through.

Mark Roddy

>>
I get no errors when signing the cat or sys files, and the signatures verify fine with the signtool. I have loaded the certs in trusted root store, but not the trusted publisher store – I will try that next.
<<

This is a bit abstracted, but it should help understanding this process.

Silent installation of the driver requires a trusted publisher. That is why the KMCS document says to put the certificate there. Even if the root for your certificate says you can be trusted we will still verify each time someone who is not a trusted publisher tries to put something on a machine.

You have to put it in root, because even if you’re a “trusted publisher” we can’t be sure it’s really you if the certificate chain ends in an unknown [hence untrusted] root. A self-signed cert has no chain, so it has to be both places. (BTW [I could be wrong about this part- the rest I am quite sure of] this bit about adding to root may only work when test signing mode is enabled).

>
Windows Vista solves these problems by allowing vendors and IT departments to sign and publish drivers by using an Authenticode signature. IT departments can configure Windows to treat drivers that they signed as equivalent to drivers that were signed by Microsoft, thus allowing an IT department to silently deploy drivers across their corporation, even updating in-box drivers. Vendors can quickly deploy emergency fixes to their customers without waiting for a signature from Microsoft. Meanwhile, because these drivers are signed, IT departments and end users can be secure, knowing that the drivers have not been altered in any way since they were published. Further, users know the source of the drivers because the signature also identifies the publisher.
These third-party signatures complement the signatures that Windows Hardware Quality Labs (WHQL) gives. The third-party signatures guarantee driver integrity, but do not imply any level of testing or quality. The signatures that are given as part of the Windows Logo Program not only verify driver integrity, but also indicate a level of quality that is based on tests run by WHQL.
<<

Yes, this is how it is supposed to be. To address another issue mentioned a couple of times here, let’s be clear.

You start out untrusted. WHQL starts out trusted (call it an “inbox certificate”). So as far as this silent install thing goes- yes, THE VERY FIRST TIME we see something from you, they’ll get a popup asking if you can be trusted (or you need an install procedure that installs your certificate appropriately, and that action will also require their approval, so the first one is never free without WHQL).

But if you’ve got a proper cross-certified certificate and they elect to make you a trusted publisher, then you chain to that “inbox” stuff, and we will trust you from henceforth- so all future drivers from you [not just that one] will install silently.

I know this works- I use a multiport serial card with Authenticode (not WHQL) signed drivers on the X64 machine I’m writing this from, and if I mark the checkbox saying to trust all future content from them when I install the main driver, it silently installs all the ports after the adapter’s driver starts. If I don’t, then I get asked again to verify trust for each of the ports as it gets enumerated.

>
Also did not work. Looking at references from MS (from above) I should be able to do this:
<<

Yes you should- the people providing my multiport serial card could, and as I said before, I’ve been doing it myself (in the self-signed test form) for a really long time now.

There are also aids provided to help you and I diagnose problems when they arise.

One of those is the setupapi logs I mentioned before, which, beginning with Vista, provide a lot more detail about what is going on when things like this break. What does that log say is wrong? You seem to be focused on the mechanics of the certificate, but it’s not clear from the information presented so far, that this is what the problem actually is here.

Is there a difference in behavior for installations that are “legacy” (Non
PnP) and PnP?

I have a NDIS 5 protocol driver (signed binary) that can be installed as a
legacy driver using the SCM. No pop-ups are seen.

The same driver can be installed using an INF using netcfg. In this case
there is a “this is an Authenticode-signed driver” pop-up.

Both installs are on clean Vista or later machines.

Thomas F. Divine


From: “Mark Roddy”
Sent: Wednesday, November 03, 2010 3:14 PM
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] Driver Signing for Vista 32

> On Wed, Nov 3, 2010 at 3:02 PM, Tim Roberts wrote:
>> If you hope to release this outside of your own office, WHQL is the only
>> way to get silent installs.
>
> Well no it isn’t. You have to pre-install an acceptable cert on the
> target machine and then install your driver. No pop-uppys. This is
> covered under ‘how to release sign a kernel module’ in the walk
> through.
>
> Mark Roddy
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

These behaviors are by design, and yes, they are different.

On a 64-bit system, though, the signing rules still apply to the legacy case as far as loading (not installing) goes. Nothing untrusted can be loaded.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, November 03, 2010 12:56 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Driver Signing for Vista 32

Is there a difference in behavior for installations that are “legacy” (Non
PnP) and PnP?

I have a NDIS 5 protocol driver (signed binary) that can be installed as a legacy driver using the SCM. No pop-ups are seen.

The same driver can be installed using an INF using netcfg. In this case there is a “this is an Authenticode-signed driver” pop-up.

Both installs are on clean Vista or later machines.

Thomas F. Divine


From: “Mark Roddy”
Sent: Wednesday, November 03, 2010 3:14 PM
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] Driver Signing for Vista 32

> On Wed, Nov 3, 2010 at 3:02 PM, Tim Roberts wrote:
>> If you hope to release this outside of your own office, WHQL is the
>> only way to get silent installs.
>
> Well no it isn’t. You have to pre-install an acceptable cert on the
> target machine and then install your driver. No pop-uppys. This is
> covered under ‘how to release sign a kernel module’ in the walk
> through.
>
> Mark Roddy
>

Thanks, I figured out the root of my first problem – the original files given to me had a signature, and oversigned it and caused some issues.

Undid all of that and it works as expected, except my customer now no longer wants the first time do you trust us dialog box - the first time.

Looking at the post by Bob K -

You start out untrusted. WHQL starts out trusted (call it an “inbox
certificate”). So as far as this silent install thing goes- yes, THE VERY FIRST
TIME we see something from you, they’ll get a popup asking if you can be trusted
(or you need an install procedure that installs your certificate appropriately,
and that action will also require their approval, so the first one is never free
without WHQL).

We need to go through WHQL to make our customer happy.

Thanks, I learned a bunch

Bob

>1) Did you put the certificate in the local machine’s TrustedPublisher and Root stores (and it must

be localmachine, not the logged-in user’s store it will otherwise default to, as parts of the install run in
a system and not a user context)? That may be what you meant by “loaded it” but that’s not at all clear
to me.

More so.

If a “toy” cert is created using MAKECERT without having a good root cert (self-signed), then it is a good idea to a) open it using the shell ext b) extract the public part of “Root Agency” from it and c) install this extracted Root Agency to Local Machine Trusted Roots.

Then install the whole cert to Local Machine Trusted Publishers (or omit this, this will cause the yellow “do you trust?” dialog box from SetupCopyOEMInf).

No need to turn the OS to the mode with “Test” in the corners. At all.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>“Windows Kernal-Mode Code Signing Walkthrough”

Sorry, but you’re mixing KMCS with PnP signing.

KMCS requires cross-certs. PnP signing does not.

KMCS does not use cert stores on the machine. PnP signing uses them.

KMCS is checked on binary load, PnP - in SetupCopyOEMInf.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

>You have to put it in root, because even if you’re a “trusted publisher” we can’t be sure it’s really you if

the certificate chain ends in an unknown [hence untrusted] root.

More so. “The chain must end with a trusted root” condition is checked earlier then “being in Trusted Publishers” one.

If the first condition is not met - then this considered to be bad digital signature, and cause the red dialog box (same way as if some bytes were altered).

Only if all crypto is OK and the root is in Trusted Roots (i.e. the digital signature is good) - the “being in Trusted Publishers” is checked.

KMCS does not use cert stores, and thus requires the cross-cert, which is the “trusted root” embedded to the binary itself.

A self-signed cert has no chain,

A chain of 2 items - Root Agency, then Your Toy Company.

Put Root Agency to roots and Your Toy Company to publishers, after this all works OK (2003+ at least, there were issues on XP but I don’t remember what they were).


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

On Wed, 3 Nov 2010 15:56:11 -0400
“Thomas F. Divine” wrote:

> Is there a difference in behavior for installations that are
> “legacy” (Non PnP) and PnP?
>
> I have a NDIS 5 protocol driver (signed binary) that can be installed
> as a legacy driver using the SCM. No pop-ups are seen.
>
> The same driver can be installed using an INF using netcfg. In this
> case there is a “this is an Authenticode-signed driver” pop-up.

Do you know if there’s a way to install using netcfg via WiX/DifX? I’d
like to move away from using the legacy method for my protocol driver
but I can’t find any documentation.


Bruce Cran

On 11/04/2010 01:10 AM, Maxim S. Shatskih wrote:

KMCS does not use cert stores, and thus requires the cross-cert,
which is the “trusted root” embedded to the binary itself.

Almost correct. The “trusted root” in this case is very likely an “MSCV
root” certificate compiled into the boot driver loader.

*This* is used to verify the cross-cert (and thus the whole chain).

(“Trusted root” must always be something that is already on the machine.
Otherwise this is not secure. It can also be a checksum of the top-level
certificate, but *something* verifiable must be present.)

On 11/03/2010 09:29 PM, xxxxx@ncr.com wrote:

it works as expected, except my customer now no longer wants the
first time do you trust us dialog box - the first time.

You could avoid that “first-time box” by pre-installing the publisher
certificate to “Trusted Publishers”, e.g. via ADS. Unless your customer
is a company who wants to sell the driver packaged with hardware.

A caveat (excellent series of posts, Max, I’ll put that in first):

>
Put Root Agency to roots and Your Toy Company to publishers, after this all works OK (2003+ at least, there were issues on XP but I don’t remember what they were).<<
<<

The process was designed for Vista and up- it working in any fashion for earlier OS is nice, but not directly intended.

You will still get unsigned driver popups if the device setup class is one where a WHQL program existed at OS RTM- this applies only to WS03, and I don’t know whether or not (and forgive me for this if you can, but I really don’t WANT to know) this was updated in SPs.

One painful memory of the last few years is having to revert to manual testing of the KMDF modem sample on WS03 because of this. There’s a link for this somewhere on MSDN, but I’m not going to try to look up that kind of trivia- that’s what search engines are for.

FWIW, I didn’t have problems using self-signed certs on XP (even Win2K, although we dropped that from automation eventually), but I also suspect we configured the OS to default to ignoring unsigned drivers, probably without knowing it. I can remember some curiosity about why it was working, but I don’t recall a conclusive investigation, and since it was working, I had bigger problems to solve.