Connecting to a specific USB device

[Mat Arge]

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?
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?

cheers
Mat


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Anthony Foiani]

Mat --

On Tue, Jul 16, 2013 at 8:30 AM, Mat Arge <[hidden email]> 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.

(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.

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).

But it should work.

Good luck!

Tony

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Ludovic Rousseau]

2013/7/17 Anthony Foiani <[hidden email]>:

> Mat --
>
> On Tue, Jul 16, 2013 at 8:30 AM, Mat Arge <[hidden email]> 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

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Anthony Foiani]

Ludovic, greetings --

On Fri, Jul 26, 2013 at 8:08 AM, Ludovic Rousseau
<[hidden email]> wrote:
> 2013/7/17 Anthony Foiani <[hidden email]>:
>> But I don't see any place where [the saved device name/path] can be accessed.
>
> Exact. And that PC/SC information needs to come from the PKCS#11 layer.
...
>> 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."

Might it be as simple as defining some CKA_OPENSC_DEVICE_PATH, and
returning the recorded device name/path info when queried for that
attribute?  (Or am I missing a layer?)

> 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.

Nice!  Very elegant, other than the "at most one unbound token at any
given time" limitation.

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

The original poster mentioned serial numbers as an option:

>> On Tue, Jul 16, 2013 at 8:30 AM, Mat Arge <[hidden email]> wrote:
>>> 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).

But it would be nice to be able to get physical location / connection
data at the PKCS11 layer, especially since we already record it.

The whole point of a label is to allow the use of meaningful names;
allowing only serial numbers means that users now need to track
numbers-to-meaning in some other way.

Ah, and I didn't even catch "*USB* serial numbers".  For what it's
worth, the tokens that I'm using in my current project do not support
USB serial numbers, only PKCS11 serial numbers.

> 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.

Apologies for the misinformation.  It is indeed quite fast on my fast
hardware (modern x86-64 desktop).  Not sure where I got the "slow"
from -- maybe on my 266MHz PPC32 embedded box that is busy doing other
stuff in other threads as it tries to run pcscd as well...

I was wrong.  Again, apologies.

Best regards,
Anthony Foiani

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[Mat Arge]

Hy!

Sorry for bringing that old subject back up. I had to do some other work in
between, but now really need a solution, which I haven't found yet.

On Wednesday 17. July 2013 13:46:01 Anthony Foiani wrote:

> Mat --
>
> On Tue, Jul 16, 2013 at 8:30 AM, Mat Arge <[hidden email]> 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?rev
> ision=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?r
> evision=6557&view=markup
>
> But I don't see any place where that value can be accessed.
>
> (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."

I am considering writing a patch for pcscd, which writes information about the
interface used when a connection is created into a structured file. Ludovic,
would such a patch we acceptable for upstream?

>
> > 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.
>
> 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).
>
> But it should work.

That's interesting, too. As far as I can see, it was never actually merged
upstream, was it?

cheers
Mat
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel