> Then one might
> ask: is this even addressing the original need to know: on which
(trusted)
> bus is the CCID bound?
That is an easy question: when libusb is used the bus/node
identification is sent by pcscd to the driver so they both use the
same device. You can see it in the logs as:
hotplug_libusb.c:404:HPAddHotPluggable() Adding USB device: 002:072
bus = 002
node = 072
This information is defined by libusb and the format is OS specific.
lets say the LINUX host is providing a complete RDP v5 network service, and
a MS RDP client (with a local USB reader) binds as a remote desktop client.
This remoting session of course introduces the client host's reader onto the
Linux host's (virtual) USB controller(s). Something in the Linux/RDP server
must now identify said USB node.
In the case of Windows NT kernels, the whole terminal services redirection
infrastructure (supporting RDP and other secure remoting protocols) is
located in a mix of kernel and trusted application libraries. In Linux, by
contrast, perhaps RDP is just a user mode process, and the libusb value is
not vouched for by the TCB in the UNIX kernel.
But, even forgetting the complex case of an RDP-based connection of 2 CCIDs,
if two CCID readers are connected to a conventional host controller on a
given linux host, and both have the same PID/VID, surely then the original
request of our colleage is not satisfied: the two are not even
discriminated, by these numbers.
Of course, proprietary drivers might access proprietary unique serial
numbers in each CCID using a vendor APDU, as provisioned in each device by
the manufacturers. But, this is hardly standard way of identifying any CCID,
unambiguously - as our colleage seemed to want to do.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
