Hi, > -----Original Message----- > From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-boun...@lists.opensc-project.org] On Behalf Of NdK > > Il 29/04/2011 09:20, Viktor TARASOV ha scritto: > > >>> We cannot replace $PIN macro with the one that can be modified by '--auth- > id'. > >>> $PIN macro can be used to protect, for ex. the xxDF files itself, > >> Well, I don't see why it shouldn't work :) > > When $PIN translation can change from one init command to another, > > and when $PIN macro is largely used in the card profiles -- one need to be > careful. > Surely profiles have to be checked. > > >> Urgh! That's not good. :( Access conditions for existing objects should > >> only be read from card... Profile should only be used for new objects... > > Agree, but not every card always returns all necessary information. > > The missing part can be looked for in the card profiles. > Uhm... Doesn't standards mandate that, for example, 3F00 must always be > readable, 4402 contains auth info, etc?
Yes, see the PKCS#15 specification from RSA. > > some DF have $PIN in its profile settings. In the first init command it was > created with certain $PIN value translated to its ACLs . > > In the next init command pkcs15init may ask profile to retrieve the ACL of > this DF and obtain the authorization for some operation . > > So, the $PIN translation has to be the same in the both cases. > Imagine that a card gets initialized on a system where profile has been > customized to ask SOPIN to create keys, then an user tries to add keys > on another machine, where profile says $PIN is to be asked. The result > might be a locked SOPIN, since interface asks for user pin but card > requires sopin... (might be what happened to me...). AFAIU the profile is used only when creating new objects. Once the object (DF or EF) has been created the ACLs are read from the card. Everything describing the structure is on the card (or at least is should be, if it's not there's an error). This is what the PKCS#15 standard is for, it describes the structure and content of the card. PKCS#15 emulated cards are then another question, these are handled separately in OpenSC by emulators. I thought you wanted to generate a key on the card and the use it without a PIN, so requiring PIN to create the key is no problem. Have I understood you correctly? > >>> Actually, when using pkcs15-init, one needs to choose the '--auth-id' > corresponding exactly to the ACLs settings in the profile . > Forgot to ask: then why allow the user to specify it? This is where the profile settings should be overridden, i.e. if the user specifies "-G .. -a 2" the key should be generated using a pin with reference 2. Other ACL information is read from profile, and if the user does not specify any auth-id, the one specified in the profile is used. It is this feature that is currently missing from the MyEID driver, now it only reads the profile and ignores the command line parameter "-a X". I think other card drivers must have this feature, and it should be added to MyEID as well. > >>> Otherwise the PKCS#15 description will not correspond to the real ACLs . > >>> It's not quite friendly . > >> It seems quite dangerous and error-prone, to me... > As I see it, profiles should only be used for creation of objects. All > the infos needed later should be sccessible throught PKCS#15 (or other > standards) descriptions, or even set by card drivers... I agree here! Regards, Toni _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
