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