Hi! > >>>>> AFAIK, ISO 7816 defines data encoding, input for the > >>>>> cryptographic layer and some padding methods. Everything you > >>>>> listed would be part of the crypto layer which is not fixed by > >>>>> ISO 7816. > >>>> Can you explain yourself ? Yes, it's another crypto layer, that > >>>> sits beside the ISO-7816's one and that uses the common 'involved > >>>> cryptography' library. Which layer to use is defined by the > >>>> card-driver/opensc-configuration during the initialization of the > >>>> SM context. > >>> It is common to confuse or mix encoding with encryption. ISO 7816 > >>> defines encoding, nothing more. It says that SM also involves some > >>> sort of encryption. How encryption looks like is not part of 7816. > >>> The things you listed are not subject to 7816, which leaves my > >>> question unanswered if GP uses a different SM protocol as the one > >>> defined in 7816. > >> Yes, it uses different SM protocol. Look annex D of the Global > >> Platform v2.2 specification . > >> > >> How do you define 'SM protocol' ? For me it's a sum of data > >> format, encryption and authentication rules. Internally these > >> rules can be presented as pile of 'encoding' and 'encryption' > >> layer, 'authentication' clearly separated from 'encryption', ... as > >> you like . Two different SM protocols can use the same 'involved > >> cryptography', authentication scheme, ... > > I am always referring to ISO-7816: Here Encoding is standardized and > > in addition the data is encrypted/authenticated "somehow". So yes, > > SM involves encryption, but it doesn't standardize the means to this > > (which is what I call the crypto layer). One SM protocol is defined > > by ISO-7816, where the cryptographic protocols used can differ from > > card to card. For me SM is a specific encoding with unspecific > > cryptography. So two cards conforming to ISO-7816 that use different > > cryptography still use the same protocol. > Ok, return to the begin, > we have two different SM encodings, so we have two different SM > protocols -- GP and ISO-7816.
...which was not clear, since you listed only crypto related characteristics that differ. > Have you any consideration about the general schema of the > interactions between SM module and OpenSC, as it exposed on the wiki > page ? My previous remarks in this mail apply to the inner structure of the SM module. I consider your layout as the most promising. (Maybe because I implemented something similar ;-) ) Beyond that what I have already said about where to trigger SM, I have some other questions: You speak of the SM module like a separate library. What can be said against putting everything into libopensc? The ACL mode sounds like it could be superseded by the APDU mode. If ACLs request SM, you could set the correct parameters for APDU mode. Is there a more complex operation needed which justifies the ACL mode? Cheers, Frank.
pgpE4vfjEJdg0.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
