Why I can no longer sign Windows kernel-mode drivers with a vendor certificate?
TUSBAudio DFU vs. TL-USBDFU - What's the difference?
Why do I need a USB Vendor ID and USB Product ID?
How to get unique VID and PID identifiers for a (planned) USB product?
Why do I have to customize a device driver provided by Thesycon?
Why should I use unique VID/PID identifiers for a Linux Gadget based product?
What is the difference between code signing and Windows Logo Signing (WHQL)?
What's the purpose of the static COM port feature in the TL-USBCOM driver?
Signing kernel-mode drivers with a vendor certificate issued by one of the commercial CAs requires a cross certificate issued by Microsoft. As of July 1, 2021 Microsoft discontinuous cross signing. This affects Windows 7 and 8/8.1 as these systems require a cross-signed driver. Windows 10 and 11 are not affected as drivers are to be attestation signed.
Consequently, any kernel-mode driver released for Windows 7/8/8.1 after July 1, 2021 requires WHQL signing (aka HLK/HCK). Driver packages created and digitally signed before July 1, 2021 continue to work.
See also:
Every shipping USB product is uniquely identified by a tuple of two 16-bit integer numbers: vendor ID (VID) and product ID (PID). Each number ranges from zero to 65536 (0x0000 to 0xFFFF). A USB device reports these numbers through its device descriptor in the fields idVendor and idProduct.
Operating systems (Windows, macOS, Linux) use the VID/PID tuple to locate the matching device driver, and to store device-specific configuration information (e.g. last volume set for a given device instance). Software applications such as configuration tools, firmware upgrade utilities, etc. typically rely on the VID/PID tuple to identify the device they have been designed for.
On Windows, any vendor-specific USB device driver will be loaded based on VID/PID identification. So a unique VID/PID tuple is essential for the operating system to locate the correct device driver.
If two different products share the same VID/PID tuple then an operating system will potentially load the wrong device driver, and another product's applications and utilities will possibly try to communicate with the device, perform a firmware update etc. This will lead to bad user experience and, in a worst-case scenario, can damage the device.
Hence it is mandatory to ensure that a unique VID/PID tuple is assigned to every distinct USB device type (model) that is shipping. Details on how VID and PID assignment is done in practice are given in the following sections.
The Vendor ID is globally unique and typically identifies the manufacturer or distributor of the device. To ensure uniqueness globally, VIDs are managed and assigned by the USB Implementers Forum organization (http://www.usb.org). To receive a VID, you have to contact the USB Implementers Forum, see http://www.usb.org/developers/vendor/.
Any shipping product must use the official VID assigned by the USB Implementers Forum to the product's manufacturer.
In some cases it is possible to use the VID of a silicon vendor. However, this requires registration with the silicon manufacturer or distributor to receive a unique PID. Never re-use the VID/PID of an evaluation board or reference design!
Thesycon allows licensees to use the VID registered for Thesycon. This requires registration with Thesycon because Thesycon manages the PID range and needs to assign a unique PID.
The owner of a VID manages the corresponding PID range. PIDs can be assigned arbitrarily but need to be chosen in such a way that every shipping USB product uses a unique VID/PID tuple. Make sure you choose a unique PID for each new device model and carefully keep records on PID assignments.
There are several ways to receive a unique USB VID and PID:
1) Register with the USB Implementers Forum (http://www.usb.org) to receive a unique VID (charges apply), see http://www.usb.org/developers/vendor/. Then assign a unique PID for each product.
2) For licensees, Thesycon offers PIDs from Thesycon’s officially registered VID space. This service is free of charge.
3) Some silicon manufactures provide customers with unique PID assignments within their officially registered VID space.
Thesycon provides generic device drivers which cannot be used directly. Before the driver can be used with a specific USB device and shipped as part of a product, it needs to be customized. The customization procedure includes:
Note that the customization procedure does not modify the driver binary executable files (.sys, .dll) itself. The executable files are created and shipped by Thesycon and will not be modified afterwards.
Customization is a mandatory step. Any shipping driver package must be a fully customized driver package. Otherwise, there is a risk that name clashes, ambiguities or other conflicts occur when the driver is used in the field. This is because Thesycon’s drivers are shipped with many different products and there is a chance that an end user installs two (or more) of such products on the same Windows system. If every product uses a fully customized driver then multiple products can be installed and used in parallel without causing conflicts.
For a Linux based device, USB Gadget provides an easy way for implementing USB device functionality. The Gadget software stack comes with pre-configured VID and PID values. If a Gadget based USB device has to work with a vendor-specific device driver on Windows then the default values have to be replaced by unique VID/PID identifiers. This is because Windows locates vendor-specific drivers based on VID/PID identification. See also Why do I need a USB Vendor ID and USB Product ID?
Note that a USB device driver licensed from Thesycon, after customization, will be treated as a vendor-specific device driver by Windows.
Tip: You can check the VID/PID values implemented in your Gadget device by using: Thesycon’s USB descriptor dumper tool.
Our policy is not to license drivers for devices that reuse VID/PID identifiers from silicon manufacturers and which are typically used for microcontroller evaluation boards or similar. There are several reasons for this decision:
Any of these scenarios can cause unexpected behavior and create unwanted support efforts for Thesycon or the official licensee.
Conclusion: USB VID/PID identifiers must unambiguously identify a given device model. Reusing VID/PID identifiers from a silicon manufacturer's evaluation board creates ambiguity and a risk for bad user experience in the field. Also it makes unauthorized use of intellectual properties easier.
How to get an official USB VID, see section How to get unique VID and PID identifiers for a (planned) USB product?
The 64-bit (x64) variants of Windows require that any kernel-mode component contains a digital cryptographic signature created with a so called kernel-mode code signing certificate. If there is no such signature or the respective certificate is not valid, Windows will not load the driver. A code signing certificate is issued to a particular entity (enterprise or individual). So if a given driver package has a valid signature, an end user can be sure that this software has been released by that entity, and that the software was not altered since it was released. Basically, this is a good thing and therefore Thesycon recommends to digitally sign all driver files before they are released, irrespectively whether the driver is for use on x64 Windows or not.
Note that code signing is not to be confused with Windows Logo testing (sometimes also called WHQL, HLK, HCK, or Windows Hardware Certification). For code signing no specific logo testing is required and no test results need to be submitted to Microsoft. Code signing does not verify driver or device functionality in any way.
Depending on the target operating system (i.e. the system where the driver is to be installed by end users) there is one of two digital signature variants required:
Signing kernel-mode drivers with a vendor certificate issued by one of the commercial CAs requires a cross certificate issued by Microsoft. As of July 1, 2021 Microsoft discontinuous cross signing. This affects Windows 7 and 8/8.1 as these systems require a cross-signed driver. Windows 10 and 11 are not affected as drivers are to be attestation signed.
Consequently, any kernel-mode driver released for Windows 7/8/8.1 after July 1, 2021 requires WHQL signing (aka HLK/HCK). Driver packages created and digitally signed before July 1, 2021 continue to work.
Windows 10 requires that a kernel-mode driver is digitally signed by Microsoft using a code signing certificate that is owned by Microsoft.
Note that the attestation signing requirement is enforced only by Windows 10 version 1607 and later, and only under specific circumstances such as UEFI secure boot set to ON. For more details on attestation signing enforcement, you may refer to the article Driver Signing Policy.
As an alternative to code signing you can execute the Windows hardware and driver certification process. This requires that you run extensive driver tests using the Windows Hardware Lab Kit (HLK) and submit test results to Microsoft. If the driver and the device pass certification then Microsoft digitally signs the driver with a WHQL publisher certificate.
Note that Thesycon offers WHQL certification as a service. For more information or to request a quote, please contact Thesycon.
Some legacy applications are not able to handle COM ports which appear and disappear dynamically when the USB cable is plugged or unplugged. Such applications assume that a COM port is a static resource which is always available. To support such legacy applications, TL-USBCOM driver provides a special feature which emulates the behavior of a legacy static COM port.
It's important to understand that the static COM port feature is a work-around for legacy application behavior. It should be used only if all of the following conditions apply:
Static COM port behavior is optional and needs to be enabled via driver configuration settings. Contact Thesycon for more information.
© 2024 THESYCON