Hi, Please find my comments below > ... > > [Vladimir Beker] This is obvious. What I wanted to do is the following: > > from the viewpoint of the user there is password (since I speak about > > human client). The password is converted to the encryption key (for > > instance, according to PKCS#5 - and this key is used for real > authentication. > > This way I prevent eavesdropping and replay attacks by using > > challenge-response (alternatively I need SM but it supposes that both > > sides already share some secret). > > not necessarily, some cards support key agreement with asymm. crypto > (using for example cv certificates). [Vladimir Beker] Regarding to asymm. SM: First, as you say, not all cards support it. Second (more important for me): even if I go to the asymmetric scheme, I need to describe it in the smartcard layout (so that application will know that it should apply SM working with particular key).
Anyway the same applies to EXTERNAL > AUTHENTICATE is case a symm. cipher is used. [Vladimir Beker] Absolutely. That's why I want to derive key from password and use EXTERNAL AUTHENTICATE for user authentication. > > > > However from the user point of view, > > it is password, so min/max length and other password attributes still > take place. > > of course you can misuse a pin a object for this, but I don't think > there's an elegant solution for this (using pkcs15, not to mention > pkcs11 ;-) [Vladimir Beker] Regarding to PKCS#15 - it is not elegant (it would be better to have missing attributes in auth. key object instead, just to make them OPTIONAL. So, presence of these attributes (such as min. length) would mean that it is actually password derived. Regarding to PKCS#11 - I disagree with you. In terms of user it IS the PIN. The way that it is presented to the card is not interesting to the user. It smells as PIN, it behaves as PIN. Who cares that internally it is more secure than PIN? > > hmm, the currently supported AccessModes in pkcs15 are for > read, update and execute ... no deletion, but I don't know if this > list has been extended in iso7816-15 (btw: my above proposal for > never is of course not in accordance with pkcs15). I would > suggest setting the auth object required for removal in the authId > field and if an application tries to access the object it will > fail (even after verifying the auth object) but as the app. is not > supposed to access this object this shouldn't be real problem. [Vladimir Beker] Well, the proposal may be a bit different. I would propose to use invalid value here. As minimum, it may be ID that does not appear in the directory of authentication objects. Or it may be something that the card will not accept in VERIFY command (such as 0xFF). > ************************************************************************************************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** ************************************************************************************************** _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
