Authenticode signing, boot drivers, vendor certificate

NTDEV
1

Hello

I got a question regarding the signing of x64 boot drivers and their loading on post-Vista x64 systems:

When we install our boot drivers, user can select to trust the publisher (“always trust”) and ?install?, then our vendor certificate will *automatically* be imported into system and stay there forever, our boot drivers will work correctly; The user might also not select to “always trust” our vendor certificate, but install our drivers all the same.

I want to understand :
If the user installs but does not “always trust”, then the drivers install correctly while in the installation process (we have our own application to install our drivers), but then, on boot, they won’t load?
This seems weird to me.
The system is able to know that the drivers are boot drivers (it’s in the inf file) and then that if the user don’t select to “always trust”, the driver will never load!
I’d like to make sure that I understood correctly

Thanks in advance

2

You should refuse to install on win7 x64 in that case. Yes it does
seem odd that the system will allow the install when doing so will
result in an unbootable system.

Mark Roddy

On Fri, Oct 15, 2010 at 8:05 AM, wrote:
> Hello
>
>
> I got a question regarding the signing of x64 boot drivers and their loading on post-Vista x64 systems:
>
> When we install our boot drivers, user can select to trust the publisher (“always trust”) and ?install?, then our vendor certificate will automatically be imported into system and stay there forever, our boot drivers will work correctly; The user might also not select to “always trust” our vendor certificate, but install our drivers all the same.
>
> I want to understand :
> If the user installs but does not “always trust”, then the drivers install correctly while in the installation process (we have our own application to install our drivers), but then, on boot, they won’t load?
> This seems weird to me.
> The system is able to know that the drivers are boot drivers (it’s in the inf file) and then that if the user don’t select to “always trust”, the driver will never load!
> I’d like to make sure that I understood correctly
>
> Thanks in advance
>
>
> —
> 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
>

3

> If the user installs but does not “always trust”, then the drivers install correctly while in the installation

process (we have our own application to install our drivers), but then, on boot, they won’t load?

Not so.

KMCS is not bypassable by “Do you trust” dialog box. So, KMCS signature is a must, and yes, for boot driver, it must be in .sys itself.

But KMCS does not require WinQual logo, so, just buy a cert for the company and you’re OK.

As about PnP signing - which is absolutely separate from KMCS - it is only invoked (on Vista+ and I think 2003 too) when copying the driver package to the Driver Store (SetupCopyOEMInf). After the driver is in the Store, PnP signing is never invoked anymore.

So, when you say “yes” in “Do you trust” box, this allows the package to be copied to Driver Store, after which it will not only be loadable, but silently re-installable for the new devnodes, or for the same devnode if you have deleted it in the Device Manager and then re-created it again.

And, if you say “Always trust”, then the cert is also placed to Trusted Publishers of Local Machine. You can do this manually and thus avoid the “Do you trust” box at all. This means that all subsequent driver packages signed by the same cert will be silently installable.

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

4

@Maxim:
We do have a cert for signing our boot drivers
We do sign the .sys, using our cert.
Our drivers are Boot drivers (kernel code then) and use PnP functions and follow the WDM model. I mention this because I am not sure I understand the difference you make between Kernel drivers and PnP drivers.

My question was: If the user does not “always trust” our cert, will the boot drivers, which have been signed etc, still be loaded, (as long as they have been installed successfully)?

It’s a pity for me that I can’t test these cases by myself as my current job involves more power-point and planning than developing and testing…

5

Please check your driver binary signature chain from a WDK command line with

certmgr .sys

If the “Microsoft Code Vertification Root” cross-certificate for your
certificate provider was not included in the “embedded signature” block
- Win7/x64 will happily install the driver,
- but then the device will be disabled.

Note: You can place the missing certificates in a trusted cert store on
the machine, this then works (and is very likely what you observe).

In our case the problem was caused during code-signing:
Signtool.exe used a longer-living CA certificate without a matching
cross-cert for it. So it also did not include the cross-cert in the
embedded signature.
The problem only became apparent on a non-development Win7/x64 machine.

Solution: (1) After deleting the “newer” Root CA certificate and that of
an intermediate Publishing Entity (and keeping the “older ones” where
thec ross-cert matched to), the whole certificate chain was successfully
included. (2) Long-term solution: get a new cross-cert.

6

> If the user installs but does not “always trust”, then the drivers

install correctly while in the installation process (we have our own
application to install our drivers), but then, on boot, they won’t
load?

Boot-time drivers need a proper embedded signature, then they will not
need the “always trust this publisher” box checked during install.
DRM-relevant drivers may even need an additional signature.

Please see my other post about how to verify this.

And yes, our driver also installed properly (no error), but then on
Win7/x64 driver load failed. For a non-boot driver. Very annoying.

7

wrote in message news:xxxxx@ntdev…
…
> My question was: If the user does not “always trust” our cert, will the
> boot drivers, which have been signed etc, still be loaded, (as long as
> they have been installed successfully)?
>

Then as you’ve been told, you got a problem. The driver will install but
fail on start.

A possible workaround is to install the cert before the driver, in your
setup program.
First, ensure that your cert is already installed, only then install the
driver.
Think of a recovery plan in case ingenious user deletes the cert later :slight_smile:
– pa

8

This has been said a few times in this thread, but I’m pretty sure that it’s not correct. The answer to the original question is “Yes, they will continue to be loaded if installed successfully”.

This has been my understanding:

Whether or not the USER trusts you controls whether your binaries ever get copied, placed, and stored- i.e., whether you get installed or not.
Whether or not the OS trusts you controls whether or not you load.

The OS trusting you depends upon the certificate being valid (not the same as trusted) and chaining to a root the OS trusts (which I believe is why you need the MSFT cross-certs).

They only have to trust you once to install the driver. The OS will continue to trust (hence load) the driver (assuming it passed trustworthiness the first time) until you do something to invalidate the signature.

I happen to have a third-party Authenticode-signed driver package on my dev machine (for a multiport serial card). I checked before I sent this by removing the certificate from trusted publishers store, and AFAICT, it works this way.

-----Original Message-----
From: Pavel A.
Sent: Monday, October 18, 2010 4:49 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Authenticode signing, boot drivers, vendor certificate

wrote in message news:xxxxx@ntdev…
…
> My question was: If the user does not “always trust” our cert, will
> the boot drivers, which have been signed etc, still be loaded, (as
> long as they have been installed successfully)?
>

Then as you’ve been told, you got a problem. The driver will install but fail on start.

A possible workaround is to install the cert before the driver, in your setup program.
First, ensure that your cert is already installed, only then install the driver.
Think of a recovery plan in case ingenious user deletes the cert later :slight_smile:
– pa

9

> Then as you’ve been told, you got a problem. The driver will install but

fail on start.

A possible workaround is to install the cert before the driver, in your
setup program.
First, ensure that your cert is already installed, only then install the
driver.
Think of a recovery plan in case ingenious user deletes the cert later :slight_smile:
– pa

Absolutely not so with KMCS.

Any properly cross-signed driver will pass KMCS, it ignores whether the cert is in Trusted Publishers or not so.

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

10

Maxim wrote:

Absolutely not so with KMCS.

Any properly cross-signed driver will pass KMCS, it ignores whether the cert is in Trusted Publishers or not so.

Max is exactly right. The “Trusted Publishers” thing is only relevant for PnP driver INSTALLATION. It is not involved with driver LOADING.

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

11

>Max is exactly right. The “Trusted Publishers” thing is only relevant for PnP driver INSTALLATION.

And this “installation” is SetupCopyOEMInf, which copies the package to the Driver Store.

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

12

>

> Then as you’ve been told, you got a problem. The driver will install
but
> fail on start.
>
> A possible workaround is to install the cert before the driver, in
your
> setup program.
> First, ensure that your cert is already installed, only then install
the
> driver.
> Think of a recovery plan in case ingenious user deletes the cert
later :slight_smile:
> – pa

Absolutely not so with KMCS.

Any properly cross-signed driver will pass KMCS, it ignores whether
the cert
is in Trusted Publishers or not so.

In fact it’s even worse than that because the user will think the driver
installed correctly (there were no warnings afterall), and the system
will crash and burn next boot if it was a critical driver.

James

13

On 10/19/2010 3:08 AM, Bob Kjelgaard wrote:

This has been said a few times in this thread, but I’m pretty sure
that it’s not correct. The answer to the original question is “Yes,
they will continue to be loaded if installed successfully”.

Sorry, Bob, but no:
A newly-signed version of our driver did successfully install on
Win7/64bit, but it did not LOAD when our device was attached.

Symptom: In device manager, a small yellow triangle with an exclamation
mark showed up next to the driver icon.
The property information stated something like “driver not loaded
because no trust chain could be established”.

The driver is a BulkUSB derived plain USB driver (WDM).

The culprit was a missing cross-certificate in the *.sys file. And the
cross-cert was missing because Signtool.exe did not put it in there,
because it used the newer one of two intermediate certificates.

If you don’t believe me, let’s take this offline and I’ll provide you
with anything I have, so you can verify the issue yourself.

Note: you can *not* verify it on any 32bit machine. Neither on WinXP nor
on Win7/32bit. It must be Win7/64bit.

14

> A newly-signed version of our driver did successfully install on

Win7/64bit, but it did not LOAD when our device was attached.

And what does the Security log say?

KMCS validation failures are logged. More so, they are even logged on x86 OSes where they do not fail the driver load.

The culprit was a missing cross-certificate in the *.sys file.

Then you have a bug in KMCS signing procedure. It’s correct that such a bug will produce such a result.

The original question was on “can the lack of the cert in Trusted Publishers cause driver load failure?”.

And the answer is: “no, it can’t, since the Trusted Publishers store is not used in KMCS validation procedure at all”. Only your signature and embedded cross-cert are used.

Note: you can *not* verify it on any 32bit machine.

Try looking at Security log. KMCS failures are logged there on x86 Vista+ OSes, though the driver is actually loaded.

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

15

Silly silly me :frowning:

But can you promise that this is not an implementation detail, and it
will not change on the next patch Tuesday?

Having a signed driver loaded, when its signer is not trusted by
the cert store (or other “well known” policy source), is strange.
Even if the OS kernel itself lets it load, a 3rd party AV may block it?
– pa

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
> This has been said a few times in this thread, but I’m pretty sure that
> it’s not correct. The answer to the original question is “Yes, they will
> continue to be loaded if installed successfully”.
>
> This has been my understanding:
>
> Whether or not the USER trusts you controls whether your binaries ever get
> copied, placed, and stored- i.e., whether you get installed or not.
> Whether or not the OS trusts you controls whether or not you load.
>
> The OS trusting you depends upon the certificate being valid (not the same
> as trusted) and chaining to a root the OS trusts (which I believe is why
> you need the MSFT cross-certs).
>
> They only have to trust you once to install the driver. The OS will
> continue to trust (hence load) the driver (assuming it passed
> trustworthiness the first time) until you do something to invalidate the
> signature.
>
> I happen to have a third-party Authenticode-signed driver package on my
> dev machine (for a multiport serial card). I checked before I sent this
> by removing the certificate from trusted publishers store, and AFAICT, it
> works this way.
>
> -----Original Message-----
> From: Pavel A.
> Sent: Monday, October 18, 2010 4:49 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] Authenticode signing, boot drivers, vendor certificate
>
> wrote in message news:xxxxx@ntdev…
> …
>> My question was: If the user does not “always trust” our cert, will
>> the boot drivers, which have been signed etc, still be loaded, (as
>> long as they have been installed successfully)?
>>
>
> Then as you’ve been told, you got a problem. The driver will install but
> fail on start.
>
> A possible workaround is to install the cert before the driver, in your
> setup program.
> First, ensure that your cert is already installed, only then install the
> driver.
> Think of a recovery plan in case ingenious user deletes the cert later :slight_smile:
> – pa
>

16

>> The culprit was a missing cross-certificate in the *.sys file.

On 10/19/2010 6:56 PM, Maxim S. Shatskih wrote:

Then you have a bug in KMCS signing procedure. It’s correct that such a bug will produce such a result.

The bug is actually in the tool, not in the procedure. The procedure
worked before (and it still works, if I replace the cross-cert or delete
the “newer” intermediate certificates). IMHO much worse is that I don’t
get an error message on the machine that does the signing:

Apart from the fact that it uses the wrong cert (not the one that links
to the cross-cert, but the one that “lives” longer), even a “signtool
verify /kp” reports no error if the MSCV Root cross-certificate is
missing. But (later) “driver load” fails on a Win7/64bit machine.

N.B.: VeriSign recently rolled out new top-level CA certs.
For these, the matching MSCV root cross-cert needs to be available and
manually configured to be used for the signing process.
If this is not done, signtool.exe will still chain to these certs.
(Even if an older CA cert is available that would chain to the
available/present MSCV root cert, signtool will not use that chain.)
=> Everything will sign, install and sign-verify fine.
=> Later then “in the field”, driver load will fail on Win*/64bit.

Well, the problem will be fixed eventually… :slight_smile:

17

On 10/19/2010 3:08 AM, Bob Kjelgaard wrote:

The OS trusting you depends upon the certificate being valid ([…])
and chaining to a root the OS trusts (which I believe is why you need
the MSFT cross-certs).

Exactly. The problem I described is caused by the trust chain not be
built (completely) by signtool.exe in specific circumstances.

Note: I consider these postings as one way of reporting the issue.
(My boss would ask funny questions about the upfront payment if I wanted
to open an incident to report something we got sorted out locally.)

18

Back to the original question.
I could, few minutes ago, make a test on some x64 system (Win7).
I removed the “trusted” certificate from the store (from Trusted Publishers).
And my boot drivers (Start=0) could still load.

Thanks for all of you who participated to this thread for sharing your knowledge with us.