Menu
▾
▴
Re: [Opensc-devel] State of session locking support
|
From: Frank M. <mo...@in...> - 2015-11-26 14:21:20
|
I withdrew my original PR to create a new one: https://github.com/OpenSC/OpenSC/pull/618 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 Firefox >> 9. 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 operation 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 some 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 driver 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 > >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 |
