Re: [Opensc-devel] Connecting to a specific USB device

[Ludovic R. <lud...@gm...>]

2013/7/17 Anthony Foiani <ant...@gm...>:
> Mat --
>
> On Tue, Jul 16, 2013 at 8:30 AM, Mat Arge <arg...@gm...> wrote:
>> Hello!
>>
>> I am tracking the connection of USB tokens via udev and want to do some
>> specific stuff with them (pass them through to certain virtual machines). For
>> that, I would like to get some token specifics (like the serial number or the
>> PKCS#11 label). So what I need is a connection (preferably with PKCS#11) to
>> the just inserted token. The problem is, that at the udev level where I am, I
>> only know the USB BUS Id, the vendor ID and such stuff. Is there some way to
>> get a PKCS#11 or pc/sc connection to the correct token?
>
> A quick look through the pcsc-lite stuff is discouraging; it seems
> that a string describing the specific port is indeed stored in the
> reader context structure, but there doesn't seem to be any existing
> way to get it out.
>
> See line 213 of:
> http://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/src/readerfactory.c?revision=6668&view=markup
>
> For lilbusb, that "device" value is ultimately generated around line 516 of:
> http://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/src/hotplug_libusb.c?revision=6557&view=markup
>
> But I don't see any place where that value can be accessed.

Exact. And that PC/SC information needs to come from the PKCS#11 layer.

> (But I'm certainly not an expert on this; I've just hacked a few
> things onto the source as I needed them -- see next point.)
>
> The cleanest way might be a vendor-specified attribute, but as the
> comment at the top of p11_attr.c says: "The number of layers we stack
> on top of each other here is frightening."
>
>> Or the other way round: Is there some way to find out for an existing
>> pcsc/pkcs11 connection which hardware address it is leading to?
>
> It's not exactly what you're looking for, but I did propose a patch to
> pcscd that restricted it to a particular USB port:
>
> http://opensc.1086184.n5.nabble.com/FYI-PATCH-restrict-pcscd-to-a-single-USB-port-path-td13800.html
>
> Worst case, your udev script could:
> 1. if it looks like a crypto token ...
> 2. spawn a pcscd that looks only at that port...
> 3. then query that specific pcscd to get label etc...
> 4. kill the pcscd...
> 5. bind the port to the VM appropriately.

If once attached to a VM the USB token is no more available for the
host then pcsc on the host will not see it anymore. And then OpenSC
will not see the token either.
So a new PKCS#11 token detected by OpenSC will only be a newly
connected USB token.

You would not be able to connect a new token until the previous one is
attached to a VM.

Maybe your USB tokens have different USB serial numbers so you can
differentiate them?

> Not pretty, and not fast (pcscd takes a few seconds to come up even on
> my fast hardware, but maybe I just don't know how to strip out
> unnecessary bits).

pcscd should be fast to boot. On an ARM9 CPU I measured 0.3 second. See [1].
Maybe you are using a smart card reader that is slow to boot.

Bye

[1] http://ludovicrousseau.blogspot.fr/2010/08/ram-and-cpu-improvements-in-pcsc-lite.html

-- 
 Dr. Ludovic Rousseau