Menu
▾
▴
Re: [Opensc-devel] State of session locking support
|
From: Douglas E E. <dee...@gm...> - 2015-11-27 14:38:37
|
https://github.com/OpenSC/OpenSC/pull/618 appear to address the issues from a PKCS#11 perspective, but it is not clear how they would work with a pin pad reader. I have been taking a different approach, by trying to recognize if the state of the card has been modified by some other application, before trying to login again. Thus to would work better with a pin pad and could possibly allow the card to be logged in across multiple applications. (opensc.conf disconnect_action = leave) These two approaches could coexist, and be controllable via opensc.conf. There are still some issues with my code, that could be a problem for #618. Another application (call it B) could steal the card while our application (call it A) is in card_match or card_init. Error recovery in this area is not handled well. It appears that PCSC may return too soon after a card_reset done by (B) and pcsc_lock is released but the reset is still active in the reader. (A) gets control sees that SCARD_W_RESET_CARD was returned tries do a transmit and ends up in reader-pcsc.c here: 266 /* unable to transmit ... most likely a reader problem */ 267 sc_debug(reader->ctx, SC_LOG_DEBUG_NORMAL, "unable to transmit"); I have not found the solution for this yet. I think it is problem in PCSC. The simple way to test is to start FireFox (A) go to preferences->Advanced->view Certificates This should prompt from the PIN, then show the certificates. To steal the card opensc-tool cab be used as application (B). In another window: opensc-tool -a If opensc.conf has disconnect_action = reset; this will cause a card_reset and get FireFox (A) to have to recover from this. To test with disconnect_action = leave; this will switch the AID to the global platform AID and my PIV card has both AIDs. opensc-tool -s 00:A4:04:00:07:a0:00:00:01:51:00:00 I am still looking at the reset problem, but need to address this. Error handling in OpenSC is too distributed across all layers, and PCSC will only return to the next SCARD command SCARD_W_RESET_CARD to (A) to indicate (B) has done a reset. This will most likely be from the SCardBeginTranaction initiated from sc_lock. I am still working on this, as it includes C_GetSessionInfo doing a sc_pkcs15_check_state that gets the latest state of the card, and also tries to chenc the AID and login state as reported be the card using a VERIFY class 1 APDU. On 11/26/2015 8:21 AM, Frank Morgner wrote: > I withdrew my original PR to create a new one: > > > > Please check if it fits your needs of statelessness! > > Am 15. November 2015 00:49:35 MEZ, schrieb Frank Morgner <mo...@in...>: > > I quickly hacked my proposition; it's open for review/suggestions here: > https://github.com/OpenSC/OpenSC/pull/608 > > Greets, Frank. > > Am Freitag, dem 13. November, um 14:07 Uhr schrieb Frank Morgner: > > Please rephrase this problem to something like "session locking"! > > Doug is correct, this can't be solved purely on the lower level. Your > best bet would be the PKCS#11 Sessions. I just checked with Client > authentication in Firefox and the workflow is something like this: > > 1. Read card/token/certificates/slots/whatever > 2. C_OpenSession(0x1) > 3. C_Login > 4. C_OpenSession(0x1) > 5. C_SignInit/C_Sign > 6. (immediately after signature) C_CloseSession > 7. Go to 4. and repeat > 8. Terminate Firefox9. C_CloseAllSessions > > As you can see, as soon as the PIN is verified Firefox expects to have > exclusive access. Adding sc_lock/sc_unlock to C_OpenSession and > C_CloseSession/C_CloseAllSessions should be a quick fix for your > problem. Yes, it locks the card on the PC/SC level, but that's all a > library without global knowledge can do. > > Despite this quick win, the problems listed below by Doug still apply! > Also, the card driver for your card needs to be reviewed in more depth. > > As I am writing this I can see that sc_lock also tries to open an SM > channel, which I'm pretty sure is not always a good idea... So all in > all, you have a lot of testing ahead of you ;-) > > Greets, Frank. > > > Am Donnerstag, dem 12. November, um 8:26 Uhr schrieb Douglas E Engert: > > Each ! applet, card or calling application may have its own issues. Can you say what applets, cards or applications you are trying to address? > > There are a number of factors to consider, these are in particular order: > > (1) PKCS#11 already has sessions that require login designed to give exclusive access. > But PKCS#11 on most systems, is at the application level not at the system level. > > (2a) PC/SC is at the system level and can enforce exclusive access with a lock/unlock. > > (2b) Remote desktop connections can make a card available over the network by transmitting PC/SC > calls. This could cause complications. > > (3) OpenSC uses the pcsc lock/unlock for transactions, but this does not match the > PKCS#11 session level. > > (4) Some cards are starting to use secure messaging, that needs to be reestablished if some other > application jumped in the middle. > > (5) Some cards don't have an un-verify to ! reset the security state of the card. A ATR reset is used instead. > > (6) How would you handle the caching of a card state of a read/write card, if some other application > changed files, keys or pins on the card? > > (7) Many applications may keep a PKCS#11 session open for long periods, and they poll to see if the card has been removed. > > (8) Some cards, users or applications may expect that once a card is unlocked by the user, any of the user's processes can use the card without reentering the PIN. > > (9a) PIN caching may be against policy, PIN PAD readers may be required by policy. Don't count on pin caching as a solution. > > (9b) Other ways to authenticate may be required other the PIN, such as fingerprint matching on card. > > (10) OpenSC and PCSC already has some options to control releasing/holding of the locks. > > (11) OpenSC already will try and uses a cached pin if a sign, decrypt or derive operati! on fails. Could this be extended? > To the user it looks stateless. (Did I say I don't like cached pins?) > > (12) PKCS#11 has the concept of CKA_ALWAYS_AUTHENTICATE to force a reauthentication for selected keys. (Some cards enforce that a crytpo command for some keys must be proceeded by a VERIFY > command > with no other commands in between.) OpenSC already supports this. You may want to look at using this concept for all the keys even though the card does not require it. > Applications may not need any changes! The application is the responsible to do another C_Login. > > (13) OpenSC does have an on disk cache of card objects for the eid card. This might help if you need to > reconnect to a card, you would not need to reread objects from the card. Microsoft's cert store does something like this. > > (14) Adding "save"/"restore" calls to PKCS#11 will then require applications to call these. Many applications will not, > if only so! me uses these, will the concept still work? > > > (15) Many of the OpenSC bugs lately deal with multiple applications resetting the cards (or using multiple applets on the card) and issues with SM or > reestablishment of authentication. These are usually addressed in the card driver. > > On 11/12/2015 5:03 AM, Martin Vogt wrote: > > > On Thu, Nov 12, 2015 at 11:47 AM, Frank Morgner <mo...@in... <mailto:mo...@in...>> wrote: > > Nobody is working on this. Could you state what you think the (security) problem currently is? > > > I'm using closed source drivers, because opensc/pkcs11 cannot be used > simultaneously. (since ~ 5 years now) > > Are there ideas how "stateless" support should be implemented? > > My idea was to add two methods to a d! river plugin "save"/"restore" state, > and call this from maybe the pkcs11 layer(?) > > I would like to ask for an advice how it should be done. > > > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > > Douglas E. Engert <DEE...@gm...> > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > -- > Frank Morgner > > Virtual Smart Card Architecture http://vsmartcard.sourceforge.net > OpenPACE ! http://openpace.sourceforge.net > IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc > > > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > > > -- > Frank Morgner -- Douglas E. Engert <DEE...@gm...> |
