Driver signing for Win64

NTDEV
1

Hi

We have purchased a code signing certificate from GlobalSign.
There’s also a cross-certificate from Microsoft for GlobalSign,
I have imported both of them in my Windows 7 64. I sign my
driver, create a cat (Inf2cat) and sign this as well. However
another system with Windows 7 64 still won’t accept this to
install the driver (“…cannot verify the digital signature… Code 52”)

Sign the sys:
SignTool.exe sign /a /f company-certificate.pfx /p password /t http://timestamp.verisign.com/scripts/timestamp.dll /v “package\fre\amd64\e500v2.sys”
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: package\fre\amd64\e500v2.sys

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

Create catalog:
inf2cat.exe /driver:package\ /os:XP_X86,XP_X64,Vista_X86,Vista_X64,7_X86,7_X64 /v
Processing directory (package) file (e500v2.inf)
Processing directory (package) file (e500v2x64.cat)
Processing directory (package) file (e500v2x86.cat)
Processing directory (package\chk\amd64)file (e500v2.sys)
Processing directory (package\chk\i386) file (e500v2.sys)
Processing directory (package\fre\amd64)file (e500v2.sys)
Processing directory (package\fre\i386) file (e500v2.sys)
Parsing INF: package\e500v2.inf
Finished parsing INFs
Processing INF: package\e500v2.inf
Finished processing INFs
Testing driver package…
Testing driver package…
Testing driver package…
Testing driver package…
Testing driver package…
Testing driver package…

Signability test complete.

Errors:
None

Warnings:
None

Catalog generation complete.
package\e500v2x86.cat
package\e500v2x64.cat

Sign catalog:
SignTool.exe sign /a /n “Indel AG” /t http://timestamp.verisign.com/scripts/timestamp.dll /v “package\e500v2x86.cat”
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: package\e500v2x86.cat

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

SignTool.exe sign /a /n “Indel AG” /t http://timestamp.verisign.com/scripts/timestamp.dll /v “package\e500v2x64.cat”
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: package\e500v2x64.cat

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

Verify signature
SignTool.exe verify /kp “package\fre\amd64\e500v2.sys”

Verifying: package\fre\amd64\e500v2.sys
Hash of file (sha1): 55177D6A2E84689C9D671783D18CD02FA03BE971

Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: GlobalSign Root CA
Issued by: Microsoft Code Verification Root
Expires: Mon May 23 19:10:51 2016
SHA1 hash: 3EEB2750A199F5E7B6A8952430BE5062FE04E9E5

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Successfully verified: package\e500v2x64.cat

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

Same output for verifying the catalog files (except for the hashes of course).

But the driver files still don’t show up in the catalog file

SignTool.exe verify /kp /c “package\e500v2x64.cat” /v “package\fre\amd64\e500v2.sys”

Verifying: package\fre\amd64\e500v2.sys
SignTool Error: File not found in the specified catalog.
SignTool Error: File not valid: package\fre\amd64\e500v2.sys

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

What else do I have to do? I’m suspecting an error in the inf file or the creation
of the catalog. How can I check if the driver files are referenced from the catalog?
Is the relative path of the sys files important or only the file name?
The KMCS_Walkthrough.doc from Microsoft still talks about the old Vista DDK
with different tools (Signability).

Thanks

bye Fabi

2

You’re missing the /ac on the command line to include the MS cross
cert in the signing.

/ac is followed by the path to the cross cert .CER file.

Follow the example in the KMCS Walkthrough document.

Mark.

At 15:56 16/05/2011, Fabian Cenedese wrote:

Hi

We have purchased a code signing certificate from GlobalSign.
There’s also a cross-certificate from Microsoft for GlobalSign,
I have imported both of them in my Windows 7 64. I sign my
driver, create a cat (Inf2cat) and sign this as well. However
another system with Windows 7 64 still won’t accept this to
install the driver (“…cannot verify the digital signature… Code 52”)

Sign the sys:
SignTool.exe sign /a /f company-certificate.pfx /p password /t
http://timestamp.verisign.com/scripts/timestamp.dll /v
“package\fre\amd64\e500v2.sys”
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: package\fre\amd64\e500v2.sys

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

Create catalog:
inf2cat.exe /driver:package\
/os:XP_X86,XP_X64,Vista_X86,Vista_X64,7_X86,7_X64 /v
Processing directory (package) file (e500v2.inf)
Processing directory (package) file (e500v2x64.cat)
Processing directory (package) file (e500v2x86.cat)
Processing directory (package\chk\amd64)file (e500v2.sys)
Processing directory (package\chk\i386) file (e500v2.sys)
Processing directory (package\fre\amd64)file (e500v2.sys)
Processing directory (package\fre\i386) file (e500v2.sys)
Parsing INF: package\e500v2.inf
Finished parsing INFs
Processing INF: package\e500v2.inf
Finished processing INFs
Testing driver package…
Testing driver package…
Testing driver package…
Testing driver package…
Testing driver package…
Testing driver package…

Signability test complete.

Errors:
None

Warnings:
None

Catalog generation complete.
package\e500v2x86.cat
package\e500v2x64.cat

Sign catalog:
SignTool.exe sign /a /n “Indel AG” /t
http://timestamp.verisign.com/scripts/timestamp.dll /v “package\e500v2x86.cat”
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: package\e500v2x86.cat

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

SignTool.exe sign /a /n “Indel AG” /t
http://timestamp.verisign.com/scripts/timestamp.dll /v “package\e500v2x64.cat”
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: package\e500v2x64.cat

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

Verify signature
SignTool.exe verify /kp “package\fre\amd64\e500v2.sys”

Verifying: package\fre\amd64\e500v2.sys
Hash of file (sha1): 55177D6A2E84689C9D671783D18CD02FA03BE971

Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: GlobalSign Root CA
Issued by: Microsoft Code Verification Root
Expires: Mon May 23 19:10:51 2016
SHA1 hash: 3EEB2750A199F5E7B6A8952430BE5062FE04E9E5

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Successfully verified: package\e500v2x64.cat

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

Same output for verifying the catalog files (except for the hashes of course).

But the driver files still don’t show up in the catalog file

SignTool.exe verify /kp /c “package\e500v2x64.cat” /v
“package\fre\amd64\e500v2.sys”

Verifying: package\fre\amd64\e500v2.sys
SignTool Error: File not found in the specified catalog.
SignTool Error: File not valid: package\fre\amd64\e500v2.sys

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

What else do I have to do? I’m suspecting an error in the inf file
or the creation
of the catalog. How can I check if the driver files are referenced
from the catalog?
Is the relative path of the sys files important or only the file name?
The KMCS_Walkthrough.doc from Microsoft still talks about the old Vista DDK
with different tools (Signability).

Thanks

bye Fabi

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

At 16:40 16.05.2011 +0100, you wrote:

You're missing the /ac on the command line to include the MS cross cert in the signing.

/ac is followed by the path to the cross cert .CER file.

Follow the example in the KMCS Walkthrough document.

I already did that but I still get code 52 upon installing.

SignTool.exe sign /a /ac MSCV-GlobalSign.cer /f \companycert.pfx /p password /t http://timestamp.verisign.com/scripts/timestamp.dll /v "fre\amd64\e500v2.sys"
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Cross certificate chain (using machine store):
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: GlobalSign Root CA
Issued by: Microsoft Code Verification Root
Expires: Mon May 23 19:10:51 2016
SHA1 hash: 3EEB2750A199F5E7B6A8952430BE5062FE04E9E5

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: fre\amd64\e500v2.sys

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

inf2cat /driver:package\ /os:XP_X86,XP_X64,Vista_X86,Vista_X64,7_X86,7_X64 /v
Processing directory (package) file (e500v2.inf)
Processing directory (package) file (e500v2x64.cat)
Processing directory (package) file (e500v2x86.cat)
Processing directory (package\fre\amd64)file (e500v2.sys)
Processing directory (package\fre\i386) file (e500v2.sys)
Parsing INF: package\e500v2.inf
Finished parsing INFs
Processing INF: package\e500v2.inf
Finished processing INFs
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...
Testing driver package...

Signability test complete.

Errors:
None

Warnings:
None

Catalog generation complete.
package\e500v2x86.cat
package\e500v2x64.cat

SignTool.exe sign /a /ac MSCV-GlobalSign.cer /n "Indel AG" /t http://timestamp.verisign.com/scripts/timestamp.dll /v "e500v2x64.cat"
The following certificate was selected:
Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Cross certificate chain (using machine store):
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: GlobalSign Root CA
Issued by: Microsoft Code Verification Root
Expires: Mon May 23 19:10:51 2016
SHA1 hash: 3EEB2750A199F5E7B6A8952430BE5062FE04E9E5

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Done Adding Additional Store
Successfully signed and timestamped: e500v2x64.cat

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

SignTool.exe verify /kp /v "e500v2x64.cat"

Verifying: e500v2x64.cat
Hash of file (sha1): F8ED72E35BD3DACBBD6C8E9DE33EC4F353F3A117

Signing Certificate Chain:
Issued to: GlobalSign Root CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 28 14:00:00 2028
SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

The signature is timestamped: Tue May 17 08:46:30 2011
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

Issued to: VeriSign Time Stamping Services CA
Issued by: Thawte Timestamping CA
Expires: Wed Dec 04 01:59:59 2013
SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

Issued to: VeriSign Time Stamping Services Signer - G2
Issued by: VeriSign Time Stamping Services CA
Expires: Fri Jun 15 01:59:59 2012
SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE

Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: GlobalSign Root CA
Issued by: Microsoft Code Verification Root
Expires: Mon May 23 19:10:51 2016
SHA1 hash: 3EEB2750A199F5E7B6A8952430BE5062FE04E9E5

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Successfully verified: e500v2x64.cat

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

SignTool.exe verify /kp /c "e500v2x64.cat" /v "e500v2.inf"

Verifying: e500v2.inf
File is signed in catalog: e500v2x64.cat
Hash of file (sha1): 605FAC030A47C589C6A9C41898C91552BA6054FC

Signing Certificate Chain:
Issued to: GlobalSign Root CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 28 14:00:00 2028
SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

The signature is timestamped: Tue May 17 08:46:30 2011
Timestamp Verified by:
Issued to: Thawte Timestamping CA
Issued by: Thawte Timestamping CA
Expires: Fri Jan 01 01:59:59 2021
SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656

Issued to: VeriSign Time Stamping Services CA
Issued by: Thawte Timestamping CA
Expires: Wed Dec 04 01:59:59 2013
SHA1 hash: F46AC0C6EFBB8C6A14F55F09E2D37DF4C0DE012D

Issued to: VeriSign Time Stamping Services Signer - G2
Issued by: VeriSign Time Stamping Services CA
Expires: Fri Jun 15 01:59:59 2012
SHA1 hash: ADA8AAA643FF7DC38DD40FA4C97AD559FF4846DE

Cross Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: Sat Nov 01 15:54:03 2025
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3

Issued to: GlobalSign Root CA
Issued by: Microsoft Code Verification Root
Expires: Mon May 23 19:10:51 2016
SHA1 hash: 3EEB2750A199F5E7B6A8952430BE5062FE04E9E5

Issued to: GlobalSign Primary Object Publishing CA
Issued by: GlobalSign Root CA
Expires: Fri Jan 27 14:00:00 2017
SHA1 hash: 549DF5E7102A223BA204B7150106D8EA17B7A70A

Issued to: GlobalSign ObjectSign CA
Issued by: GlobalSign Primary Object Publishing CA
Expires: Fri Jan 27 12:00:00 2017
SHA1 hash: 94BDB3CE4A5BC37A9A0BB45AFADB043932474F32

Issued to: Indel AG
Issued by: GlobalSign ObjectSign CA
Expires: Tue May 13 11:02:07 2014
SHA1 hash: 7D098B9AC13057B60FC2C7B8BCE92EEA1B6EECCB

Successfully verified: e500v2.inf

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

What else can I check? Do I need to import a certificate on the target system?

Thanks

bye Fabi

4

On 05/17/2011 08:50 AM, Fabian Cenedese wrote:

> Follow the example in the KMCS Walkthrough document.
I already did that but I still get code 52 upon installing.

What else can I check?

Check which certificates are embedded *into* your CAT and SYS files.
You can do this from a WDK command line with “certmgr ”

> Do I need to import a certificate on the target system?

No, when the signing is done correctly, nothing needs to be imported on
the target system. Neither for driver install nor for driver load.

Looks to me like you have a similar “certificate chain” problem as we
had with embed-signing, so please read on. [Sorry for the long post.]

BACKGROUND:

For Win7/64bit driver installation and load, your driver CAT and SYS
files need a correct and complete “certificate chain” embedded up to a
reasonable level.

For CAT files, a chain up to a certificate “high enough” is sufficient
(to “Trusted Root” or “Trusted Publishers” will do).

For SYS files, you absolutely need a certificate chain that includes the
cross-certificate to “MS Code Verification Root” embedded in the file.

EVIDENCE:

> Cross certificate chain (using machine store):

…this “using machine store” might be a clue.

“signtool verify” also finds and uses certificates that are present in
your (developer machine) registry for building a valid chain.

But these certificates are not necessarily present on the target.

[For a cross-test, you should copy signtool.exe (and its libs) to the
target and try to verify the signature there.]

> Signing Certificate Chain:
> Issued to: GlobalSign Root CA
> Issued by: GlobalSign Root CA
> Expires: Fri Jan 28 14:00:00 2028
> SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C

Ah! This certificate is likely the culprit.

It was rolled out in an update package, but might not be present on all
targets. [Just installing it on the target would work, but is not the
real solution.] The solution is to use a “certification path” that uses
the older, already rolled-out GlobalSign cross-certificates.

On the developer machine, you likely have both sets of GlobalSign
certificates, old and new (valid until 2014/2016 and until 2028), and so
a valid chain for signature testing and installation can be found.

Also you will have a locally installed cross-certificate (because
Signtool auto-installs it during signing). So driver load works, too.

PROBLEM ROOT CAUSE:

During signing, “Signtool.exe” always chooses the most current
certificates, no matter if the resulting certificate chain ends with the
MSCV root cross-certificate (or not).

[WDK7600’s Signtool.exe at least prints “Signtool Error: The provided
cross certificate would not be present in the certificate chain.” in
this case. Better than nothing.]

WORKAROUND:

The “short-term” fix is to actually remove the newer GlobalSign
certificates that cause Signtool.exe to break the certification path.
The certmgr GUI (=when invoked without parameter) helps here, too.
You can use the old GlobalSIgn certificates until 2014 (when they
expire). [Timestamping should ensure your driver will be accepted
afterwards, too.]

SOLUTION:

The real fix would be

(a) a newer cross-certificate that links the 2028-expiring “GlobalSign
Root CA” certificate to the “Microsoft Code Verification Root”

(b) a fix for Signtool.exe that makes sure a complete certification
chain is always attempted first, before just using later-expiring
certificates

ADDITIONAL READING:
http://www.osronline.com/showthread.cfm?link=192421
http://www.osronline.com/showthread.cfm?link=185696
-> see my mail from 2010-JUL-12

Related links for VeriSign:
http://www.osronline.com/showthread.cfm?link=197762
http://www.osronline.com/showthread.cfm?link=197659

5

Just one thing to add to Hagen’s excellent list of things to
check. Root certificates do change, as many of us who use Verisign
have discovered recently. One reason this can cause so many
headaches is that updates to the root certificates are only listed as
recommended by Microsoft Update.

I would expect that if you follow Hagen’s list that you will solve
the problem. However, if all else fails have a look for KB931125 and
the latest root update package from March 2011. The actual download
can be found here:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3a027078-4cd7-4b27-9837-3d7e58dd5a89

I’d also suggest trawling the GlobalSign knowledge base and talking
to their support. Hopefully it’s easier than Verisign’s.

Mark.

At 08:57 17/05/2011, Hagen Patzke wrote:

On 05/17/2011 08:50 AM, Fabian Cenedese wrote:
>> Follow the example in the KMCS Walkthrough document.
> I already did that but I still get code 52 upon installing.

> What else can I check?

Check which certificates are embedded *into* your CAT and SYS files.
You can do this from a WDK command line with “certmgr ”
>
>
> > Do I need to import a certificate on the target system?
>
>No, when the signing is done correctly, nothing needs to be imported on
>the target system. Neither for driver install nor for driver load.
>
>
>Looks to me like you have a similar “certificate chain” problem as we
>had with embed-signing, so please read on. [Sorry for the long post.]
>
>
>BACKGROUND:
>
>For Win7/64bit driver installation and load, your driver CAT and SYS
>files need a correct and complete “certificate chain” embedded up to a
>reasonable level.
>
>For CAT files, a chain up to a certificate “high enough” is sufficient
>(to “Trusted Root” or “Trusted Publishers” will do).
>
>For SYS files, you absolutely need a certificate chain that includes the
>cross-certificate to “MS Code Verification Root” embedded in the file.
>
>
>EVIDENCE:
>
> > Cross certificate chain (using machine store):
>
>…this “using machine store” might be a clue.
>
>“signtool verify” also finds and uses certificates that are present in
>your (developer machine) registry for building a valid chain.
>
>But these certificates are not necessarily present on the target.
>
>[For a cross-test, you should copy signtool.exe (and its libs) to the
>target and try to verify the signature there.]
>
>
> > Signing Certificate Chain:
> > Issued to: GlobalSign Root CA
> > Issued by: GlobalSign Root CA
> > Expires: Fri Jan 28 14:00:00 2028
> > SHA1 hash: B1BC968BD4F49D622AA89A81F2150152A41D829C
>
>Ah! This certificate is likely the culprit.
>
>It was rolled out in an update package, but might not be present on all
>targets. [Just installing it on the target would work, but is not the
>real solution.] The solution is to use a “certification path” that uses
>the older, already rolled-out GlobalSign cross-certificates.
>
>On the developer machine, you likely have both sets of GlobalSign
>certificates, old and new (valid until 2014/2016 and until 2028), and so
>a valid chain for signature testing and installation can be found.
>
>Also you will have a locally installed cross-certificate (because
>Signtool auto-installs it during signing). So driver load works, too.
>
>
>PROBLEM ROOT CAUSE:
>
>During signing, “Signtool.exe” always chooses the most current
>certificates, no matter if the resulting certificate chain ends with the
>MSCV root cross-certificate (or not).
>
>
>[WDK7600’s Signtool.exe at least prints “Signtool Error: The provided
>cross certificate would not be present in the certificate chain.” in
>this case. Better than nothing.]
>
>
>WORKAROUND:
>
>The “short-term” fix is to actually remove the newer GlobalSign
>certificates that cause Signtool.exe to break the certification path.
>The certmgr GUI (=when invoked without parameter) helps here, too.
>You can use the old GlobalSIgn certificates until 2014 (when they
>expire). [Timestamping should ensure your driver will be accepted
>afterwards, too.]
>
>
>SOLUTION:
>
>The real fix would be
>
>(a) a newer cross-certificate that links the 2028-expiring “GlobalSign
>Root CA” certificate to the “Microsoft Code Verification Root”
>
>(b) a fix for Signtool.exe that makes sure a complete certification
>chain is always attempted first, before just using later-expiring
>certificates
>
>
>
>ADDITIONAL READING:
>http://www.osronline.com/showthread.cfm?link=192421
>http://www.osronline.com/showthread.cfm?link=185696
>-> see my mail from 2010-JUL-12
>
>Related links for VeriSign:
>http://www.osronline.com/showthread.cfm?link=197762
>http://www.osronline.com/showthread.cfm?link=197659
>
>
>—
>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

6

Hi

It seems like I got it to work. The /ac switch might have been the last
“real” bug. The reason it still didn’t work with that was probably pebkac.
I assume I accidentally copied the unsigned driver to the System32\drivers
folder or possibly just uninstalled/installed without copying the new driver
at all. So I can now install my driver also on Win64, thanks to all.
I’ll still answer the questions for completeness.

Check which certificates are embedded *into* your CAT and SYS files.
You can do this from a WDK command line with “certmgr ”

On the development system this just opens up the mmc with certman
in it, the file is not considered. However on the target system I get this
(leaving out some serial numbers and thumbprints):

----- Signer [1] -----
Hash Algorithm:: 1.3.14.3.2.26 (sha1)
Encrypt Algorithm:: 1.2.840.113549.1.1.1 ()
----- Signer [1] Certificate-----
Subject::
[0,0] 2.5.4.6 (C) CH
[1,0] 2.5.4.8 (S) ZH
[2,0] 2.5.4.7 (L) Russikon
[3,0] 2.5.4.10 (O) Indel AG
[4,0] 2.5.4.3 (CN) Indel AG
Issuer::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) ObjectSign CA
[3,0] 2.5.4.3 (CN) GlobalSign ObjectSign CA
NotBefore::
Fri May 13 11:02:10 2011
NotAfter::
Tue May 13 11:02:07 2014
----- Signer [1] AuthenticatedAttributes -----
[0,0] 1.2.840.113549.1.9.3
[1,0] 1.3.6.1.4.1.311.2.1.11
[2,0] 1.2.840.113549.1.9.4
[3,0] 1.3.6.1.4.1.311.2.1.12
----- Signer [1] UnauthenticatedAttributes -----
[0,0] 1.2.840.113549.1.9.6
Timestamp::
Timestamp Version:: 1
Timestamp server’s certificate issuer::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.10 (O) VeriSign, Inc.
[2,0] 2.5.4.3 (CN) VeriSign Time Stamping Services CA
Timestamp’s authenticated attributes::
[0,0] 1.2.840.113549.1.9.3
[1,0] 1.2.840.113549.1.9.5
Signing Time::
Tue May 17 09:36:46 2011
[2,0] 1.2.840.113549.1.9.4
==============Certificate # 1 ==========
Subject::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) Root CA
[3,0] 2.5.4.3 (CN) GlobalSign Root CA
Issuer::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.8 (S) Washington
[2,0] 2.5.4.7 (L) Redmond
[3,0] 2.5.4.10 (O) Microsoft Corporation
[4,0] 2.5.4.3 (CN) Microsoft Code Verification Root
NotBefore::
Tue May 23 19:00:51 2006
NotAfter::
Mon May 23 19:10:51 2016
==============Certificate # 2 ==========
Subject::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) ObjectSign CA
[3,0] 2.5.4.3 (CN) GlobalSign ObjectSign CA
Issuer::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) Primary Object Publishing CA
[3,0] 2.5.4.3 (CN) GlobalSign Primary Object Publishing CA
NotBefore::
Thu Jan 22 12:00:00 2004
NotAfter::
Fri Jan 27 12:00:00 2017
==============Certificate # 3 ==========
Subject::
[0,0] 2.5.4.6 (C) CH
[1,0] 2.5.4.8 (S) ZH
[2,0] 2.5.4.7 (L) Russikon
[3,0] 2.5.4.10 (O) Indel AG
[4,0] 2.5.4.3 (CN) Indel AG
Issuer::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) ObjectSign CA
[3,0] 2.5.4.3 (CN) GlobalSign ObjectSign CA
NotBefore::
Fri May 13 11:02:10 2011
NotAfter::
Tue May 13 11:02:07 2014
==============Certificate # 4 ==========
Subject::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) Primary Object Publishing CA
[3,0] 2.5.4.3 (CN) GlobalSign Primary Object Publishing CA
Issuer::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) Root CA
[3,0] 2.5.4.3 (CN) GlobalSign Root CA
NotBefore::
Thu Jan 28 15:00:00 1999
NotAfter::
Fri Jan 27 14:00:00 2017
==============Certificate # 5 ==========
Subject::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.10 (O) VeriSign, Inc.
[2,0] 2.5.4.3 (CN) VeriSign Time Stamping Services CA
Issuer::
[0,0] 2.5.4.6 (C) ZA
[1,0] 2.5.4.8 (S) Western Cape
[2,0] 2.5.4.7 (L) Durbanville
[3,0] 2.5.4.10 (O) Thawte
[4,0] 2.5.4.11 (OU) Thawte Certification
[5,0] 2.5.4.3 (CN) Thawte Timestamping CA
NotBefore::
Thu Dec 04 02:00:00 2003
NotAfter::
Wed Dec 04 01:59:59 2013
==============Certificate # 6 ==========
Subject::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.10 (O) VeriSign, Inc.
[2,0] 2.5.4.3 (CN) VeriSign Time Stamping Services Signer - G2
Issuer::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.10 (O) VeriSign, Inc.
[2,0] 2.5.4.3 (CN) VeriSign Time Stamping Services CA
NotBefore::
Fri Jun 15 02:00:00 2007
NotAfter::
Fri Jun 15 01:59:59 2012
==============No CTLs ==========
==============No CRLs ==========
==============================================
CertMgr Succeeded

>Looks to me like you have a similar “certificate chain” problem as we
>had with embed-signing, so please read on. [Sorry for the long post.]

That’s ok, long explanations are usually better understandable.

>For SYS files, you absolutely need a certificate chain that includes the
>cross-certificate to “MS Code Verification Root” embedded in the file.

I hope it is, the output above looks ok to me but I don’t see anything
about embedding.

>[For a cross-test, you should copy signtool.exe (and its libs) to the
>target and try to verify the signature there.]

Shows the same output as in my first mail. Both sys and cat have the
cross certificate chain Indel -> GlobalSign -> Microsoft.
(status successfully verified)

>On the developer machine, you likely have both sets of GlobalSign
>certificates, old and new (valid until 2014/2016 and until 2028), and so
>a valid chain for signature testing and installation can be found.

On the developer machine I only have the 2028 Root CA, the
Code Signing certificates are 2017. On the target system I have
the same 2028 Root CA and no code signing certificate of course.
So this shouldn’t be a problem.

>ADDITIONAL READING:
>http://www.osronline.com/showthread.cfm?link=192421
>http://www.osronline.com/showthread.cfm?link=185696
>-> see my mail from 2010-JUL-12
>
>Related links for VeriSign:
>http://www.osronline.com/showthread.cfm?link=197762
>http://www.osronline.com/showthread.cfm?link=197659

Thanks for the interesting reads. While reading this another question
came into my mind.

What happens if our certificate expires and we don’t renew it? Is the
only consequence that we can’t sign new drivers? Or will the already
deployed drivers also stop to work on Win64? Or if we get out of business,
are the customers screwed?


The driver signature enforcement is justified by Microsoft as improving
quality as a lot of blue screens are caused by bad drivers. However that
would only be true if each driver also had passed a WHQL test. Right
now the drivers are the same good or bad quality, just with a certificate
that anyone can buy. Considering the fact that only very few (actually
boiling down to VeriSign and GlobalSign if you follow the links on
Microsoft’s cross certificate page) authorities have cross certificates
this smells a lot like a money making scheme. *Sign can sure be
thankful to MS…


Thanks to all on this list who are helping.

bye Fabi

7

At 10:48 17/05/2011, Fabian Cenedese wrote:

Thanks for the interesting reads. While reading this another question
came into my mind.

What happens if our certificate expires and we don’t renew it? Is the
only consequence that we can’t sign new drivers? Or will the already
deployed drivers also stop to work on Win64? Or if we get out of business,
are the customers screwed?

Correct, packages signed before expiration will continue to install
and the drivers will work. You just won’t be able to create new
packages until you refresh the signing certificate.

Mark.

8

> What happens if our certificate expires and we don’t renew it?

Is the only consequence that we can’t sign new drivers?

Yes.

Or if we get out of business, are the customers screwed?

No.

Best regards,
Alex Krol

9

On 05/17/2011 11:48 AM, Fabian Cenedese wrote:

However on the target system I get this
[…]
==============Certificate # 1 ==========
Subject::
[0,0] 2.5.4.6 (C) BE
[1,0] 2.5.4.10 (O) GlobalSign nv-sa
[2,0] 2.5.4.11 (OU) Root CA
[3,0] 2.5.4.3 (CN) GlobalSign Root CA
Issuer::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.8 (S) Washington
[2,0] 2.5.4.7 (L) Redmond
[3,0] 2.5.4.10 (O) Microsoft Corporation
[4,0] 2.5.4.3 (CN) Microsoft Code Verification Root
NotBefore::
Tue May 23 19:00:51 2006
NotAfter::
Mon May 23 19:10:51 2016
[…]
CertMgr Succeeded

[…] the output above looks ok to me

To me, too: it contains the MSCV Root cross-cert. To my knowledge this
is not embedded unless the certificate chain is complete / valid.

but I don’t see anything about embedding.

Having the certificate chain inside the file *is* the embedding. :slight_smile:

On the developer machine I only have the 2028 Root CA, the
Code Signing certificates are 2017. On the target system I have
the same 2028 Root CA and no code signing certificate of course.
So this shouldn’t be a problem.

“Certificate # 4” links GlobalSign “Primary Object Publishing” to “Root
CA” and expires 2017.

There is a version of this certificate that expires later, but will not
link with the MSCV Root cross-certificate.

My assumption was that this caused your problem (the symptoms looked
like it). Obviously not. Good for you!

What happens if our certificate expires and we don’t renew it?
Is the only consequence that we can’t sign new drivers?

Correct if you always cryptographically timestamp your drivers.

The timestamp proves that your certificate was valid at the point of
time when you used it for signing, and this is all that counts.

Or will the already deployed drivers also stop to work on Win64?

Without timestamp they would.

Another interesting question is: What will happen when the timestamp
certificate expires?
[We will know latest in 2013. And it should also be “nothing”.]


> The driver signature enforcement is justified by Microsoft as improving
> quality as a lot of blue screens are caused by bad drivers. However that
> would only be true if each driver also had passed a WHQL test. Right
> now the drivers are the same good or bad quality, just with a certificate
> that anyone can buy. Considering the fact that only very few (actually
> boiling down to VeriSign and GlobalSign if you follow the links on
> Microsoft’s cross certificate page) authorities have cross certificates
> this smells a lot like a money making scheme. *Sign can sure be
> thankful to MS…
>

Not quite. An official Code Signing Certificate is only given to an
entity which can be tracked down and held liable if necessary.

The main reasons to insist on signed drivers is

(1) A signature establishes identity of who made a driver.

(2) Based on that identity you can decide what to do with the driver.

E.g., an administrator can place a companies’ certificate into an
“rejected certificates” store, thus preventing a user from accidentally
installing/loading a driver signed with it.

With unsigned drivers, anyone can make an “anonymous” malicious
driver, and you have no chance to track it and/or to prevent its
installation for the future. You can, once it is signed.

Even in case a cert gets stolen, and some culprit uses a honorable
companies’ cert to sign a malicious driver, you can revoke this cert.
Then the company whose cert was stolen and who had “good” drivers signed
with it will have to get a new cert and re-sign and re-distribute all
drivers with the new cert. Lots of hassle, but no security hole.

WHQL signing is just opening a “silent install” option for drivers whose
driver developers committed to a certain amount of additional testing.

As I see it, there is no money for Microsoft in all this. Signatures are
useful in certain circumstances, so they use them, but that’s all.

10

I disagree here. That presumes most customers use x64 and most users don’t allow test signing. I’ve seen big
companies allow all kinds of BS drivers get installed.
It’s a good idea, but isn’t working out yet.

Hagen Patzke wrote:

Not quite. An official Code Signing Certificate is only given to an
entity which can be tracked down and held liable if necessary.

The main reasons to insist on signed drivers is

(1) A signature establishes identity of who made a driver.

(2) Based on that identity you can decide what to do with the driver.

E.g., an administrator can place a companies’ certificate into an
“rejected certificates” store, thus preventing a user from accidentally
installing/loading a driver signed with it.

With *unsigned* drivers, anyone can make an “anonymous” malicious
driver, and you have no chance to track it and/or to prevent its
installation for the future. You can, once it is *signed*.

Even in case a cert gets stolen, and some culprit uses a honorable
companies’ cert to sign a malicious driver, you can revoke this cert.
Then the company whose cert was stolen and who had “good” drivers signed
with it will have to get a new cert and re-sign and re-distribute all
drivers with the new cert. Lots of hassle, but no security hole.

WHQL signing is just opening a “silent install” option for drivers whose
driver developers committed to a certain amount of additional testing.

As I see it, there is no money for Microsoft in all this. Signatures are
useful in certain circumstances, so they use them, but that’s all.

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

11

On 05/17/2011 01:50 PM, Dejan Maksimovic wrote:

I disagree here. That presumes most customers use x64 and most users
don’t allow test signing. I’ve seen big companies allow all kinds of
BS drivers get installed.
It’s a good idea, but isn’t working out yet.

Everybody has the inalienable right to shoot themselves in the foot.

E.g., if you have a car with a “seat belt not fastened” alarm, you can
bridge the sensor that sounds the alarm.
Then this also is “It’s a good idea, but isn’t working out yet.”

Bonus quote from the 'net: “Those who try to build idiot-proof systems
always underestimate the persistence and ingenuity of idiots.”

12

There’s a price for everything and a benefit for it - IMO, we pay an unneeded price for signing our drivers (OK
it’s not really big, but it’s unneeded at this time) and get no benefit from it :frowning:
Can we sue someone if their driver does not work correctly? No. Do we loose customers even if a driver is not
signed by us and looks like our driver? Yes.

I know this won’t change anything, but it’s worth venting :slight_smile:

Dejan.

Hagen Patzke wrote:

On 05/17/2011 01:50 PM, Dejan Maksimovic wrote:
> I disagree here. That presumes most customers use x64 and most users
> don’t allow test signing. I’ve seen big companies allow all kinds of
> BS drivers get installed.
> It’s a good idea, but isn’t working out yet.

Everybody has the inalienable right to shoot themselves in the foot.

E.g., if you have a car with a “seat belt not fastened” alarm, you can
bridge the sensor that sounds the alarm.
Then this also is “It’s a good idea, but isn’t working out yet.”

Bonus quote from the 'net: “Those who try to build idiot-proof systems
always underestimate the persistence and ingenuity of idiots.”

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

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

13

On 05/18/2011 08:19 AM, Dejan Maksimovic wrote:

IMO, we pay an unneeded price for signing our drivers […] and get
no benefit from it :frowning:

You don’t need to sign 32+64bit UMDF drivers or 32bit kernel drivers.

You only need to sign drivers if you want them executed in kernel space
on 64bit Windows. You can decide if this is a benefit to you.

If you develop software for any closed-source operating system, you have
to abide to the rules of the the OS vendor: OS API, Signatures, etc.

For open-source, you need to convince others, or roll out your own OS.

Can we sue someone if their driver does not work correctly? No.

Remember, the first 64bit Windows versions were only for servers.

A signed driver makes it at least possible for a server admin to exclude
drivers that destabilize their production rig from their systems.

That now even Netbooks come with 64bit Windows is an interesting twist
of events. Maybe this is for the same reasoning as for servers:

Driver problems can cause a lot of support costs. Apart from the
problems you already have to solve, you don’t want to allow unsigned
drivers from unidentifiable sources(!) to cause you grief.

14

> A signed driver makes it at least possible for a server admin to exclude

drivers that destabilize their production rig from their systems.

The motivation is not such, as it is obvious.

What you said is the motivation for WHQL and not KMCS.

The motivation for KMCS is an attempt to block copy protection violations.

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

15

> For open-source, you need to convince others, or roll out your own OS.

Same is true for closed-source OS, just “others” are named “Microsoft” or “Apple” in this case.

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

16

I also don’t like the fact that I have to sign my drivers for x64.

However, I like the fact that I have x64 Windows at home, with UAC enabled (asking for password + user) so I can be safe that no crap will be installed because of some simple mistakes (i.e., using IE as admin in XP SP3 and it get crashed because of buffer overflow …), hooked, etc, and I can do safe banking.

For those who really hates to pay for certificate - try to ask yourself how you will solve the problem of rootkits in Windows.

Anyway, what is 99 $ (1 year verisign certificate price) these days? One full tank of petrol for the car or one week food supply for 1 person in supermarket? :slight_smile:

17

> On 05/18/2011 08:19 AM, Dejan Maksimovic wrote:

> IMO, we pay an unneeded price for signing our drivers […] and get
> no benefit from it :frowning:

You don’t need to sign 32+64bit UMDF drivers or 32bit kernel drivers.

You only need to sign drivers if you want them executed in kernel space
on 64bit Windows. You can decide if this is a benefit to you.

That’s not a “benefit” it is a forced “payment”. An actual benefit would be seeing that many customers would
not use unsigned software.
Remember those XP driver prompts? They were over-ignored. Everyone installed unsigned drivers. A few may
have “felt” better that a driver is signed, but it wasn’t a winning factor.
Now you are forced to use a signed driver. There is no added benefit of it. Rather we disagree on how you
see benefit - to me, it would be that there were customers who would never use our drivers if they were unsigned
even on XP32 - that was not the case. Only when Vista 64 BECAME somewhat spread was this an issue. That, in my mind,
is sufficient to say that there was no real benefit of using signatures. It was a forced payment to artificially
make people think there is an added benefit.

Can you provide anything to the contrary? A case where a server would have been saved were a signature
present? A case where you could sue a company because you can prove it was their driver that caused damage?

If you develop software for any closed-source operating system, you have
to abide to the rules of the the OS vendor: OS API, Signatures, etc.

We are not debating that - only whether there was any benefit :slight_smile:
And I am quite happy that MS did not push rules that are as ridiculous as (cr)Apple’s.

> Can we sue someone if their driver does not work correctly? No.

Remember, the first 64bit Windows versions were only for servers.
A signed driver makes it at least possible for a server admin to exclude
drivers that destabilize their production rig from their systems.

How does that answer my question or relate to it at all?

Driver problems can cause a lot of support costs. Apart from the problems you already have to solve, you don’t
want to allow unsigned drivers from unidentifiable sources(!) to cause you grief.

How does it solve problems if a driver is signed? A correct-minded admin will not install ANY drivers on a
system without verifying they work on a test system first. Hence - the signature “benefit” just became useless.

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

18

>>That’s not a “benefit” it is a forced “payment”.<<

No, it’s not. Why do you need to pay for certificate on the first place? Because you want to support x64, right? So, you are selling your software and you earn money (your customers pay you), but you don’t want to pay fees to maintain your software, or what?

If you are open source developer, things are not that bad for you. Some tools like process hacker managed to get signed by another bigger open source projects and they just work fine.

19

You summed it quite right. I didn’t want to dive into a possible copy protection flame war.

BTW, the copy protection still does not work :slight_smile:

> A signed driver makes it at least possible for a server admin to exclude
> drivers that destabilize their production rig from their systems.
The motivation is not such, as it is obvious.
What you said is the motivation for WHQL and not KMCS.
The motivation for KMCS is an attempt to block copy protection violations.

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

20

> For those who really hates to pay for certificate - try to ask yourself how you will solve the problem of rootkits in Windows.

By NOT installing everything you download :slight_smile:

Anyway, what is 99 $ (1 year verisign certificate price) these days? One full tank of petrol for the car or one week food supply for 1 person in supermarket? :slight_smile:

It’s the 99$ that we could have spent on petrol or a small weekend trip. Why give it to Verisign when the benefit is still not there?

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.