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. > > 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. Cheers, Frank.
pgpVkQIK0VUBu.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
