Driver signing

Hi there

Let's see if someone could help me
I'm Developing a data acquisition system that sends the acquired data to the
PC via USB. Its working OK, but I have problems with the driver signing in
x64-based Windows.

I have read several info in Microsoft, and for what I have understood, there
are two way to sign the drivers. One way is performing the actions needed to
sign it via the WHQL (basically perform a test and submit the results in
Winqual). The other way is to sign it as a SPC (for which I need to obtain a
SPC from a Certificate Authority and sign the driver catalog).

Now the matter of the question:
Does anyone know which way should I take?
Which are the pros and cons of each way?

In the case of the WHQL: Which WLP category corresponds to the device?

Regards,
Seb

> PC via USB. Its working OK, but I have problems with the driver signing in
> x64-based Windows.

There are 2 100% different signing procedures.

1) PnP signing.

OS versions: from w2k up.
What is signed: the .cat file (it describes the whole PnP driver package)
When the signature is checked: at PnP package install (I think in SetupCopyOEMInf, which can be called by some higher-level functions).
Signature issues cause: red or yellow error message box "Do you trust this software?" or "Not digitally signed".
Can be bypassed by: installing the cert to Trusted Publishers (not on XP I think)
Eligible certs: for the full power of this, only WHQL. You can also use your cert, any one signed by a known trusted root, but you will need to install it to Trusted Publishers on the machine manually, OR to have a yellow box of "Do you trust the software from this company"?

WHQL uses the above described signing. IIRC the WHQL signed driver is signed by "Microsoft Windows Publisher" or something like, though keeping your company name in version info resource.

WHQL-signed drivers always install silently, non-WHQL-signed require the cert to be in Trusted Publishers for such.

2) KMCS

OS versions: Vista+ x64
What is signed: the .cat file or the .sys file, for boot-start driver, ..sys MUST be signed.
When the signature is checked: at driver binary load. It is also checked on x86 Vista+ OSes, but just logs the failure event to the Security log.
Signature issues cause: driver binary load failure (for a boot driver, can fail the whole boot - ".sys file is corrupt" or such) or (on x86 OSes) - Security log event.
Can be bypassed by:
F8 on boot, and "Disable Driver Signature Enforcement" from the Safe Mode text menu (white on black BIOS-mode text).
OR
"set testsigning on"+signing with a test cert+attaching a debugger.
Eligible certs: ONLY the corporate certs from a short list of trusted roots (Verisign and GlobalSign are there), MUST be used with MS's cross-cert for this root (to check the signature at boot where the cert stores with trusted roots are not booted yet).

You can use both signing methods - sign the .sys with KMCS and then the whole package with PnP signing (or send to WHQL to sign).

Also I've heard that there are protected (undebuggable) processes within Windows, like the audio server process, and any DLLs which are loaded there (like some global APOs or such) must be signed the same way as kmode .sys files.

The main purpose of KMCS is DRM, the main purpose of PnP signing is to enforce WHQL.

--
Maxim S. Shatskih
Windows DDK MVP

http://www.storagecraft.com

Seb <> wrote:
>
>I'm Developing a data acquisition system that sends the acquired data to the
>PC via USB. Its working OK, but I have problems with the driver signing in
>x64-based Windows.
>...
>In the case of the WHQL: Which WLP category corresponds to the device?

You'll have to go unclassified.
--
Tim Roberts,
Providenza & Boekelheide, Inc.