minimal requirements for working with crypto tokens?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

minimal requirements for working with crypto tokens?

Anthony Foiani
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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: minimal requirements for working with crypto tokens?

Ludovic Rousseau
2012/12/6 Anthony Foiani <[hidden email]>:
> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: minimal requirements for working with crypto tokens?

Anthony Foiani
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
<[hidden email]> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel