On 29/04/2011 15:35, Viktor TARASOV wrote: >>> From your point of view, where the UPDATE access to 4402 and friends >>> should be defined ? >> Since UPDATE refers to an existing object, it belongs to that object. > 4402 is not an object that can be described by PKCS#15, it's the PKCS#15 > itself -- AODF descriptor of the PKCS#15 structure. Uh, OK. I didn't study PKCS#15 yet... just a really quick glance. Then it have to be (at least) readable. Like 3F00 and 5015 :) All other objects, on a properly "formatted" PKCS#15 token, should be described by AODF or other "standard" files. So it should be enforced that ACLs are set only when creating a new filesystem and not taken from profile every time.
> The only place where its UPDATE access is defined (beside the file's FCP) is > the profile. Then it should be defined statically: no room for playing, here. >> But CREATE, being referred to a non-existing object, should belong to >> container (parent) object. > Once more, parent is not an PKCS#15 object. But we know we are working on a PKCS#15-formatted card. > If 'SELECT' parent do not return FCP data, there is no way to get the real > ACLs. Unless they're stored in another object we know something about. > The only hope is that the profile settings correspond to the real (hidden) > ACLs. We can *require* that access conditions stored in object metadata match the ones stored in PKCS#15 files by doing it ourselves, at least for newly-formatted cards. Using just pkcs15-init (and maybe pkcs15-tool), it must not be possible to create an object whose ACL is different than the one stored in metadata EFs. As it is now, it's possible (gone there, done that). >> It's not "good" that problems arise if I create a card using >> pkcs15+onepin and a user creates a key using just pkcs15 profile! > It's up to you to educate your users. Sure, but you can see that it gets completely unmanageable when you have many users (haven't had discussions with some university professors 'that are always right'? Lucky you! :) ). > Once more, actually, the pkcs15init is designed to make possible the > administration of the cards (probably absolutely obsolete cards) > that do not always return all necessary information. Missing information for > such a cards is looked for in the profiles. > It presumes some 'stability' of the profiles. Sure. That's why I'm suggesting to move handling of these cards to their own emulator, that exposes a standard interface. But, first of all... > Probably these precautions is not more (was never) valid. > Pkcs15init has to be reviewed/retested to see if these precautions are still > necessary. ... is some card driver actually using 'em? > No, you will be prompted for the PIN that was deduced from the FCP of the > parent that has been selected at the > moment just before generation . If 'SELECT' of your parent do not returns > FCP, then your profile will be asked to > create virtual instance of you parent and this one will certainly have the > needed ACL. Ok. > ID '02' will silently go into the authId of a new PKCS#15 object. Nothing > more. So creating a mismatch between what PKCS#15 knows aout that object and what card mandates... And we end up having to look at (possibly out-of sync) profiles. > Then, when you will try to use this generated key, for ex. to make a > signature, > your PIN value argument will be used in the VERIFY command with the 02 as > pin-reference . But since profile only says CRYPTO=$PIN, ACL is created with a requirement for VERIFY CHV1 (given that CHV1 have ID 01)... >>> If it's not like that, get us look at the extended logs or the detailed >>> description of your actions. >> Didn't dig this deep into card-specific code. > It's going about the logs from your 'suspicious' session where SOPIN was > blocked. Too late. Definitely locked SOPUK, too. Not worth resending to Aventra to reload their app... I'll try to recycle it as a test card for my app implementing neural cryptography when it will be ready (in the mean time I'll try OpenPGP to make some practice). BYtE, Diego. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
