|
Revision
1.5 – 9th Mar 2010 www.touch-base.com\documentation\technical WHQL and Digital Signature
considerations |
|||||||||
Short for Windows Hardware Quality Labs, WHQL is a Microsoft facility that tests and certifies third-party hardware and driver products for compatibility with Windows operating systems. Products that meet the compatibility requirements are then allowed to display Windows logos on product packaging, advertising and collateral and other marketing materials, indicating that the product has met the standards of Microsoft and that the product has been designed to work with the Windows operating systems. Once a product has received the WHQL logo it is listed on the Microsoft Hardware Compatibility List. This subject is covered in full at the Microsoft WHQL web site.
Drivers cannot pass the WHQL tests in isolation; they have to be submitted with suitable hardware. It is our understanding that digital signatures are only available for PnP devices. USB devices by their very nature are PnP compatible. The other devices mainly supported by UPDD are serial and very few of these devices are PnP. Serial PnP device specification is described in the Serial PnP specification document. It is our understanding that you cannot get approval if the submitted software supports a non-PnP device.
A driver that passes the tests is allocated a ‘digital signature’ and as such is considered ‘signed’. Drivers that have not been submitted for testing or have failed the tests are considered ‘unsigned’. Depending on the Driver Signing setting in the Hardware Tab of the system applet in the Control Panel, unsigned drivers can be blocked, approved (most common setting) or ignored.
This setting will result in the following dialog being shown when the hardware, handled by the unsigned driver, is used for the first time:
The Microsoft Winlogo web site has further information on the Windows Default system policy for unsigned drivers. Given that the UPDD driver supports 100’s of pointer devices, mostly unsigned, then most UPDD driver run ‘unsigned’. Signed drivers can only be utilised with hardware used in the signing process.
In most cases installing an unsigned driver is acceptable and many Windows drivers are unsigned. Given that UPDD has been signed it is proven to be a driver of good quality. However, in some cases it is required to supply signed drivers, especially for use on complete systems that need all components to be Microsoft approved so that the complete system can carry the ‘Designed for Windows’ logo.
Signing procedure
In very basic terms the WHQL hardware compatibility tests are downloaded and installed and are run against a driver and controller combination. The tests have to be undertaken on a system that has passed WHQL and will not cause any conflicts during testing. Tests are performed for both 32 and 64 bit drivers.
The tests generate logs which are processed and are submitted for review and approval. They can only be submitted by companies that have obtained a VeriSign Class 3 code-signing ID. Once approved a .cat file, containing the digital signature, is returned for distribution with the driver and controller combination.
Thereafter, the operating system performs signature detection whenever
an INF file is referenced to install hardware from a device class that is
subject to signature detection: that is, during any Plug and Play operation,
when the user runs the Add New Hardware wizard in the Control Panel, and so on.
The system always installs the driver that is the closest match for the
hardware, whether or not that driver is signed; however, given drivers of equal
rank, the system installs the signed driver rather than the unsigned driver.
During driver installation, Windows compares the hashes contained in
the driver's CAT file with the computed hash of the driver binaries to
determine whether the binaries have changed since the CAT file was created. If
a driver fails the signature check or there is no CAT file the driver is
considered unsigned. Given this, once signed, no changes can be made to any
binaries used in the signing process. For this reason most companies that offer
signed drivers also offer the unsigned drivers with the latest development.
Further information about the signing procedure can be found on the web and a good place to start is the WHQL Getting Started web page.
Given the level of knowledge required to undertake the signing procedure many companies use a third party WHQL services company to undertake this work.
Signing service - Internal
Starting with UPDD 4.1.6 we now offer an in-house facility to sign UPDD with a specific controller. Since March 2007, Microsoft requires that all WHQL logo and signature tests are performed with the Windows Logo Kit (WLK) and Driver Test Manager (DTM). Setting up DTM is no small task; the DTM system is a dedicated network of servers and client machines running in various operating systems. Our DTM laboratory is set up and ready to test pointer device class devices.
As part of our production system we will maintain the digital signature files associated with each signed controller and UPDD build. This will allow us to offer signed drivers where available for specific controllers and yet continue further UPDD development.
The new UPDD 4.1.x design has minimized the code used in kernel mode (the signed element of the driver) allowing us to add further functionality and maintain the UPDD utility programs outside of the signing process. We are hopeful that very few, if any, changes will be made to the kernel element thus maintaining the signed certification across new driver releases.
Signing service - External
We
recommend that digital signatures be obtained by Touch-Base as this avoids any
issues such as integration problems.
We can
however embed a digital signature package obtained by another party if
required. Such a signature package has to integrate with the UPDD PnP
management system and so must confirm to certain guidelines.
1) Must be based on a UPDD 4.1.6 or
higher package.
2) There must be 2 packages, one 64 bit
and one 32 bit. Each of these packages should support all target systems for
the relevant processor architecture(e.g. XP,
3) A unique 4 character tag must be
used to identify your package. Please liaise with Touch-base to define a unique
tag.
4) Each package will contain the
following files. It is crucial that these files exactly match the signed driver
file.
·
An
inf installer file
·
The
signed driver file (tbupddsu.sys)
·
The
signature (cat) file
·
The
original installer (setup.exe) package from which the driver file was taken.
5) The
following file names must be used for files (where TTTT is the 4 character tag
mentioned above).
·
For
the INF files UPDDTTTT.INF and UPD6TTTT.INF for 32 and 64 bit systems
respectively.
·
For
the cat files UPDDTTTT.CAT and UPD6TTTT.CAT for 32 and 64 bit systems
respectively.
6) The INF
files should be based on the INF files installed by setup.exe (UPDDV3MO.INF and
UPDDV6MO.INF). Changes will be required (e.g. for the cat file name), but care
should be taken to not change the method in which the driver is installed.
7) The
current install strategy used is that tbupdd.sys is placed in
<windows>\system32\drivers and the inf / cat file placed in another
location (in practice \program files\updd but can be any non system folder).
The package should be structured such that with the files placed in this
manner, the Windows hardware wizard can be used to install and update the UPDD
drivers. After such an installation:
·
The
driver should be registered correctly in the device manager and marked as
digitally signed.
·
If
the UPDD package is active on the system then touch should function correctly.
UPDD Signed controller combinations
The following table lists the signed UPDD driver and controller combinations:
|
Date |
Controller |
PNP identification (how to
identify) |
UPDD kernel |
|
|
|
|
Vendor id |
Product id |
|
|
9th July 08 |
eGalax and derivatives |
EFF |
1 |
4.1.3 |
|
7th Nov 08 |
Mitsubishi |
1293 |
4002 |
4.1.3 |
|
1st May 09 |
Mitsubishi – resigned due to driver update |
1293 |
4002 |
4.1.6 |
|
18th Nov 08 |
ITM / LG |
403, 16E3, E316 |
F9E9 |
4.1.3 |
|
1st May 09 |
Hampshire TSHARC |
7DD |
1 |
4.1.6 |
|
Mar 2010 |
DMC |
AFA |
3E6 |
4.1.6/1389 |
|
Mar 2010 |
Zytronic X-Y |
14C8 |
3 |
4.1.6/1460 |
Costs
Internal signing
The cost of this
service is GBP 1500.00. This covers 2
days to process the tests against a supplied controller and GBP500 paid to
Microsoft as part of the WHQL acceptance process and digital signature
generation. Controller specific tests are also run as part of the WHQL
procedure and any failures with the pointer device hardware will prohibit the
allocation of a digital signature.
Before
requesting a UPDD digital signature the hardware must pass all Microsoft
hardware compatibility tests. If a failure occurs due to a compatibility error
then we will provide a report on the nature of the error and will perform 1
retest free of charge, so long as the retest is within one week of the original
test.
We
can perform a compatibility testing service for GBP 1000, in which we will run
tests on a single platform (usually Windows Vista 32 bit) and provide results
as many times as required in a 2 week period. In this case, assuming the final
test run is successful this can be used for a WHQL submission and submission
cost will be GBP 1000.
It
is important to note that the signature is for a specific kernel driver version
and in the event that a later kernel driver version is required then a new
digital signature will be required. The same charges will apply.
External signing
Where we are supplied signed files for embedding in driver packages there will be an hourly charge to cover the embedding work. As long as the guidelines above have been followed this time should be minimal, say 4 to 8 hours. However, if the guidelines are not followed and extra work is required to utilize the delivered files then time taken will inevitably be longer.
Contact
For further information or technical assistance please email the technical support team at technical@touch-base.com