Le 05/04/2011 16:42, Frank Morgner a écrit : > 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.
>>> What I am aiming at is modularity and reuse of code. This should not be >>> only done by coding functions which are used by different card drivers. >>> This should be reflected by the software architecture to achieve >>> separation of concerns. Two main concerns are encoding and encryption: >>> >>> Encoding layer: >>> - pad data for authentication/encryption >>> - encode clear apdu for encryption >>> - encode cryptogram/clear apdu for authentication >>> - encode cryptogram and mac for transmission >>> Crypto layer: >>> - encrypt data >>> - decrypt data >>> - authenticate data >>> >>> I separated the crypto layer via callback functions. This could also >>> be done with the encoding layer (which I didn't because I thought >>> that every card uses 7816). >> Where the crypto layer callback should be called? In encoding layer? >> In the non-SM part (libopensc?, pcsc?) ? > The former, the encoding layer triggers cryptographic operations. First > encode plain APDU, then encrypt data, then authenticate data, then > encode encrypted/authenticated APDU. > >> For me the SM related callbacks represents the external API of the SM >> module (static or dynamic). These callbacks are called in the non-SM >> part (libopensc). Internal architecture of SM module is not exposed >> to the libopensc level . In this module are linked together encoding >> and crypto layers . >> >> There are only few SM callbacks: initialize, get-secured-apdus, >> decode-answer, finalize, init/close-module . > Agreed, I don't think more callbacks are needed. When splitting encoding > from encryption, I am talking of the structure of the SM-Module. Ok. Have you any consideration about the general schema of the interactions between SM module and OpenSC, as it exposed on the wiki page ? > Cheers, > Frank. Kind wishes, Viktor. > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
