Hi João, On 10.08.2009, at 16:53, João Poupino wrote: > The card appears to be working ok. However, there is still an issue > with the Signature Key: the card needs to receive the Verify PIN APDU > exactly before the Compute Signature APDU, or else a "Security Status > Not Satisfied" error will be received. IMO, this is something the calling application needs to know and deal with. Check PKCS#11 spec for CKA_ALWAYS_AUTHENTICATE, which I just discovered is not implemented in OpenSC, which is something I'll fix tonight. It still requires
> One possible way to solve this > issue is to create a GUI that asks the user for the PIN exactly before > the Compute Signature operation. This is one possibility (to trigger a GUI to ask for a PIN/PINpad entry) but unfortunately there is no well defined way of doing this via PKCS#11 (which should be the preferred interface to OpenSC). The way it is supposed to work in PKCS#11 is for the calling application to inspect the token flags and if it sees that it supports protected authentication, pop up a window to ask the user to authenticate. And if it gets a CKR_USER_NOT_LOGGED_IN, to deal with the situation and recover by calling C_Login and continue with whatever it was doing before. > Another possible way, is to delay the > sending of the Verify PIN APDU right until the Compute Signature > function is called, send the saved APDU (with the PIN) and destroy it > afterwards. This avoids the problem of caching the PIN for more than > one Compute Signature operation, but is it "safe"? This does not really work with pinpads (the calling application should know when to display something and for example it only knows with C_Login to display a "enter PIN on pinpad" window) and it might come as a surprise to the user. It is also not advised to cache signature PINs in any way, if you want the code to be used in audited setups for example. Magic is never a good option. > We would like to know your opinion regarding the Digital Signature Key > PIN issue: is delaying the PIN verification (with a temporary cache) > and then destroying it after the compute signature acceptable? > Is the GUI the better option? Would the OpenSC team accept such a GUI > (possibly enabled at compile time with --enable-eid-gui or something)? It might be an option, but probably it would need 3..4 different GUI "plugins" to work on all platforms - Windows, Mac, Linux(KDE/GNOME). It also probably breaks modal windows on some platforms - the popup window might not be attached to the calling application. Nor does it work with headless setups. Nonrepudiation keys, at least in EU, are used to give legally binding signatures. Applications that can create such signatures, should be sophisticated enough to be aware of the fact that every signature requires a PIN verification (whatever API it uses). I don't think it is a problem that needs to be "fixed" on OpenSC level. -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
