Vista 64-bit code signing: "windows can't verify the publisher of this driver"

Nobody that I know, to be honest. But it would make a great document.

The problem is that these two different signing policies (signing’s effect on the installation dialog – generating one or more different user warnings – versus Kernel Mode Code Signing for x64) are designed and administered by two entirely separate groups at Microsoft.

We need somebody who has a comprehensive understanding of these processes to be able to create that document. OR somebody who cares enough to do the research/experimentation.

If somebody DOES write it up, I know we’ll be happy to put it in The NT Insider for the world to read and understand.

Peter
OSR

> The problem is that these two different signing policies

(signing’s effect on the installation dialog – generating
one or more different user warnings – versus Kernel Mode
Code Signing for x64) are designed and administered by two
entirely separate groups at Microsoft.

That’s a great reminder. I sometimes think there is a single Windows god at
Microsoft that has everything totally coordinated. And then scratch my head
when it’s not.

Jan

IIRC, boot start drivers must have an embedded signature, and drivers that start later can use either an embedded signature or a .cat signature.

(For in-box things, a .cat is preferred where possible so that the large cert blobs aren’t duplicated for every single PE image, but rather are stored in a more efficient, centralized location. The sig blob embedded in a binary with the certs included might be on the order of 10k per binary, whereas a .cat doesn’t need to duplicate the certificate parts (largest by far) over and over.

For example, win32k.sys on my Vista SP1 x64 box has a .cat signature and not an embedded one (no security directory in the PE header). However, ntfs.sys has a security directory with the certificate blob + signature.

  • S

-----Original Message-----
From: Jan Bottorff
Sent: Tuesday, March 17, 2009 11:55
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Vista 64-bit code signing: “windows can’t verify the publisher of this driver”

Tim,

It seems like you’re both agreeing and disagreeing with what I said in two
different paragraphs.

Your reply said “an x64 driver that is used by the boot loader must have the
signature embedded in the driver binary” and then your reply also said “The
x64 KMCS signature check happens every single time the driver is loaded”.

My understanding is (unless you are in a special debugging/test mode) that
EVERY x64 driver on Vista/W2K8 will need an embedded signature, no matter
when it starts. Are you saying your believe a non-boot start x64 driver on
Vista/W2K8 does not need an embedded signature, or am misinterpreting what
your saying?

Yes, I was not totally clear about the validity of a GlobalSign certificate,
and yes there would need to be a valid certificate chain to a valid root,
and that requires adding the correct cross-certificate. I always have used
VeriSign certificates, so don’t have any personal knowledge about using
GlobalSign certificates.

My overall point was that “signed driver” has multiple meanings, and the
correct kind of signature is required for a desired purpose. Putting a KMCS
signature on a driver will not make it show up as “signed” in device
manager, or make it install silently. As I remember, a correctly signed
.cat, and unsigned binary (on x64 Vista/W2K8) will show up as signed in
device manager, but when the OS tries to start the driver, it fails with an
error that says the binary is not signed.

Jan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Tuesday, March 17, 2009 9:49 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Vista 64-bit code signing: “windows
> can’t verify the publisher of this driver”
>
> Jan Bottorff wrote:
> > Lert me ask a few questions. Are you signing the .sys binary or the
> > .cat fle? Or both? They are totally different signatures.
> >
> > During driver installation, you need the .cat signed. On Vista/W2K8
> > x64, you also need the binary signed.
>
> This is not quite correct. The .cat signature is all you
> need in every case except one: an x64 driver that is used by
> the boot loader must have the signature embedded in the
> driver binary. That’s the only exception. For all other
> drivers, the .cat signature is sufficient.
>
>
> > On Vista x64 the expected behaivor would be: the first time you
> > install a driver with your Authenticode signature a dialog
> will come
> > up, and it will have an option to “always trust drivers
> from xxx”. To
> > prevent this, you need either a) a WHQL signature, b) the the
> > Authenticode cerificate already installed as I believe a trusted
> > publisher. I belive you can get option B to happen via a
> network doman
> > group policy, so all machines that are domain members will trust
> > drivers from that company.You also can add the publisher
> certificate
> > on first install, and then laters installs of that device should be
> > silent.
>
> You’re talking about the “install time” behavior on all
> systems, not the
> x64 KMCS behavior. The x64 KMCS signature check happens
> every single time the driver is loaded. There are no easy
> policies to override that. You can either (1) attach a
> kernel debugger, (2) press F8 at boot time to turn it off, or
> (3) enable /testsign and install your certificate as a trusted root.
>
>
> > I’d have to verify if GlobalSign is a valid Authenticode
> certificate
> > provider, with installed roots.
>
> For KMCS, it doesn’t matter. There is only one valid root
> provider (Microsoft), and you must embed a cross-certificate
> that chains from your provider to Microsoft.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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
>


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

It does waste space though on the whole. Given that all binaries shipping with the OS are signed, I suspect that the savings for using cat files are in the hundreds of megabytes given the size of the cert part of the blob.

Granted, for the third party case, the ratio of binaries to unique certs is much higher. But there is a sensible reason for the idea.

  • S

-----Original Message-----
From: xxxxx@osr.com
Sent: Tuesday, March 17, 2009 13:10
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista 64-bit code signing: “windows can’t verify the publisher of this driver”

Tim’s right. You REALLY only NEED to sign the .SYS file for boot start drivers on x64. And you ALWAYS need to sign the .CAT file

OTOH, it never HURTS to sign both. So, in trying to explain this to people, our message has been “just sign everything, all the time.”

And, you’re completely right Jan: The whole KMCS/integrity thing is different from WHQL signing. A signature from WHQL will be sufficient for both install and KMCS purposes, but a 3rd party authenticode signature may be only sufficient for KMCS purposes (depending on the device category).

It’s all so confusing. It makes me happy I don’t do “real” installation procedures for products,

Peter
OSR


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

I signed driver referring to “Kernel-Mode Code Signing Walkthrough”,
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx, it
works fine under Srv2008/Vista 64bits.
Hope following tips can help you.

* make sure your OS time is correct when you sign your cat file.
* use bcdedit to set TESTSIGNING on in your 64bit system.
* Installing your certificate in your system, for example:
certmgr.exe /add aaa.cer /s /r localMachine root
certmgr.exe /add aaa.cer /s /r localMachine trustedpublisher

Thanks
Annie

Tim Green wrote:

So, can anyone explain why using “CopyINF” fails on Vista 64 if the
driver to be copied does not have a signed .SYS file?

Driver A copies driver B. Driver B can be installed by Found New
Hardware Wizard and by difx, and used in the usual way, on Vista 64
without any problems. What is different about CopyINF?

I have also seen this behaviour.

It looked to me as though CopyINF was not copying and installing the
catalog file associated with the referenced INF file. Adding a CopyINF
directive to DriverA.inf referencing DriverB.inf, meant that when
installing DriverA DriverB.inf and all files referenced by CopyFiles
directives in DriverB.inf were copied correctly, but it looked like the
catlog referenced by the CatalogFile directive in DriverB.inf was not
copied /installed/registered. Therefore when the system subsequently
tries to install DriverB on a device it can’t find the associated
catalog file and treats the driver as unsigned. If DriverB’s binaries
are signed directly it doesn’t need to check the catalog file referenced
in DriverB.inf and therefore it works…

I’d say it is a bug in the implementation of CopyINF.

Best regards,

Andrew


Andrew Lee Solarflare Communications
mailto:xxxxx@solarflare.com http://www.solarflare.com/

Wanted to answer some questions raised in this thread. All of the information in this pertains to Vista and greater. Older versions of the OS do not behave this way.

First, there is a cross-certificate available for GlobalSign. If the catalog file is being properly signed and cross-signed with the GlocalSign cert and cross-cert, there should not be any issues with Kernel mode code signing (KMCS).

Next, some info about KMCS: The KMCS checks are done when the driver is loaded. Microsoft uses the term “embedded signing” to mean that the driver binaries are signed directly - as opposed to “catalog signing”. KMCS does not REQUIRE “embedded signing”, however there is a *significant* performance penalty at boot time if boot drivers do not have “embedded signing” - this is true for both X86 and x64 systems. Therefore, Microsoft strongly recommends that drivers have “embedded signing” with certificate and cross-certificate on all drivers. WHQL does not provide embedded signing of driver packages - they only provide a signature of the catalog file. So embedded signing must be done by the customer - I believe WHQL has a Logo test in place to validate this.

For driver installation:

  1. Driver installation ONLY uses the catalog file. Embedded signatures will not affect the behavior of the pop-ups.
  2. Cross-certificates are REQUIRED for KMCS signing, but don’t mean anything for driver installation. Cross signing will not affect the behavior of the pop-ups.
  3. An unsigned driver OR a driver that is signed with a certificate that does not “root” to a certificate in the local computer Trusted Root store will result in the dialog with an ERROR that the driver is not signed.
  4. A driver that is signed with a certificate that “roots” to a certificate in the local computer Trusted Root store (one from an approved CA) will result in the “unknown publisher” WARNING dialog, unless the signing cert used to sign the catalog is in the local computer Trusted Publisher store.
  5. You will not see a dialog during installation if:
    a. The catalog file has a Windows signature (THis is for ALL OS versions)
    b. The catalog file has a WHQL signature (This is for ALL OS versions)
    c. The catalog file is signed with a certificate that was issued by a Trusted Root CA AND the certificate is in the local machine Trusted Publisher store. (This is for VISTA and newer.)

Hope this helps. As I said, this is Vista and newer. Prior to Vista, there was no KMCS in the code, so the cross-certificates don’t mean ANYTHING prior to Vista.

>During driver installation, you need the .cat signed. On Vista/W2K8 x64, you also need the binary

signed.

Not so.

There are 2 kinds of signing:

a) KMCS:

  • Vista+ x64 only
  • you can sign the binary OR the .cat
  • checked on load, the driver will not be loaded if there are signature issues
  • to obtain this, you must have a code signing cert from Verisign or such and apply this cert

b) WHQL signing

  • any Windows from w2k up
  • you must sign the .cat
  • check on PnP install (during INF file execution)
  • lack of signature causes the extra message boxes during install and also Device Manager telling that the driver is not signed
  • to obtain this, the driver must be tested by DTM and then a WHQL submission must be done to MS

Surely the OP has KMCS OK, and issues with lack of WHQL signing.


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

> My understanding is (unless you are in a special debugging/test mode) that

EVERY x64 driver on Vista/W2K8 will need an embedded signature, no matter
when it starts.

The signature can be in a .cat, except for boot-start drivers.


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

Jennifer,

Very helpful post, thanks.

A couple of questions:

There is a *significant* performance penalty on x86 systems if boot-start drivers are not “embedded signed”?? REALLY? This is the first time I’ve heard of this… why does the OS check for signatures at boot on x86, when it just ignores them? What am I missing?

Hmmm… (a) Why in the world doesn’t WHQL sign the .SYS file? Wouldn’t that be a good thing? (b) You’re saying that for a driver to be logo’ed, the .SYS file MUST be signed? THAT’s something I haven’t heard before and is very interesting. This would mean that to logo my driver, I have to figure out the driver signing process in any case… I can’t just submit my driver to WHQL and “let them take care of it.”

Peter
OSR

> [quote]
> KMCS does not REQUIRE “embedded signing”, however there is a *significant* performance penalty
at boot time if boot drivers do not have “embedded signing” - this is true for both X86 and x64 systems
> [/quote]

I don’t know who is right, but this would seem to contradict what the kmcs_walkthrough.doc reports:

• Boot-start drivers.
>In the special case of boot-start drivers—drivers that are loaded by the Windows Vista operating
>system loader—publishers must use an SPC to embedded-sign the driver binary image file. This
>requirement ensures optimal system boot performance.

mm

xxxxx@osr.com wrote:

Jennifer,

Very helpful post, thanks.

A couple of questions:

There is a *significant* performance penalty on x86 systems if boot-start drivers are not “embedded signed”?? REALLY? This is the first time I’ve heard of this… why does the OS check for signatures at boot on x86, when it just ignores them? What am I missing?

Hmmm… (a) Why in the world doesn’t WHQL sign the .SYS file? Wouldn’t that be a good thing? (b) You’re saying that for a driver to be logo’ed, the .SYS file MUST be signed? THAT’s something I haven’t heard before and is very interesting. This would mean that to logo my driver, I have to figure out the driver signing process in any case… I can’t just submit my driver to WHQL and “let them take care of it.”

Peter
OSR

First, thanks everybody for your input! I guess this is a topic of interest for many. To answer some questons:

-This is not a boot start driver
-I have signed ONLY the .cat file, and not the individual binaries.
-This question is not about KMCS, because the kernel appears to accept my signatures, and the drivers load and execute just fine. This question is only about installation popups
-This question is only about installation on a machine whose certificate store has not been modified in any way from factory-fresh Vista install.

Jennifer: your post was very informative. I have a few clarification questions:

  1. A driver that is signed with a certificate that “roots” to a certificate in
    the local computer Trusted Root store (one from an approved CA) will result in
    the “unknown publisher” WARNING dialog, unless the signing cert used to sign the
    catalog is in the local computer Trusted Publisher store.

This appears to be my exact situation. My certificate roots to a Global Sign Root CA. My test machines have no certificates in the Trusted Publisher store.

QUESTION 1: Is this the WARNING dialog you are referring to?:
“Windows can’t verify the publisher of this drivers software”
See details… "The driver software you’re attempting to install does not have a valid digital signature that verifies who published it… ".

This statement is confusing/misleading, because the GlobalSign certificate chain does verify who published the software. It does not necessarily mean that Microsoft has done any WHQL testing, and the warning message should state that the quality of the drivers can’t be verified.

QUESTION 2: Under the Driver tab, it says “Digital Signer: Not digitally signed”
Is this because the driver is not Windows/WHQL signed? Or is there a problem with my .cat signature?

QUESTION 3: Under the Driver tab… Driver details…, each file (including the WdfCoInstaller01007.dll) says “Digital Signer: Not digitally signed”.
Is this because the driver is not Windows/WHQL signed? Or will this go away if I just sign each binary with my signature?

Thanks,
Jonah

>> It’s all so confusing. It makes me happy I don’t do “real” installation

> procedures for products,
>
> Peter
> OSR

Peter, would you mind giving a brief description of the installation procedure that you prefer? (with a focus on: XP, Vista, Vista x64)

Prior to the Vista, I was inclined to manually copy all driver files to the proper Windows system directories (\windows\inf, \windows\system32\drivers, \windows\system32). When the USB device is plugged in, if the user selects the option of “Automatically find the drivers”, both XP and Vista would discover them if the inf was written properly.

Is that the process you refer to? Or is it something else, such as using DPInst or IFxApp, or DevCon, or other?

Thanks,
Jonah

Aside from the smallest, hacked-up, engineering-level, crappy minimum necessary to get a driver installed for testing, I don’t do any installation procedures at all. So, for USB let’s say, I hack together some re-used junky .INF file, copy it to c:\Junk along with the .sys file, and plug the device in… then point the installer to the directory.

Ugly, but my only need is to get things installed for development and testing.

I also use DevCon a fair bit… one of the world’s greatest utilities, I think.

Peter
OSR


DevCon a fair bit… one of the world’s greatest utilities

Hear Hear!

Too bad the INetCfg swiss-army-knife equivalent SNETCFG.EXE got retired in
favor of BindView. Between devcon and snetcfg I have been able to avoid
creating installers of any sort for almost all development work. And don’t
forget SC.EXE to pull out those left-over PnP driver service entries!

There is something to be said for “simply works”.

And hardly ugly…

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, March 20, 2009 10:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista 64-bit code signing: “windows can’t verify the
publisher of this driver”

Aside from the smallest, hacked-up, engineering-level, crappy minimum
necessary to get a driver installed for testing, I don’t do any installation
procedures at all. So, for USB let’s say, I hack together some re-used
junky .INF file, copy it to c:\Junk along with the .sys file, and plug the
device in… then point the installer to the directory.

Ugly, but my only need is to get things installed for development and
testing.

I also use DevCon a fair bit… one of the world’s greatest utilities, I
think.

Peter
OSR


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

Ugly? No, that would be a setup driven by, say, xml configuration files.

mm

David R. Cattley wrote:


> DevCon a fair bit… one of the world’s greatest utilities
>

Hear Hear!

Too bad the INetCfg swiss-army-knife equivalent SNETCFG.EXE got retired in
favor of BindView. Between devcon and snetcfg I have been able to avoid
creating installers of any sort for almost all development work. And don’t
forget SC.EXE to pull out those left-over PnP driver service entries!

There is something to be said for “simply works”.

And hardly ugly…

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, March 20, 2009 10:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista 64-bit code signing: “windows can’t verify the
publisher of this driver”

Aside from the smallest, hacked-up, engineering-level, crappy minimum
necessary to get a driver installed for testing, I don’t do any installation
procedures at all. So, for USB let’s say, I hack together some re-used
junky .INF file, copy it to c:\Junk along with the .sys file, and plug the
device in… then point the installer to the directory.

Ugly, but my only need is to get things installed for development and
testing.

I also use DevCon a fair bit… one of the world’s greatest utilities, I
think.

Peter
OSR


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

To answer Peter’s questions: Yes, it checks for signatures on x86 drivers at boot, and then ignores them if they are missing. Can’t say why - but that is the behavior. We’ve spent a lot of time with the OEMs making sure they have signatures on all their boot loaded drivers.

WHQL is checking for the signature on the .sys file precisely because of the boot performance issue. (At least I *think* they added this test - I’m not as close to this issue as I use to be :slight_smile: Why don’t they sign it themselves? They don’t have the infrastructure in place. I believe this is in the SYSTEM logo tests, not the individual device logo tests. So, an IHV could get the logo, then added the embedded signatures to the binaries before handing them off to the OEMs to add to their systems.

MM: No contradiction. The KMCS walkthrough says “This requirement ensures optimal system boot performance.” Not, “This is required to boot.”

Jonah:

  1. I think the dialog you are seeing is the “unsigned” Error dialog, not the warning dialog. When I look in the local computer Trusted Root store on my Vista machine, I don’t see a cert from Global Sign. Use MMC.exe - install the certificates plug in for the Computer Account - it will show up as Local Computer. And then look in the Trusted Root Certificate Authorities folder, certificates. Is the certificate there that your signing cert has as it’s root? (To find that, right click on a catalog file or .sys file that you have signed, go to properties, select the Digital Signatures Tab. Select the item from the signature list and click details. On the Digital signatures details dialog, do you see a message that says “A certificate chain processed, but terminated in a root certificate that is not trusted by the trust provider”? Alternative, what do you get if you do:
    “signtool verify /v /pa .cat”

    2. It should be looking at the signature on the catalog file and showing the signature, IF it is a “valid” signature. If you had a problem with #1, you’ll have a problem here.

    3. That is a bug in that dialog. You should ignore it.

Jennifer:

I’m confused - it uses the words ‘must’ and ‘requirement.’

In the special case of boot-start drivers—drivers that are loaded by the Windows Vista operating
>system loader—publishers MUST use an SPC to embedded-sign the driver binary image file. This
>REQUIREMENT ensures optimal system boot performance.

mm

xxxxx@microsoft.com wrote:

To answer Peter’s questions: Yes, it checks for signatures on x86 drivers at boot, and then ignores them if they are missing. Can’t say why - but that is the behavior. We’ve spent a lot of time with the OEMs making sure they have signatures on all their boot loaded drivers.

WHQL is checking for the signature on the .sys file precisely because of the boot performance issue. (At least I *think* they added this test - I’m not as close to this issue as I use to be :slight_smile: Why don’t they sign it themselves? They don’t have the infrastructure in place. I believe this is in the SYSTEM logo tests, not the individual device logo tests. So, an IHV could get the logo, then added the embedded signatures to the binaries before handing them off to the OEMs to add to their systems.

MM: No contradiction. The KMCS walkthrough says “This requirement ensures optimal system boot performance.” Not, “This is required to boot.”

Jonah:

  1. I think the dialog you are seeing is the “unsigned” Error dialog, not the warning dialog. When I look in the local computer Trusted Root store on my Vista machine, I don’t see a cert from Global Sign. Use MMC.exe - install the certificates plug in for the Computer Account - it will show up as Local Computer. And then look in the Trusted Root Certificate Authorities folder, certificates. Is the certificate there that your signing cert has as it’s root? (To find that, right click on a catalog file or .sys file that you have signed, go to properties, select the Digital Signatures Tab. Select the item from the signature list and click details. On the Digital signatures details dialog, do you see a message that says “A certificate chain processed, but terminated in a root certificate that is not trusted by the trust provider”? Alternative, what do you get if you do:
    “signtool verify /v /pa .cat”
    >
    > 2. It should be looking at the signature on the catalog file and showing the signature, IF it is a “valid” signature. If you had a problem with #1, you’ll have a problem here.
    >
    > 3. That is a bug in that dialog. You should ignore it.
    >
    >

MM - think of this the way you think of a Logo requirement…

Jennifer, thanks again for your help! But please note:

> Jonah:
> 1. I think the dialog you are seeing is the “unsigned” Error dialog, not the
> warning dialog. When I look in the local computer Trusted Root store on my
> Vista machine, I don’t see a cert from Global Sign. Use MMC.exe - install the
> certificates plug in for the Computer Account - it will show up as Local
> Computer. And then look in the Trusted Root Certificate Authorities folder,
> certificates. Is the certificate there that your signing cert has as it’s root?

Yes, there is a “GlobalSign”, and two “GlobalSign Root CA” certificates, all 3 of those are under Trusted Root Certificate Authorities on both my XP Pro machine and Vista64 machine.

> (To find that, right click on a catalog file or .sys file that you have signed,
> go to properties, select the Digital Signatures Tab. Select the item from the
> signature list and click details. On the Digital signatures details dialog, do
> you see a message that says “A certificate chain processed, but terminated in a
> root certificate that is not trusted by the trust provider”?

On the .cat file’s “Digital Signatures” tab, clicking on the item in the Signature List, it says “This digital signature is OK”. No error message like you state on any of the sub-dialogs.

> Alternative, what
> do you get if you do:
> “signtool verify /v /pa .cat”

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Despite all this, during install, I still see what you believe is an Error message (as opposed to Warning message). If you could clarify exactly what the Error message and Warning message each say, that would be helpful.

Thanks!
Jonah