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:
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?
Kernel Mode Code Signing Overview
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:
Vendor Signing (Windows 7/8/8.1)
To create a vendor signature, you need to buy a code signing certificate from one of the established authorities. Please refer to the Microsoft article Get a code signing certificate.
While a standard code signing certificate is sufficient for kernel-mode drivers on Windows 7, Windows 8 and Windows 8.1, Thesycon recommends buying an extended validation (EV) code signing certificate. This is because an EV certificate is needed to perform Microsoft attestation signing as required for Windows 10.
Microsoft Attestation Signing (Windows 10)
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.
Windows Logo Signing (WHQL)
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.
In Windows 7 there are some issues with SHA-256 code signing certificates as described in the following subsections.
Operating systems: Windows 7 32/64 bit
Problem description: By default, Windows 7 does not accept SHA-256 code signatures, it accepts SHA-1 signatures only. However, SHA-1 based certificates are deprecated and not available any longer. All recent code singing certificates use the SHA-256 algorithm.
Microsoft has released a hotfix that adds support for SHA-256 certificates on Windows 7. The hotfix KB3033929 can be found here: https://support.microsoft.com/en-us/kb/3033929
Note that KB3033929 is available through Windows update. So the easiest solution is to make sure this update is installed.
Additional information:This problem does not exist on Windows 8 and later. If the Thesycon driver installer (v1.12 and later) is used then setup.exe detects this problem during driver installation and shows an error message which references the KB3033929 patch.
Operating systems: Windows 7 32/64 bit
Problem description: Normally, Thesycon’s driver installer suppresses the "Untrusted publisher" dialog box. However, if the driver that is installed is signed with a SHA-256 code signing certificate then Windows 7 may still show this dialog box. Although you selected the "Always trust" option, the dialog box may reappear during a subsequent driver installation.
This is an issue in Windows 7. For more information and a hotfix, check out KB2921916: https://support.microsoft.com/en-us/kb/2921916
Additional information: KB2921916 is not available through Windows update.
RNDIS (Remote NDIS) is a proprietary protocol based on Microsoft's internal network driver interface used in the Windows kernel. Thesycon’s network driver does not support RNDIS. The driver supports the network emulation protocols defined by the USB Implementers Forum as part of the USB Communications Device Class (CDC) specification. Specifically, the driver implements CDC/ECM (Ethernet Control Model), CDC/NCM (Network Control Model), and CDC/EEM (Ethernet Emulation Model).
If you experience problems with the Windows in-box RNDIS driver, Thesycon recommends to switch to one of the CDC protocols. If the device implementation is Linux based, this should be easy because Linux includes CDC/ECM and CDC/NCM modules as part of the Gadget USB device stack. If no specific requirements on data throughput exist, Thesycon recommends using CDC/ECM because it is the simplest protocol. In specific scenarios (e.g. exchange of small packets at a high packet rate) better data throughput can be achieved with CDC/NCM.
Other operating systems such as Linux and macOS include CDC/ECM and CDC/NCM class drivers.
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.