What are “Signed” Drivers?
Most USB drivers operate in what is known as “kernel mode” on Windows based PCs. Kernel mode drivers have low level access to the PC and its resources. This low level access to the PC is normally necessary to implement the kind of functionality that the driver is intended to provide to top level applications.
However, low level access to a PC has potential security implications. Kernel mode is typically the “ideal” place where malicious software developers would want their software to operate, since it provides the greatest control and access to the PC. Therefore, in the interest of protecting Windows security, Windows OSes place restrictions on what code is allowed to be operated in kernel mode.
Windows “trusts” drivers and executable programs that have been signed, more so than software that is unsigned. Signing a driver package is analogous to placing an embossed wax seal on an envelope. The signature/wax seal does not effect or alter the contents of the package, but it provides proof that the contents have not been modified or tampered with, since the time that the signature/wax seal was first applied.
There are three types of USB driver signatures to be aware of:
Embedded digital signatures: This type of signature resides inside of driver .sys files (kernel mode driver binary files). No additional/external files are associated with this type of signature. These types of signatures only protect against tampering with the .sys file itself, and do not include other files that may be a part of the driver package (ex: .inf and .dll files). All Microsoft OS provided driver .sys files, as well as most third party kernel mode drivers will contain at least this level of signature.
“Full driver package” digital signature – Microsoft Authenticode: This type of signature can be though of as a “wrapper” over the entire driver package content files. A driver package can be a simple as a single .inf file (a plain text installation instruction file that Windows uses when installing new drivers), or may encompass additional files (such as .dll and/or .sys files). The full driver package signature comes in the form of a properly created security catalog file (.cat), which will be part of the driver package distribution. A driver package signed with an Authenticode signature is relatively easy to create, but it less trustworthy to that of a WHQL digital signature.
“Full driver package” digital signature – WHQL: This type of signature is the most trusted by Windows, and is very similar to the full driver package Microsoft Authenticode signature above, but is more expensive and harder to obtain. To obtain a Windows Hardware Quality Labs (WHQL) signature, a driver package must undergo extensive testing, and passing log files and submission fees must be supplied to Microsoft. If a driver package has already previously been tested and WHQL certified, but has since been modified, in some cases it is possible to get the driver re-certified through a simpler and cheaper "Driver Update Acceptable" process with Microsoft.
Any modifications to a driver package once the signature has been applied, including adding or deleting a single character of whitespace in the driver .inf file, will invalidate a full driver package signature. A driver package can however have two simultaneous signatures, one covering the full driver package, and one embedded inside the driver binary file(s). Inf file modifications do not invalidate an embedded digital signature inside of a driver binary file.
Once a signature has been invalidated, Windows will no longer trust the driver package as much, and will place restrictions on its installation (or outright prevent its installation on some OSes). The driver package can however be re-signed, to restore the trustworthiness of the driver to Windows.
MLA - USB Library Help Version : 2.16
![]() |