Le 28/04/2011 12:28, NdK a écrit : > On 28/04/2011 12:07, Viktor TARASOV wrote: > >> $PIN, $SOPIN and others are the profile macros >> and correspond to the SC_AC_SYMBOLIC authentication method. > Ok. I already found this digging code. > >> They are resolved using the pin flags of the PIN pkcs15 >> objects already present on the card. >> Look into sc_pkcs15init_get_pin_reference() . > Now I'm starting to get lost... > Why is it fixed? Let's say 'translated'. 'PIN', 'SOPIN' in human language are translated to CHV## in APDU language .
>> If your card contains the User PIN authentication object >> with the reference 1, the $PIN is translated to CHV1. > And how should I say, in profile, "use the authentication object specified by > --auth" ? Use for what? Language of pkcs15init tool's arguments is a poor language. It's difficult to specify all parameters for a new object: import with SOPIN, delete with PIN, PSO_DST with SignPIN, ... The details come from the card profiles. Probably the '--auth' argument should overwrite the object's 'usage' ACLs from the profile . That would be reasonable and will answer your expectation. We will lost the fine granularity (PSO_DST with PIN, PSO_Auth none, ...) -- but I don't think we really need it . >> '-a 02' only (to be confirmed) means that the >> CommonObjectAttributes.authId of your object will be set to '02' and >> written to the PrKDF . > And that means what? If use is regulated by profile (as it seems), it's > useless to set another (different) value. > If I say "-G ... -a 02" I mean "create a new key and require > authentication with 'pin2' to use it" (now assuming 'pin2' maps to > CHV2). If the default profile says CRYPTO=$PIN and that gets translated > to CHV1, that's not what I expect... Now it's a certitude -- '-a' has to overwrite the object's usage ACLs from the profile. >> Look into you profile (which one?) > myeid.profile , just reset to default one for these tests. > >> -- how generation/creation of new file/object is protected in your parent DF? > Urgh! Parent permission! I was looking at EF permissions and not parent > DF ones... That explains something. > 3F00 have acl= CREATE=$PIN, DELETE=$SOPIN >> how write operation for xxDFs is protected ? ... If one of them is >> protected by CHV1 ($PIN) -- you will be asked for CHV1. > I see. Uhm... Tuning profiles can be a very hard job... > > BYtE, > Diego. > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
