SmartCard reader "Access denied" while claiming interface with Webusb on chrome - google-chrome

Question

I am developing a javascript library to perform smart card operations using the CCID protocol over chrome webusb API. Everything goes well when I plug the smart card reader on Linux and MacOS, however I get stuck on windows when I try to claim the interface.
I tried to run chrome as an administrator, disable smart card services /
CCID drivers on windows in case those were claiming the interface, but nothing does it. I keep having the
"Failed to claim interface: Access denied (insufficient permissions)"
message. Is it really a permission problem ? Or is it some windows service I am not aware of blocking the access ?
Edit: I tried on another mac, on which the reader didn't work. After removing the specific vendor id / product id from the CCID driver info.plist, I managed to make it work. So I suppose the same problem is happening on windows, a CCID driver is "blocking" the access interface. What are my alternatives ?
The device descriptor:
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1a44 VASCO Data Security International
idProduct 0x0001 Digipass 905 SmartCard Reader
bcdDevice 1.02
iManufacturer 1 VASCO
iProduct 2 DP905v1.1
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 93
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 11 Chip/SmartCard
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
ChipCard Interface Descriptor:
bLength 54
bDescriptorType 33
bcdCCID 1.00
nMaxSlotIndex 0
bVoltageSupport 3 5.0V 3.0V
dwProtocols 3 T=0 T=1
dwDefaultClock 3700
dwMaxiumumClock 3700
bNumClockSupported 1
dwDataRate 9946 bps
dwMaxDataRate 318280 bps
bNumDataRatesSupp. 53
dwMaxIFSD 254
dwSyncProtocols 00000007 2-wire 3-wire I2C
dwMechanical 00000000
dwFeatures 000404BE
Auto configuration based on ATR
Auto activation on insert
Auto voltage selection
Auto clock change
Auto baud rate change
Auto PPS made by CCID
Auto IFSD exchange
Short and extended APDU level exchange
dwMaxCCIDMsgLen 272
bClassGetResponse echo
bClassEnvelope echo
wlcdLayout none
bPINSupport 0
bMaxCCIDBusySlots 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 0

Answer 1

The insight in your edit is correct, if the CCID driver is blocking access to the device then Chrome cannot access it. In addition on Windows the operating system must know to load the WinUSB.sys driver (which comes with Windows) against the device or else any userspace application such as Chrome cannot access it. This can be accomplished using an INF file like this one or by adding Microsoft OS descriptors to the device to set the "compatible ID" to "WINUSB".
If you are building your own device the latter option is preferable as it will provide plug-and-play support for your users while the former still requires a manual installation step for Windows users.
If you are working with an existing device but have control over the Windows system then, similar to editing the Info.plist for the macOS driver, you can go into the Windows Device Manager and replace the existing driver with WinUSB.sys using an INF file like the above.

Answer 2

I'm pretty new to this but as far as i can see when a native driver takes hold of your USB device, your lost and there is nothing the browser can do about it. It seems a fix could be to change the vendor or product ID (if you can do this) so no native driver will claim your device. If this is not a solution, a chrome app has much more possibilities and might be able to overcome the problem.