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 |
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 |
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 |
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 |
In reply to this post by Anthony Foiani
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." 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. 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 |
Free forum by Nabble | Edit this page |