Wello William, Le 07/12/2011 15:24, Hunter William a écrit : > -----Original Message----- > Ok, yes, I see that - so should we allow the accessControlRules parameter > to override the authId? It seems so... > I can update the pkcs15-crypt tool. Are there any other places that need > updating? I can see that on a login (pkcs15_login), we might expect > additional keys to become available, and these must match the auth_id > too. >> Is it happens for you to have the accessControlRule that protects by >> the different 'PIN' objects the IntrenalAuth, Decipher and Sign >> operations of the same key ? >> Could we assume, that only one 'PIN' type auth.object is present in >> 'accessControlRules' of one key ? > It seems to me that both PKCS#11 and the minidriver only support one > (user) PIN per card, so this has to be so for these modules to work? > However, the specifications support multiple PIN objects, so a card may > in theory have different PIN's for different operations. It just isn't > clear to me how this would then work? The pkcs15-crypt tool may be able > to get it right, but how would you support this for the PKCS#11 module or > the minidriver? > > I'm happy to implement this, but do you (or anyone else) have any > suggestions on how to do it properly?
My first suggestion is to set authId when parsing the contents of PrKDF . That's why was my question above. Assuming that only one 'PIN' authentication object can be present in securityConditions, we can set authId on the parsing stage and rest of code will hardly be changed. We can return to this decision later, when the real case with more the one PINs in securityConditions will happen. PKCS#11 deals with more then one PINs by creating the multiple slots for the same card. The most general configuration of the OpenSC PKCS#11 is to create one slot for every on-card application and for every non-So, non-Unblock PIN. Other possibilities could be configurations with one slot for UserPIN, two slots for UserPIN and SignPIN, ... For minidriver the choice is more restricted. I guess that it should be done as the PKCS#11 in the one-userPin-slot configuration -- in 'read/use' mode are accessible all objects protected by userPin, from the all on-card applications; in 'write' mode new objects are created in 'generic' on-card application . > Would it be something like: > > Instead of using p15_obj->auth_id, use the following function: > > pkcs15_get_auth_id(struct pkcs15_object *obj, unsigned int operation) > > where operation would be a set of bits checked against the accessMode. It > would return the first sc_pkcs15_id that matches any of the operations > flagged, first checking the accessrules, and then returning obj->auth_id > if none match. This should work fine for pkcs15-crypt, but for framework- > pkcs15, it would have to just return the first auth_id it finds with any > valid operation, and any others would be ignored. .. > I can't see that the minidriver uses auth_id at all (except to set it > where necessary). So, for the minidriver, the key auth_id and the first > user PIN *have* to match, or else things just don't work? It's still to be done. My suggestions are above. > Cheers, > Will Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
