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? > 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" ? > '-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... > 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
