Le 29/03/2011 01:16, Frank Morgner a écrit : > Hi! > >>>>> The smart cards I worked with, that used SM implemented more or less >>>>> what is defined in ISO 7816. The Wiki states, that GlobalPlatform SCP01 >>>>> uses a different SM protocol. What exactly does differ from ISO 7816? >>>> keyset format; session key derivation data; session keys calculation; >>>> SSC/no-SSC; encrypted data format; MAC computation; ... >>>> >>>> Involved symmetric cryptography is essentially the same: 3DES/CBC >>>> >>>> For the 'exact' differences you can look through the GP specification, >>>> or the actual implementation of the both protocols in the IAS/ECC branch. >>> 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, ... >>> Which file would I have to look at for the GP part of your branch? >> do grep 'sm_gp_' > If I am reading sm-global-platform.c correctly, then the SM APDU's data > (excluding the header) is defined as 8 bytes mac and optional encryption > data. This indeed is different from 7816, which uses mac and encryption > data only with TLV. > > 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?) ? 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 . > Greets, > 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
