Hello, On Tue, Oct 19, 2010 at 12:52, jons...@terra.es <jons...@terra.es> wrote: > Afaik this theme has been discussed at OpenSC [2]. As a result, user consent > code > was removed from OpenSC.
User consent in PKCS#15 terms means that the application needs to ask for users permission after every n-th operation. In PKCS#11 terms (the main output of OpenSC) the only way to ask for a permission via the API is by asking the user to verify the PIN code and the CKA_ALWAYS_AUTHENTICATE flag in PKCS#11 v2.20. Important difference between PKCS#11 and PKCS#15 is that PKCS#11 always assume userConsent == 1. This kind of user consent information has been in OpenSC for a long time. > But here comes a problem: Spanish authorities certification rules requires > that every > signing procedure must be notified to the user by mean the middleware, > regardless > the behaviour of main application. Removal of User Consent (as Martin did in > github [3]) > lies into an un-certificable code IMHO this is just bureaucratic fabrication that serves no real purpose other than delegating responsibility. If the host is compromised, a certified popup-throwing middleware will not stop the trojan from generating signatures if the card allows it (or the trojan has the PIN code). Yet, as noted in the ticket, some GUI triggering from inside OpenSC would be useful, for notifying the need of PIN (re-)entry from a pinpad or to "fake" a pinpad to the application and ask for the PIN itself. But this can't be the default behaviour (or needs to be configurable). As a quick hack, calling pinentry could be used, but not as a permanent solution. For this to work nicely, native GUI should be created (Windows, Mac OS X, GTK and/or Qt for Linux) which assures the user that the prompt comes from OpenSC (a "certified" popup window). This requires localization also. I don't think that piping the PIN code around via external programs adds anything to the secrecy of the PIN code or the overall security of the system (unlike a card that enforces user consent and a pinpad reader) _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel