François Leblanc wrote: >> There are two targets: >> 1. If a PIN is entered via software, cache it in a single location, usable >> by all layers above libopensc by same mechanism >> 2. Allow to personalize a card with all PIN-s going through a pinpad. >> >> 1. is possible, but 2 via PKCS#11 might be a problem, if a card requires >> several times a PIN for a single operation... >> >> >> Actually: >> - C_Login() caches PIN in one of the p15card->pin_cache[] entries ; >> - sc_pkcs15init_authenticate() (in fact do_get_and_verify_secret()) do not >> look for PIN in this cache, but in a global cache (static >'secret *' and >> 'named_pin' in keycache.c) . >> >> What is the reason of co-existence of these two caches? >> >> Maybe sc_pkcs15init_authenticate() should look for the PIN in >> p15card->pin_cache[] also ? >> IMHO, at least, it will solve the problem for the 'target 1.', and will not >> change the situation for 'target 2.' . >> > > > I've seen in docs > << > If the token has a "protected authentication path", as indicated by the > CKF_PROTECTED_AUTHENTICATION_PATH flag in its CK_TOKEN_INFO being set, then > that means that there is some way for a user to be authenticated to the token > without having the application send a PIN through the Cryptoki library. One > such possibility is that the user enters a PIN on a PINpad on the token > itself, or on the slot device. Or the user might not even use a > PIN-authentication could be achieved by some fingerprint-reading device, for > example. To log into a token with a protected authentication path, the pPin > parameter to C_Login should be NULL_PTR. When C_Login returns, whatever > authentication method supported by the token will have been performed; a > return value of CKR_OK means that the user was successfully authenticated, > and a return value of CKR_PIN_INCORRECT means that the user was denied access. > > > for target 2 it will be ok, after provided CKF_PROTECTED_AUTHENTICATION_PATH > for pinpad readers, > > so for target 1 and 2 we can call 'sc_pkcs15init_set_callbacks' and give a > function witch return > > p15card->pin_cache[] value if not null, ask on pinpad readers if it's a > pinpad reader and error > > elsewhere. > > What do you think? > > François. >
I have no answer; do not tried to use pinpad with the actual OpenSC version. In my 'local OpenSC' I modified do_get_and_verify_secret() to not return an error if there was no PIN value obtained (from cache or callback) and if there is CKF_PROTECTED_AUTHENTICATION_PATH. Then PIN-pad is managed at the libopensc card specific level . Don't know if it's generally acceptable. Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
