WinUSB communication with STM32 (Part 3: Driver)

WinUSB driver must be linked to device. This means creating a driver INF file specifying WinUSB as driver for device with specific USB VID and PID. To complicate a bit further this information needs to be signed. That is done by signing a catalog file (CAT) created from INF file. Windows Driver Kit (WDK) includes all the tools to do it.

Driver (code) signing was introduced to help prevent the installation of software that is not trusted. From what I understand about driver signing is that Windows trust some global certificate authorities (CA). They then issue a code signing certificates containing the publishers' information to software publishers. By this they are saying that the publisher was verified by them. They do it manually like call the person/company which issued a request for certificate and verify their information. For this they charge a yearly fee. The result is a class 3 certificate which publisher uses to sign his software. On installation/execution Windows pop up a dialog asking if you trust the publisher named as specified in signature of the executable which you wish to install/run. Publisher can also send his driver directly to Microsoft for testing and signing. It is called WHQL Testing. I'm not sure but I think that drivers tested and signed by MS are installed without any warnings. Read more about it on wiki. And I believe this isn't free either.
Free of charge alternative is an open source code signing certificate issued by same trusted CA (e.g. http://www.certum.eu). The requirement is that "Open source" keywords are stated in certificate information (e.g. the Name field of certificate is "<publisher name>. Open Source Developer")

Another free of charge alternative for debugging is so called self-signed certificate. This is a certificate created by developer. I created a script that:

1. creates the certificates,
2. copies the redistributables from WDK,
3. creates usbID.h file containing the IDs for USB descriptor which must match the INF file,  
4. creates the INF file,
5. checks the INF file,
6. creates the CAT file from INF file and
7. signs the CAT file with created certificate

I did this rather than publish a driver ready to install because it depends on personal information. Well I could distribute my self-signed certificate but I don't own a USB vendor ID. And since you have to have your own in the INF file the signed driver is no use to you because you must change it.

USB Vendor ID is another story to this. If you are serious and plan to sell USB devices you should apply for USB VID. It will be assigned to you after one time purchase. To additionally use the USB logo on the device you must pay a yearly fee... I think.

The script actually creates two certificates. First is your CA certificate. Second is code signing certificate issued by your CA. I omitted the installation of created CA certificate to "Root trusted certificates" because it seems to make no difference. First I thought that there will be no warnings if I put the created CA certificate next to other trusted CAs. But the Windows still pop up even more annoying warning saying that publisher can not be verified. I also tried generating the certificates with OpenSSL with no success.

Anyway, driver installation completes successfully if you choose to install anyway. The device is then displayed in the Device Manager as shown below.

Automatic installation can be done with dpinst.exe toll (part of WDK redistributables). But I didn't deal with why dpinst warning pops up saying that the publisher of dpinst is unknown. Maybe because it was ran from script?

To see details of all operations see the script.

This is the third post in this series (of total 4 posts). See 1, 2, 4.

[Update - I have a new WinUSB device project with STM32F407 without the need for Windows side driver info (.inf and .cat files) ]