Menu
▾
▴
Re: [Opensc-devel] State of session locking support
|
From: Frank M. <mo...@in...> - 2015-11-27 16:44:53
|
Hi! > 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. With forced PIN-pad usage it doesn't work. But to be clear: This problem can't be solved with a PIN-pad reader regardless of the approach taken. > 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. I highly doubt that it is possible to *reliably* detecting a modification/usage of the card's state by an other application. If this detection mechanism does not work 100% then your card is open for misusage by other applications. The only solution I see is to always save and restore the complete state of the card. And, seen from a PKCS#11 perspective, the only volatile state is whether some user is logged in or not (correct me if I'm wrong). Validating the PIN on a PIN-pad always modifies the card's state, that's why the state *must* be restored by entering the PIN on the PIN-Pad again and again and again for every transaction. Thus, solving this problem with a PIN-pad reader is either really really annoying or simply impossible. Why solve this problem on the PKCS#11 level? This only needs to be solved in PKCS#11; tokend and minidriver have their OS-builtin mechanisms for avoiding interfering applications. > 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...> > -- 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 |
