Table of Contents Introduction Where do these USB/VID_... certificates come from? How can I find the application that installed these certificates? Why are these certificates installed without asking? Isn't the silent installation of a trusted certificate a security risk? How can I delete these certificates? Technical description of the signing process

If you ended up on this page, you most likely clicked the "Issuer statement" button, from a certificate that was labelled something like USB\VID_... (libwdi autogenerated), and which you found installed as a Trusted Root Certification Authority or Trusted Publisher on your machine.
If so, you may be wondering what these certificates are for, and how they got installed onto your system.

This Certification Practice Statement attempts to answer these questions.

The certificates are generated by libwdi, which is a library aiming at facilitating the installation of USB drivers on Windows. They are being installed to the Trusted Root Certification Authorities and Trusted Publishers system stores as these stores are used in the validation of driver packages created by libwdi based applications, to avoid prompts such as following, from appearing during a driver installation:

The reason libwdi attempts to remove these prompts is because they serve little legitimate purpose and are more of an annoyance than anything else for end users. As a matter of fact, a prompt like the one above will appear even if you use Microsoft's own WinUSB driver files, to install a generic USB device, and this despite the fact that all the WinUSB driver files are digitally signed by Microsoft. Therefore, on Vista and later, you end up in the ridiculous situation where even a driver package, that only contains Microsoft certified binaries, is flagged by Microsoft as something that could be harmful.
Because libwdi expects prompts such as the one above to be confusing to end-users, it does take steps to ensure that, when installing a generic driver that can be trusted (WinUSB, libusb0 or libusbK, since they are all digitally signed with a Microsoft Authenticode digital signature and come from a reputable source), the security warning does not occur. In order to do so however, a libwdi based application needs to install an auto-generated certificate for each device, and this is the reason why you find these auto-generated certificates in your machine's certificate stores.

As mentioned above, the certificates are generated by libwdi, but libwdi is only a library, which may be used by a whole range of applications that require generic access to an USB device. As such, it is impossible for us to list the name of all the applications that may install the USB\VID_... certificates. Our current knowledge of the most common libwdi-based applications likely to install such certificates include:

1. Zadig from the original libwdi project
2. inf-wizard.exe from libusb-win32
3. inf-wizard.exe from libusbK

We did consider prompting end-users at least once, before installing the certificates, but we decided not to after considering that libwdi would end up being used by people who have no idea about PKI or certificates, and may not understand the choices being presented to them.
While it is true that, in most situations, an application should never go around installing trusted certificates without asking the user, because this may leave somebody else with the ability to sign malicious trusted binary packages, we consider that the certificates from libwdi are a special case because:

1. The private key for the certificate is generated at runtime, on the end user machine, and is not accessible to any other application.
2. Right after the driver package has been signed, the private key is destroyed. This effectively means that the certificate cannot be used for anything but to validate driver package that was signed by libwdi, that one time. As a matter of fact, even if you re-install the exact same device using the same driver, you will find that libwdi generates a brand new certificate (and a brand new temporary private key), because even a libwdi application can not reuse an old certificate for anything else but validating the original driver package.

We do take security matters very seriously and that is the reason why we implemented the no-reuse policy above. It has the the obvious drawback of multiplying certificates (one for each device) but this is all done for the sake of making sure that the security of an end-user machine can never be compromised from having used libwdi. Also, since libwdi is Open Source, we invite anyone who wishes to do so, to look at our PKI implementation to confirm for themselves that, despite the additional certificates being added as trusted, the system's security is not being diminished in any way.

Finally, because the certificates can only be installed from an application running in elevated mode, which means that the end-user first has to indicate that he or she trusts the application operation, we consider that the user also provides consent for the installation of certificates in the trusted stores, which is one of the operations the application needs to perform to ensure ease of use. As you can see, we have also made sure that our Certification Practice Statement (this page) is accessible from just a click when viewing the certificates, to be as open as possible about our installation process.

If you find that you no longer plan to use the USB device the certificates were attached to, you can easily delete them, through one of the following methods. Note however that, because they are installed into the system rather than the user stores, a certificate management application may have to run in elevated mode to be able to perform deletion.

• Internet Explorer:
  • Right click on your internet explorer shortcut and select 'Run as administrator'
  • Select 'Internet Options' → 'Content' tab and click on the 'Certificates' button
  • Navigate to either of the 'Trusted Root Certification Authorities' or 'Trusted Publishers' tab, then select the USB\VID_... certificate you want to delete and click the 'Remove' button
• CertMgr:
  • Select Run and type certmgr.msc
  • Navigate to either of the 'Trusted Root Certification Authorities' or 'Trusted Publishers', then right click on the USB\VID_... certificate you want to delete, and select 'Delete'

Here is how the signing process of a driver package occurs in a libwdi based application:

1. The driver files (.sys, .dll) are extracted
2. A .inf file is auto-generated, according to the device being targeted as well as the driver selected by the user. It is because the content of this .inf file cannot be determined beforehand, and because .inf files are being hashed in a .cat file that we need to also generate a new .cat.
3. A .cat file is auto-generated, with the hashes of all the relevant files referenced by the .inf including the .inf file itself.
4. A new keypair is generated on the end user machine, and is used to generate a self-signed root certificate.
5. The certificate is installed in the Trusted Root Certification Authorities (Root) and Trusted Publishers system stores
6. The .cat file is signed
7. The private key is destroyed

For more info, see the CreateCat() and SelfSignFile() function calls from libwdi/pki.c.