On Tue, Apr 13, 2010 at 3:27 PM, Martin Paljak <mar...@paljak.pri.ee> wrote: > On Apr 13, 2010, at 15:02 , Alon Bar-Lev wrote: >> On Mon, Apr 12, 2010 at 1:59 PM, Martin Paljak <mar...@paljak.pri.ee> wrote:
>> 1. Make OpenSC secured? >> >> The fact that OpenSC locks the reader for its own use for the duration >> of the session is the most critical issue OpenSC has. >> As a result two applications that uses PKCS#11 at the same time either >> cannot work at the same time, or can access the card without >> authentication. > This happens if lock_login for the PKCS#11 module is set to true, which it is > not by default. > >> A stateless mode should be implemented... [1], it has nothing to do >> with the card features, but credential caching. > There are two ways for approaching this: > - lock the card for the duration of the application (lock_login = true) > - reset the card after every transaction and rely on credential cache (your > proposed stateless behavior) > - let the card decide when it wants to re-authenticate (and assume some > essential protection of the host machine against trojans etc) and keep the > card in authenticated and shared state (matters for keys which policy allows > this) (lock_login = false with a suitable card driver, like estonian eID) 1. Invalid - as PKCS#11 explicitly states that multi-application mode should be supported. 2. Valid. 3. Invalid - as PKCS#11 explicitly states that each process should re-authenticate. >> As for PINPAD readers, there are some cards that has a feature of >> authentication cookie that is given after initial authentication, this >> cookie is valid as long as there is power to the card. So the >> algorithm is as follows: Lock reader, authenticate using PINPAD, >> acquire cookie, unlock reader. After that a normal sequence of >> stateless operation can be executed while the cookie is the >> authentication credential. >> >> Because of the lack of this feature I could not offer OpenSC to any >> enterprise. > > Why not implement it then? Can you name / provide shop URL-s for such cards? > Are they otherwise supported by OpenSC? Athena[1] supports that, and most proper biometric cards also supports this as one cannot expect placing finger each operation [and most work stateless]. [1] http://www.athena-scs.com > >> 2. Support biometrics match-on-card? This feature is missing from open >> source and Linux drivers. If you go toward java cards, an applet can >> be implemented in order to do so, maybe using libfprint [2]. > Nice idea, but this is an unexplored area as of now, AFAIK (I've not found > anything open source either, except for libfprint (which does not deal with > cards) and some > > I suspect that match-on-card is currently as troublesome as pinpads a few > years ago - it was not easy/possible to create a universally working solution. > I'd be interested in working with somebody who is interested in it, but won'r > have much time to deal with it before the second half of the year. But to > make this happen, somebody from the biometrics camp should be included in the > discussion, I have not found an active and lively mailing list for this. > > From release perspective, I can only guess that this would be relevant in > 0.13 or 0.14 or however the versioning goes. In fact, biometrics probably > belong to 1.1 line IMHO. Your call... Just wanted to raise this issue, as currently one must use Windows when biometric is required. Regards, Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
