Hello Martin,
some comments on r5124:
1. The values of pin_info->reference and prkey_info->key_reference
shouldn't be compared because:
* pin_info->reference is used as P2 parameter in VERIFY command
* prkey_info->key_reference is used in MSE SET tag 0x84
There is no relation between these two values. See PKCS#15 for the
meaning of these attributes and attachment for another solution.
2. The Authentication-Objects can have two authId attributes because:
* they can protect objects (this is
CommonAuthenticationObjectAttributes->authId)
* they could be protected by another PIN i.e. for unblocking purpose
(this is CommonObjectAttributes->authId)
3. User consent for PIN objects does make sense i.e. for unblocking purpose
4. There is also a ticket relating to pin re-validation (#293).
Regards
Andre
Index: src/libopensc/pkcs15-pin.c
===================================================================
--- src/libopensc/pkcs15-pin.c (revision 5124)
+++ src/libopensc/pkcs15-pin.c (working copy)
@@ -499,12 +499,21 @@
return;
}
- /* If the PIN protects a private key with user consent, don't cache it */
- if (sc_pkcs15_find_prkey_by_reference(p15card, NULL, pin_info->reference, &obj) == SC_SUCCESS) {
- if (obj->user_consent) {
- sc_debug(ctx, SC_LOG_DEBUG_NORMAL, "Not caching a PIN protecting a key with user consent");
- return;
+ /* If the PIN protects an object with user consent, don't cache it */
+ obj = p15card->obj_list;
+ while (obj != NULL) {
+ if (obj->auth_id.len == pin_info->auth_id.len) {
+ if (memcmp(obj->auth_id.value, pin_info->auth_id.value, pin_info->auth_id.len) == 0) {
+ /* When we get here, then 'obj' is protected by this PIN */
+ if (obj->user_consent > 0) {
+ sc_debug(ctx, SC_LOG_DEBUG_NORMAL,
+ "Not caching a PIN protecting an object with user consent");
+ return;
+ }
+ }
}
+
+ obj = obj->next;
}
r = sc_pkcs15_allocate_object_content(pin_obj, pin, pinlen);
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel