Re: [opensc-devel] OpenSC shared mode
1. Firefox behaves correctly, it opens long living session with crypto token, in order to reduce the number of times user is prompted for passphrase. 2. Firefox monitors slots, to be able to detect new certificate availability so it can prompt the user for one if requested. It is true that it can be done each time a signature operation is required, however, it would be much slower to do so. 3. Firefox may use the monitor (I almost sure it is not implemented) in order to disconnect TLS/SSL sessions once token is removed. --- What PKCS#11 provider should do is to allow single authentication of application while authenticating each transaction with card, aka stateless operation. This approach is problematic with PINPAD readers, as user will be required to enter PIN each operation. However, there are some advanced cards that can generate authentication token, so you can actually authenticate once using PIN get authentication token out of the card (many can be available at same time), then each transaction is authenticated using these tokens. This approach solves the PINPAD issue and BIO issues. Alon. On Sat, May 7, 2011 at 7:08 PM, Juan Antonio Martinez jons...@terra.es wrote: El sáb, 07-05-2011 a las 08:01 +0200, Frank Morgner escribió: Hi! [...] In your example, Juan, you say that Firefox calls C_Init to initialize the card for pkcs11. I'm not an expert for p11, but is it really needed to actually lock the card on initialization and keep an established connection? Neither I am an expert :-), but my feeling is not: Traces on Firefox shows this flow: - At starting FF C_Initialize C_GetInfo - Then ff enters in an infinite loop of: C_GetSlotList C_GetSlotInfo C_WaitForSlotEvent - When card is inserted: C_OpenSession C_GetSessionInfo And returns to previou loop At exit: C_CloseAllSessions C_Finalize I can't see a real reason to do any lock for just a simple polling task nor problem for a concurrent p11 session at this stage Moreover, I don't understand why ff needs to monitorize slots when no p11 task is requested/needed. In fact google says about many links against this feature Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
Alon Bar-Lev wrote: However, there are some advanced cards that can generate authentication token, so you can actually authenticate once using PIN get authentication token out of the card (many can be available at same time), then each transaction is authenticated using these tokens. This approach solves the PINPAD issue and BIO issues. And this works because the p11 library stores these cookies associated with each incoming p11 user? //Peter ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC shared mode
On Sat, May 7, 2011 at 10:57 PM, Peter Stuge pe...@stuge.se wrote: Alon Bar-Lev wrote: However, there are some advanced cards that can generate authentication token, so you can actually authenticate once using PIN get authentication token out of the card (many can be available at same time), then each transaction is authenticated using these tokens. This approach solves the PINPAD issue and BIO issues. And this works because the p11 library stores these cookies associated with each incoming p11 user? One to one corresponding with C_Login(). This also has the advantage of not locking the card when PIN is changed. If PKCS#11 library caches the PIN, and use it each time to perform card transactions. You have for example Firefox, OpenVPN, GnuPG running. You change the PIN via cmd-line, then each application attempts to sign, each bails out at 1st failure, but after the 3rd accumulative attempt the card is locked. To solve this, the PKCS#11 provider may use some file in /var/tmp to notify all instances when this event occurs so all instances may drop the current PIN. However, this will not work if one use remote sessions, such as remote desktop with PC/SC channel. The authentication cookie solves above, PINPAD, BIO efficiently, however it requires card to support it. You get a cookie out of PIN/PINPAD operation/BIO match. The cookie is valid as long as card is powered on and policy permits. Policy may state that once PIN is changed all cookies are invalidated or not. You may use the cookie instead of PIN in all object access operations, so you can use stateless transactions, while never lock the card by mistake, minimize the user interaction required during PINPAD/BIO operations. Alon. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
