Re: [opensc-devel] minimal requirements for working with crypto tokens?
2012/12/6 Anthony Foiani anthony.foi...@gmail.com: Greetings, all. Hello, As with a similar posted in the last day or two, I'm working deploying an embedded linux system, and I'm trying to figure out the smallest set of libraries that I need to do this. The desired use for tokens in the field is: 1. Sign binary blobs, generating a detached RFC5652 signature file from each data file. 2. (Eventually) for both client and server-side SSL handshaking. On a typical Linux workstation, I can do all this already, thanks to the developers here and on libusb, ccid, and pcsc-lite. Barring late-breaking changes, this functionality is already available in packages for the distribution I'm using here (Fedora 17). To test the latest and greatest, I had to build: libusb-1.0.9 pcsc-lite-1.8.6 ccid-1.4.8 openssl-1.0.1c libp11-0.2.8 opensc-0.13.0rc1-g2895729 (from CardContact) engine_pkcs11-0.1.8 Other than having to adjust the interprocess expectations of pcscd and its users, that also works fine. However, the embedded box is not running the typical workstation daemons. There's no udev at all; I'm handling the event stream directly within my application. (E.g., I'm receiving and handling USB mass storage device insertions / removals.) What I'm looking for is guidance on which libraries are required to do the work, if I can tell those libraries exactly which USB device to use, and only when there is something there to be used. Is libusb used only for discovery, or for access as well? Likewise, if there is only ever one process accessing the token (and I can guarantee that it's single-threaded access), then is pcscd necessary? libusb (or udev but you do not use it) is used by pcscd to discover USB readers. libusb is used by libccid to access the USB readers. You can write your own simpler pcscd if you want. Even further, if I know exactly which token will be used, is it possible and/or advisable to short-circuit the generic aspects of libpkcs11 and somehow use that token's driver directly? The question is: why would you change existing and working code? What is the problem with the existing programs? Bye -- Dr. Ludovic Rousseau ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] minimal requirements for working with crypto tokens?
Ludovic -- Thank you for the quick and thorough response. My apologies that I wasn't able to reply sooner. On Thu, Dec 6, 2012 at 5:23 AM, Ludovic Rousseau ludovic.rouss...@gmail.com wrote: libusb (or udev but you do not use it) is used by pcscd to discover USB readers. libusb is used by libccid to access the USB readers. That makes sense. Thank you for making it clear. You can write your own simpler pcscd if you want. ... The question is: why would you change existing and working code? What I actually want to do is to limit the capabilities of the existing code; the question in my head is whether it's easier to rewrite, or if it's possible to configure (either compile or run time) the specific and limited behaviors I want. In particular: 1. Limit crypto tokens to exactly one USB port, instead of scanning all of them. The selection of USB port can change at runtime, though. 2. Get insertion / removal notifications fairly quickly, and in a fairly lightweight manner. the pkcs11- and pcks15-tool programs seem to be able to get status, so that's obviously doable with pcscd, so I'll have to investigate that. What is the problem with the existing programs? Deployment complexity, primarily. Having another program running is another program that I have to run a watchdog for, and restart upon failure, etc. This instrument has only one userspace process running; adding another one will actually increase the complexity quite a bit. Additionally, we're building the root image from scratch, so we also have to configure and cross-compile all necessary libraries and executables. The fewer of those we need, the better off we'll be. Regardless, thank you very much for the tips, and I'll investigate from here. Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] minimal requirements for working with crypto tokens?
Greetings, all. As with a similar posted in the last day or two, I'm working deploying an embedded linux system, and I'm trying to figure out the smallest set of libraries that I need to do this. The desired use for tokens in the field is: 1. Sign binary blobs, generating a detached RFC5652 signature file from each data file. 2. (Eventually) for both client and server-side SSL handshaking. On a typical Linux workstation, I can do all this already, thanks to the developers here and on libusb, ccid, and pcsc-lite. Barring late-breaking changes, this functionality is already available in packages for the distribution I'm using here (Fedora 17). To test the latest and greatest, I had to build: libusb-1.0.9 pcsc-lite-1.8.6 ccid-1.4.8 openssl-1.0.1c libp11-0.2.8 opensc-0.13.0rc1-g2895729 (from CardContact) engine_pkcs11-0.1.8 Other than having to adjust the interprocess expectations of pcscd and its users, that also works fine. However, the embedded box is not running the typical workstation daemons. There's no udev at all; I'm handling the event stream directly within my application. (E.g., I'm receiving and handling USB mass storage device insertions / removals.) What I'm looking for is guidance on which libraries are required to do the work, if I can tell those libraries exactly which USB device to use, and only when there is something there to be used. Is libusb used only for discovery, or for access as well? Likewise, if there is only ever one process accessing the token (and I can guarantee that it's single-threaded access), then is pcscd necessary? Even further, if I know exactly which token will be used, is it possible and/or advisable to short-circuit the generic aspects of libpkcs11 and somehow use that token's driver directly? Either way, it seems that I'll still want to use OpenSSL libraries (or equiv, e.g., NSS) to do the ASN.1 streaming and on-cpu crypto ops. (This is the easiest part, as I already have OpenSSL in my build.) Are all these questions stupid, and do I need to be hit over the head with a heavy book? :) I'm still investigating, but if anyone has experience with this sort of setup, I would very much appreciate any advice they could share with me. Thanks for your time. Best regards, Anthony Foiani ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
