Advancing Windows driver security: Removing trust for the cross-signed driver program

[bgsw-venkat]

According to the Microsoft article
“Advancing Windows driver security: Removing trust for the cross-signed driver program”
(https://techcommunity.microsoft.com/blog/windows-itpro-blog/advancing-windows-driver-security-removing-trust-for-the-cross-signed-driver-pro/4504818),
Microsoft is removing trust for kernel drivers that have not gone through the Windows Hardware Compatibility Program (WHCP).
Currently, we are using libusbk for one of our devices with our own driver signing.
We would like clarification on the following points:

• Is there a confirmed end date after which cross-signed kernel drivers will no longer be trusted?
• Is Microsoft’s signing/approval of the generic libusbk driver sufficient, or does the device-specific INF file also need to be signed by us (or submitted through WHCP)?
• Are there any recommended migration steps or best practices for libusbk-based devices in this context?

Any guidance or references would be greatly appreciated.

[mcuee]

1. Is there a confirmed end date after which cross-signed kernel drivers will no longer be trusted?

No clear info. However, as per the following article, some systems may enforce new policy and make libusbK driver not installable after April 2026.
https://techcommunity.microsoft.com/blog/windows-itpro-blog/advancing-windows-driver-security-removing-trust-for-the-cross-signed-driver-pro/4504818

2. Is Microsoft’s signing/approval of the generic libusbk driver sufficient, or does the device-specific INF file also need to be signed by us (or submitted through WHCP)?

You may need to upload the whole driver package and go for Attestation signing process. You need to have an EV certificate.
https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-attestation

After the signing, you should be able to get a fully signed package, including signed libusbK.sys and a signed CAT file.

3. Are there any recommended migration steps or best practices for libusbk-based devices in this context?

We recommend users to migrate to WinUSB driver. Any reason you are still using libusbK driver?

[mcuee]

Are there any recommended migration steps or best practices for libusbk-based devices in this context?

We recommend users to migrate to WinUSB driver. Any reason you are still using libusbK driver?

If for some reasons you cannot use WinUSB, you can still use libusb-win32 driver as it has gone through Microsoft Attestation signing process.

Latest version.
https://github.com/mcuee/libusb-win32/releases/tag/release_1.4.0.2

[mcuee]

One advantage of using WinUSB, there is a work-around to use inbox WinUSB.inf for ARM64, without using Zadig which is not working currently under Windows 11 ARM64.

• Windows 11 on ARM64 Support pbatard/libwdi#289 (comment)

[bgsw-venkat]

Are there any recommended migration steps or best practices for libusbk-based devices in this context?

We recommend users to migrate to WinUSB driver. Any reason you are still using libusbK driver?

Thanks for quick reply.
The device was developed around 10 years ago. At that time, we faced several issues with WinUSB—primarily related to device detection during electromagnetic compatibility (EMC) testing. These issues were resolved by switching to libusbk.
We are not sure about the current state or improvements in the latest WinUSB driver. Migrating back would require significant re-validation and testing, especially since the device is still actively used by a large number of customers.

If for some reasons you cannot use WinUSB, you can still use libusb-win32 driver as it has gone through Microsoft Attestation signing process.

Latest version. https://github.com/mcuee/libusb-win32/releases/tag/release_1.4.0.2

May i know the difference between libusb-win32 and libusbk?

[mcuee]

May i know the difference between libusb-win32 and libusbk?

https://libusbk.sourceforge.net/UsbK3/usbk_comparisons.html

libusbK.sys advantages when compared to libusb0.sys:

• Winusb-like power management.
• Winusb-like pipe policies.
• Driver-level asynchronous transfer timeouts.
• Improved isochronous transfer support.
• Newer, more robust KMDF based design.

libusbK.sys disadvantages when compared to libusb0.sys:

• Does not support multiple configurations.
• Does not support a "filter driver" mode.
• Significantly larger device driver installation packages.
• Less tolerant of usb devices which or not fully compliant with usb specifications.

libusbK.sys advantages when compared to WinUSB.sys:

• Full isochronous transfer support. (Note: WinUSB supports isochronous transfer since Windows 8.1)
• Supports of XP64, Windows 2003, and Win2K (unofficial, see above comments)
• Supports device reset.
• Open source nature can eliminate the need for UDMF solutions.
• Allows proccesses concurrent access to the same device.
• Smaller driver installation packages.

libusbK.sys disadvantages when compared to WinUSB.sys:

• libusbK will not function as a lower filter driver of a UDMF driver as WinUSB.sys will.
• WinUSB is pre-packaged with Vista and up.
• Windows 8 and later has native support for WinUSB devices (WCID)

[mcuee]

The device was developed around 10 years ago. At that time, we faced several issues with WinUSB—primarily related to device detection during electromagnetic compatibility (EMC) testing. These issues were resolved by switching to libusbk. We are not sure about the current state or improvements in the latest WinUSB driver. Migrating back would require significant re-validation and testing, especially since the device is still actively used by a large number of customers.

I see, in this case, I think it is better to go for Attestation signing process for your libusbK.sys based device driver package. You need to have an EV certificate.
https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-attestation

We do not have access to an EV certificate now.

[bgsw-venkat]

Thanks @mcuee , we are considering attestation signing as an option. But I see the project is built with older WDK, which Microsoft may not allow for signing. So, is it possible to migrate to latest WDK 10 version?

[mcuee]

Thanks @mcuee , we are considering attestation signing as an option. But I see the project is built with older WDK, which Microsoft may not allow for signing.

Try it and let us know.

So, is it possible to migrate to latest WDK 10 version?

Unfortunately that may not happen any time soon, or may never happen. Travis and I kind of already decided to focus on WinUSB driver in 2021.

• New release of libusbk will come with signed 3.0.7.0 version of libusbk.sys #26

PR will be welcome though if you or the community want to further the development of libusbK.sys kernel driver.

[mcuee]

PR will be welcome though if you or the community want to further the development of libusbK.sys kernel driver.

Actually there is already a PR.

• Add ARM64 target to all projects, upgrade driver project to VS2022 and latest WDK for x64 and ARM64 build + minor corrections (typos) + Upgrading to latest VS2022 toolset for all projects #52

I have merged the pull request and another PR. Please try latest git. Thanks.

[pmzgre]

Dear libusb community,
We have a full product family that uses libusbk driver. It seems not feasible to move to WinUSB because WinUSB limitation in isochrone mode.
Therefore, we are very interested to have libusbk maintained with the possibility to activate a MicroSoft signing process.

[mcuee]

Dear libusb community, We have a full product family that uses libusbk driver. It seems not feasible to move to WinUSB because WinUSB limitation in isochrone mode. Therefore, we are very interested to have libusbk maintained with the possibility to activate a MicroSoft signing process.

You need to build libusbk by yourself, prepare your own driver package and submit to Microsoft for attestation signing. We at libusbK project do not have the necessary EV certiticate to do that so we cannot help.
https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/code-signing-attestation

[pmzgre]

Thanks @mcuee. We do consider attestation signing using our EV certificate. The exercise will be new to us. Any chance that the binary libusbk.sys v3.0.7.0 will pass the attestation signing ? Or you think we need to rebuild with WDK and VS2022 ? If so, it is related to the issue #62 ?
Thanks.