Douglas E. Engert wrote: > I will have to try it with OpenSC. > > On a related set of issues with smart cards for login... > > Looking at man crytoadm, (and the MIT and OpenSC code and documents) it > is not clear how access to a smart card can be restricted. I.E. How > can access to the smart card (and reader) be limited to the user at > the console? You don't want some ssh session accessing the console user's > card...
cryptoadm isn't designed to solve that problem. That is currently upto the PKCS#11 module (or PC/SC layers) that provides access to the card. For example on Sun Ray there are many readers (at least one at each DTU possible multiple) and also potentially the one on the console too. The way this is resolved is that the PC/SC and driver layer understands the Sun Ray architecture and only presents via PC/SC the readers connected to the users session. For example if I have a Sun Ray 270 and an USB attached reader then I would see two slots via the OpenSC PKCS#11 module. If I move to a DTU that has only the built in card reader on the DTU then there would be only one slot. > This has always been an issue with PKCS#11, as it is vague on what is > a slot, and how a slot can be associated with a reader. I thought that was always very clear. A slot *is* a card reader and a token is a smartcard. PKCS#11 v2.20 enhanced C_GetSlotList() so that it can be called again to find additional slots. Only ones are never removed but may return errors. > Then how does this relate to PCSC and its capability to work across the > network? I don't know anything about how PC/SC does that yet. -- Darren J Moffat
