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.
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 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 ? 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. > 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? Or simply that pkcs15-init still can't handel READ=$PIN,READ=$SOPIN? >> - 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. 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. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
