Le 24/04/2011 23:45, NdK a écrit : > On 24/04/2011 14:18, Viktor TARASOV wrote: > >>> It seems the root of the problem lies in the profile: changing >>> CRYPTO=$PIN to CRYPTO=NONE works around it, but it's surely sub-optimal. > What I wanted to say: shouldn't --insecure replace $PIN with NONE ? > For what I've understood, "-a N" makes $PIN in profile be replaced by > CHVN, hence IMO --insecure<=> $PIN->NONE. No, '-a N' means in fact '-a <ID of authentication object> . The real PIN reference, the one that can be used in the PINs APDU, is extracted from AODF record as PinAttributes.pinReference .
The 'N' in the CHVN syntax is directly pin reference that corresponds to PinAttributes.pinReference . Personally, I'm ready to remove at all 'insecure' option -- never used it. All the stuff can be defined in the card profile. But let us wait for the other opinions. > If it should work this way, then there's a bug. If it works this way in > other cards, I'll have to look at card-myeid.c, else I'll I still do not see where is the bug. > have to look > at code in profile.c . But I only have MyEID cards... >>> Another, maybe related, problem is that, IIUC the profile syntax, only >>> one PIN can be specified, >> It's not completely true. >> The ACL profile definition "ACL = *=NEVER,READ=$PIN,READ=$SOPIN;" will >> define two linked ACL entries for 'READ' operation. > That's good. This syntax makes me understand some code I couldn't find a > reason for. But does it mean that BOTH are required ? As it actually implemented -- 'BOTH'. > But then it should be much more expressive someting like > READ=($PIN&CHVn)|SOPIN to mean "to read this file you need either SOPIN > or both PIN and CHVn. But then, apart card-specific support, profile > parser should be extended. Probably yes, if you consider as a necessity the implementation of extended logic algebra for the multiple PINs . My opinion is that PIN protection is not best one. Administration should reserve for itself something better -- PIN is for the humble users. >> After that it's up to card specific part to encode this case into the FCP of >> file/object to be created. >> The encoding is quite different from one card to another . > That's quite understandable. > >> Further arrives the question how to use the combined ACLs (properly parsed >> by card specific part back into the linked ACL entries.), describe them in >> PKCS#15, ... >> Actually the common part of pkcs15init or pkcs15 cannot process combined >> ACLs where there are more then one authentication method of the same type >> (for ex. two PINs). > Uhm... Can't follow you well, here. > If I use a line like > CRYPTO=$PIN, UPDATE=CHV5, DELETE=CHV4, GENERATE=CHV4 > to make it so that the user identified by $PIN can generate and use a > key, but to delete/update it an authorization by other users is needed, > doesn't work? That works. > Or simply that pkcs15-init still can't handel READ=$PIN,READ=$SOPIN? Actually it implements 'and' for the all PINs. There is no 'or' or something more complicated. >>> - central office handles card initialization (w/ SO-PIN) >> Central office could be presented by the other authentication method: SM or >> external authentication. >> (xPIN authentication is not quite secure for the administration tasks.) >> Support of these authentication methods is in the road-map of OpenSC. > Read that, but usually a PIN (used inside a controlled environment) can > be enough. After all, central office should be trusted "by default" > since it initializes the card. I don't know quite well the world of 'controlled/trusted environment', my interest is rather to administrate the card through the 'uncontrolled/untrusted' environment. > And unless you use open-source (or > self-developed) applets, you're already trusting who wrote the applet > (or he could have inserted a backdoor to bypass any access control using > a special, undocumented APDU or a special key). > > BYtE, > Diego. Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
