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

This has come up before on NTDEV and other newsgroups, but the answers are
conflicting. I’m hoping for a more authoritative answer.
I have obtained an SPC from GlobalSign and am attempting to sign a KMDF
driver by following the MSFT “Kernel-Mode Code Signing Walkthrough”, using
inf2cat and signtool exactly as specified in the example. All procedures
succeed, and I am able to “signtool verify” successfully.

Installation on the Target machine goes fine, but during installation there
is a popup dialog “Windows can’t verify the publisher of this driver”. And
looking at the Driver tab under Device Manager shows “Not digitally signed”
for the driver (as well as for each file under “Driver Details”).
Curiously, even the WdfCoInstaller says it is Not Signed, although I would
have expected MSFT to sign the binary itself.

Some prior posts on NTDEV suggest that unless you go through Winqual and get
a signature from MSFT, then these messages will always popup. However,
other posts suggest that some people have managed to not get this particular
popup after signing drivers (or some claim a popup at least shows the
correct Publisher name, which I have not seen with my signed drivers)

So is there mistake in my signing process? Or is it always normal for Vista
64 to raise this dialog on even signed drivers, if they do not have a
Winqual signature?

Thanks,
Jonah

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.

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.

I’d have to verify if GlobalSign is a valid Authenticode certificate
provider, with installed roots.

On W2K3, there is no way to make an Authenticode signature work like a WHQL
signature, although maybe on devices in a custom device class you can.

Jan


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jonah Peskin
Sent: Monday, March 16, 2009 9:47 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Vista 64-bit code signing: “windows can’t verify the
publisher of this driver”

This has come up before on NTDEV and other newsgroups, but the answers are
conflicting. I’m hoping for a more authoritative answer.

I have obtained an SPC from GlobalSign and am attempting to sign a KMDF
driver by following the MSFT “Kernel-Mode Code Signing Walkthrough”, using
inf2cat and signtool exactly as specified in the example. All procedures
succeed, and I am able to “signtool verify” successfully.

Installation on the Target machine goes fine, but during installation there
is a popup dialog “Windows can’t verify the publisher of this driver”. And
looking at the Driver tab under Device Manager shows “Not digitally signed”
for the driver (as well as for each file under “Driver Details”).
Curiously, even the WdfCoInstaller says it is Not Signed, although I would
have expected MSFT to sign the binary itself.

Some prior posts on NTDEV suggest that unless you go through Winqual and get
a signature from MSFT, then these messages will always popup. However,
other posts suggest that some people have managed to not get this particular
popup after signing drivers (or some claim a popup at least shows the
correct Publisher name, which I have not seen with my signed drivers)

So is there mistake in my signing process? Or is it always normal for Vista
64 to raise this dialog on even signed drivers, if they do not have a
Winqual signature?

Thanks,
Jonah
— 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

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.

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

Jan Bottorff wrote:

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

Probably. :wink:

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”.

Yes. When a driver loads on x64, if the binary does not have an
embedded signature, the system will go searching for the .cat file. The
reason they want boot-start binaries to have an embedded signature is to
avoid the performance hit of searching for the .cat file.

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?

That is what I am saying, yes. It’s more than a belief – I know this
for a fact, because I’ve done it. I sign the .cat file, and Vista x64
runs it. The Kernel Mode Code Signing white paper (kmsigning.doc) even
says this.

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.

Correct.

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.

Nope, this is not the case. As long as the binary is unchanged from the
one in the .cat file (they do a checksum), the binary does not have to
be signed as long as the .cat file is.


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

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

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

installation procedures for products,

Does anybody know if there is a COMPLETE and ACCURATE document/web page that
explains the EXACT requirements for signatures as related to drivers, across
all flavors of Windows and all scenarios? Probably some sort of flowchart,
that spells out little details like W2K3 must have WHQL signatures
(certified or unclassified) unless it’s a device in a custom class and you
install the correct certs in the correct cert store, except if you’re doing
unattended OS install in which case any class can install without signatures
(I think). There are little fragments of documentation that mention these
things, but know of no place that brings it all together.

Even though I’ve spent literally a month or two of the last few years
dealing with these kinds of issues, apparently I still am learning new
stuff. The ability of the kernel to use the .cat signature to validate an
unsigned binary of a reinstanciated device on x64 Vista/W2K is a little
shift in my understanding. It sounds like for optimal performance though, it
still might be better to put a signature on the binary, or do non-boot x64
driver loads always search for the .cat?

It’s very difficult for a driver developer to PLAN what would be needed to
give specific install behaviors on specific Windows versions.

Jan

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?

Tim Green.

-----Original Message-----
From: xxxxx@lists.osr.com on behalf of xxxxx@osr.com
Sent: Tue 17/03/2009 20:11
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

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