Darren J Moffat wrote: > 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.
I beg to differ. A slot is *NOT* always a reader. Note the "other interpreations" below. PKCS#11 2.20 Section 6.2 (page 14): Cryptoki provides an interface to one or more cryptographic devices that are active in the system through a number of ?slots?. Each slot, which corresponds to a physical reader or other device interface, may contain a token. A token is typically ?present in the slot? when a cryptographic device is present in the reader. Of course, since Cryptoki provides a logical view of slots and tokens, there may be other physical interpretations. It is possible that multiple slots may share the same physical reader. The point is that a system has some number of slots, and applications can connect to tokens in any or all of those slots. One example of more then one slot sharing the same physical reader and smartcard is when there is more then one user pin for the card, maybe each cert/key has a pin. There is at least one OpenSC supported card that has trait. PKCS#11 does not address how slots are assigned to physical readers. It leaves that up to the OS. An example might be a crypto device locked inside the case of as computer to be used by root only, and an external reader for a user to use during login. The reader should be treated much like the keyboard and mouse. Other users (or sessions) ssh for example, should not have access to either of these readers. So an application calling PKCS#11 may be presented with a number of different slots, that point to one or more then one reader. > >> 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. > -- Douglas E. Engert <DEEngert at anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
