very simple question ....

NTDEV
1

I am running windows 8.1 preview on a standard HP laptop and on an Elitepad tablet (32bit for both)

We have a driver that went throught the WHQL process several months ago…it has been installed and used successfully on hundereds of occasions on a wide variety of platforms ( Vista, Win7, Win8, 32 bit, 64 bit ) …

On the HP LAPTOP running 8.1, when i load the driver it successfully loads and works as
However, on the Elitepad, when i try to load it i get the error …

C:\Users\Friday\Desktop>sc start mysdrv
[SC] StartService FAILED 577:

Windows cannot verify the digital signature for this file. A recent hardware or
software change might have installed a file that is signed incorrectly or damage
d, or that might be malicious software from an unknown source.

I thought that driver signing enforement only took place on 64 bit windows ??

Note that …

  • The identical driver on any other platform i’ve tried does not give this error

  • If i turn driver signing enforcement to OFF on the elitepad it works okay.

  • Other unsigned drivers are loaded and running ok on the elitepad

  • My driver is a file system filter driver, could that be significant ?

  • I have checked signatures etc using signtool …

Many thanks for any pointers…

Paolo

2

I think this device has UEFI firmware and secure boot. The driver needs to be KMCS signed on x86.

Good Luck,
Dave Cattley

3

Dave,

thanks for the reply. Re the KMCS, the 64 bit variant of our driver is signed in exactly the same way as the 32 bit variant i’m running on the elitepad and the 64 bit variants loads and runs fine on 64 bit windows 8.

My driver is WHQL’d and therefore does not, as i understand it, need to be KMCS signed with a cross-cert … (though i am confused about driver signing in general). The three ‘bits’ to my driver are the .inf file, the .cat file (signed by microsoft for WHQL) and the .sys file (signed using my company’s certificate to indicate we have produced the driver) … i install it via

c:\> rundll32.exe setupapi, INstallHinfSection DefaultInstall 128 c:\tmp\mydriver.inf

any more help gratefully received…

Paolo

4

> Re the KMCS, the 64 bit variant of our driver is signed in exactly the
same way as the 32 bit

And how exactly is that?

Are both binaries signed with your code signing certificate *and* the
corresponding cross certificate from MSFT that chains to your code signing
certificate issuer root?

In other words, do you include the /ac option when
signing?

Does signtool verify /kp /v yourdriver.sys report success and correctly
show your signature and the cross signature including timestamps?

Good Luck,
Dave Cattley

5

Hi Dave,

Both 32 and 64 bit “.sys” files are signed with our code signing certificate … they are not cross-signed. Running “signtool verify /kp /v yourdriver.sys” against the driver reveals no errors and shows the certificate chain up to root including our code signing cert (as i said, no cross cert).

We then send them off to Microsoft for WHQL (along with the .inf, .cat and test results).

Microsoft return to us a “.cat” file signed by “Microsoft Windows Hardware Compatability Publisher”.

We then install the driver via…

“rundll32.exe setupapi,InstallHinfSection DefaultInstall 128 OurDriver.inf”

Ever since Vista, this process has been sufficient for us to install and run both the 32bit and 64bit variants of our driver on the following…

  • Vista 32 and 64 bit
  • Win7 32 and 64 bit
  • WIn8 32 and 84 bit
  • Win8.1 32 and 64 bit

Only exception is, as original post says, windows 8.1 running on elitepad 32bit… even if UEFI/SecureBoot is enabled forcing signed driver checking, our driver should still pas these checks shouldn’t it ???

thanks,

Paolo

6

> Both 32 and 64 bit “.sys” files are signed with our code signing certificate … they are not cross-

signed.

And this is why the .sys is not loaded on UEFI Secure Boot.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

7

thanks Maxim,

…so, given that the 64 bit variant of our driver which is signed in exactly the same way ( ie NOT with a cross cert ) loads successfully on 64 bit vista, 64 bit win7, 64 bit win8 and 64 bitwin8.1, i can only assume that UEFI secure boot is the only KMCS checking mechanism that insists on cross signing ??
( seems a bit odd, surely it should be applying the same checks that the standard 64 bit windows KMCS enforcement does )…

thanks, Paolo

8

I strongly suggest you add the cross signature.

It is my non-scientific observation that Windows will use the cross signature only when other mechanisms are unavailable.

For example I did not initially replicate the load-failure-due-to-missing-cross-signature issue on UEFI x86 because my driver we indeed Authenticode signed as you do and when I ran NET START it would load and run just fine. It was not until I set my driver start to System and rebooted that I was able to observe that Windows refused to start the driver because of the lack of a cross signature.

I wish MSFT would publish a clear and definitive explanation of what actually happens vis-a-vi signature checking for kernel mode modules to satisfy our curiosities but in the end it will not change the fact that in all cases for all platforms and for all driver types there is not reason not to cross-sign the binary and clearly it is necessary for some scenarios on every platform.

Taking one from Nike: Just Do It.

Good Luck,
Dave Cattley

9

I know that the correct way for KMCS is to include the cross-cert.

If the cross-cert is not included, then it works (on pre-8 x64 OSes) by mere luck and there is no guarantees.

So, just include the cross-cert to be more correct. Many issues are automatically gone when you become “more correct”, and actually this is the usual first troubleshooting step.

Also note:

  1. x86 pre-8 OSes also do check KMCS and do log a failure event to Security log if the check failed. They do not refuse to boot or to load the .sys though, like the x64 OSes do. They only log an event.

Look at these events on other machines of yours.

  1. There is a difference between boot-start and non-boot-start driver in terms of KMCS.

For non-boot-start, the check is done with the whole certificate store (whose main branch is a subdir actually) already accessible, so, I would not be surprised that it will work without embedded cross-cert in the .sys.

For boot-start, the check is done by the boot loader when there is no loaded Windows OS yet, so, the cert store is not accessible and the check should be rather primitive. So, in this case, the requirement of embedded cross-cert can be really a must.

Also note that the Windows boot loader on UEFI is an UEFI app, and it can probably use some UEFI syscalls to do certs/signature checks.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> thanks Maxim,
>
> …so, given that the 64 bit variant of our driver which is signed in exactly the same way ( ie NOT with a cross cert ) loads successfully on 64 bit vista, 64 bit win7, 64 bit win8 and 64 bitwin8.1, i can only assume that UEFI secure boot is the only KMCS checking mechanism that insists on cross signing ??
> ( seems a bit odd, surely it should be applying the same checks that the standard 64 bit windows KMCS enforcement does )…
>
> thanks, Paolo
>