On 06/05/2011 21:23, Juan Antonio Martinez wrote: > Sure: there are some cases where these approach fails: > SSL renegotiation when signing applet is running; two pkcs11 > trying concurrent access to the card... but this is not > as usual as thought. IMHO you could avoid troubles using a simple state machine: when the "server" sends a command to the card, it sets a busy flag to prevent access from other apps. Once card answers (could take a long time, like when generating an RSA key, but since card is actually "in use" there's no way to avoid it) a timer is started. If another command comes in from the same client, timer gets reset and cycle starts again. If no command is received before timer expires, then card is reset and busy flag is cleared.
This way you can be sure that only an active app keeps control of the card. For example, for Firefox it will be like a card removal. It should reread it anyway (maybe a cert got added...). In your example, SSL renegotiation (or signing app) would be delayed the time needed to complete the other operation. An hung app could not lock the card for others. The only drawback I see is that no user intervention is possible during a command sequence: you can't stop to ask PIN, you have to know that a PIN is needed (by parsing PKCS#15 structs or by issuing a crypto op), ask for it and restart sending commands from the beginning. Unless (maybe) if reader comes with a pinpad and its "read PIN" is atomic (that is: no answer till user enters PIN). Or maybe I'm completely gone... :) BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
