> I’d like to provide a signed version of the driver to my own
customers, […] I’m looking for the cheapest possible way to sign
the driver.
We use GlobalSign. They are not very expensive, and also have an office
not too far away. This made the necessary identity checks easier.
Also we know that for our product we do not need WHQL signing.
Just to make sure you really get what you want, here are two scenarios
with explanations:
A: “In Driver Manager, I see our driver marked as ‘unsigned’. My
customer wants this to go.”
On all Windows versions, only WHQL signed drivers can “silent install”
and only these do not show the “unsigned driver” mark in Device Manager.
=> You need a WHQL = Windows Hardware Quality Labs Signature.
To get one, you need (1) to code-sign your driver, (2) test your driver
using the Driver Test Manager (DTM), (3) sign the DTM logs and (4)
submit these together with your driver and INF/CAT files to Microsoft.
If all is well, (5) Microsoft will sign your CAT file with a WHQL signature.
Note: There are a number of Microsoft-approved Certification Authorities
(CAs) for Kernel Mode Code-Signing (KMCS). But the number of CAs that
are also approved for WHQL submissions is smaller (Verisign).
If you start with a “cheaper” code-signing certificate from another CA,
you might have to buy an additional (cheaper) Verisign certificate for
WHQL submission later.
B: “My driver does not load on my Window 64bit system. But it needs to!”
-
On Win64, all “normal” kernel drivers must come with a signed CAT
file to be installed and loaded at run-time.
-
On Win64, kernel drivers that are needed for system boot must be
signed with an embedded signature. This also needs to contain a
cross-certificate linking the CA to the Microsoft code signing root.
-
On Win64, user-mode drivers using the User Mode Driver Framework
(UMDF) do not need to be signed. UMDF improves system stability - if you
can, go for it!
Note:
It is not (yet) mandatory to use signed drivers on 32bit machines to get
your driver loaded and executed.
That said, I would always recommend to use signatures where possible.
(E.g. we have a USB bulk driver that will never be needed at system boot
time, but nevertheless we sign the SYS file: this way anyone can easily
check if the file has been altered. Once you need a certificate anyway,
it’s basically a free extra.)
So: can I sign a driver with a cheapy COMODO $167/year code-signing
certificate, or do I have to shell out the $$$ for a Verisign one?
If you need WHQL, you possibly want to go for Verisign. But please
thoroughly check the Microsoft web sites about this: for some time,
there was an offer to obtain a WHQL-submission certificate for little
money. It may better fit your needs to have an inexpensive
three-year-valid code-signing certificate, and e.g. get a Verisign
one-year WHQL-submission-only certificate when you need it.
Also, I don’t understand how expiration works with certificates.
All certificates expire after some time. CA Root certificates can have
very long expiration times (10 and more years). Code-signing
certificates typically expire after one to three years.
To avoid expiration of your driver binary, you add a (free-of-charge)
cryptographic time-stamp when you sign the driver.
What happens “under the hood” is that the timestamp provider signs the
cryptographic hash of a given file (you can e.g. also pack an arbitrary
file - eg. a *.DOC file - into a *.CAB archive and have this timestamped).
If the file is a driver package (actually the CAT file), and your driver
certificate was valid at the date/time of the timestamping, Windows will
accept your driver.
Hope this helps,
Hagen
