[Spice-devel] RFC - Direct smart card support in libcacard/spice-gtk

[Marc-André Lureau]

Hi

On Tue, Dec 23, 2014 at 9:49 PM, Jeremy White <jwhite at codeweavers.com> wrote:
> Hi folks,
>
> I've been working a lot with smartcards for Xspice.
>
> As I've done this, I've come to understand that the Spice client doesn't
> actually send the physical smartcard data across; instead it sends
> virtualized smartcard apdus, using PK11 information it gets from libnss.
>
> After some discussion on irc, I decided to explore expanding libcacard to
> support sending the apdus directly to the card, using the PC/SC (aka
> pcsclite) library.
>
> I've attached a proof of concept set of patches - one for the client, and
> the substantial one for qemu/libcacard.
>
> The basic approach is to add a parallel to the vcard_emul_nss.c stack, where
> we add and remove readers and cards in response to pcsclite events.
>
> Note that I don't consider the code submission quality; it has quite a few
> rough edges.  It does work for me in some limited test cases, though, and it
> I think largely illustrates my proposed path.
>
> I am hoping to ask:
>
>   1.  Does this basic approach seem reasonable?

I think VCardEmulType VCARD_EMUL_PASSTHRU was supposed to be used for
this case, although the current code doesn't make it straightforward
to add that, as it initializes nss in vcard_emul_init. It should be
possible to change that though.

It probably doesn't make much sense to push this in libcacard if you
don't reuse any of the cacard framework.

>   2.  Anyone know what the origin of the VCARD_DIRECT code path was?  I use
> it here.  git-blame pins it back to the original libcacard commit; not sure
> where it came from before then.  I was trying to find an alternate consumer
> of that code to make sure I was aligned with it.

No idea, it's probably the way some cards operates but it's not used
by CAC afaik

> I believe that, with this change, a system that was not otherwise using a
> smart card could relay that smart card on to a distant Spice server. I'm
> uncertain what would happen in the case where the smart card was in use by
> the local system.  That's something I'll need to probe yet.  I imagine that
> it won't work, but have no real hard evidence for that :-/.

It could be that pcscd can actually lock concurrent requests and reply
from overlaping each others, but I don't think it can handle context
switch and apparently there is no context lock when connecting with
pc/sc api. So it will likely go wrong in some cases.


-- 
Marc-André Lureau