Uh, I think I am a bit late on this discussion... But I wanted to add a general concern that there are some conceptual problems with the SM branch (and the recently included patches in staging).
1. Global SM configuration is mixed with a configuration at the driver
level. For example, look at [3]. It includes CWA, IAS/ECC data types
which should be realized at the card driver level (or maybe some SM
driver).
2. There are at least two methods to hook into SM, using a SM module and
implementing SM at the driver level. This conceptually introduces
duplication. It is sure to be followed with code duplication. Both
should be unified: Each card driver has a SM driver, which provides
wrapping and unwrapping SM. A SM driver can then also be a SM module
with external key sets.
3. As stated earlier, I am advocating for an additional abstraction
between encoding and encryption. Thus, a SM driver would only
implement encoding, offering an other abstraction to the crypto.
Not implementing this abstraction has led to code duplication [1].
And reinventing the wheel will continue, when all ISO-7816-like
cards [2, for example] (or modules) offer their own implementation
of:
- TLV-encoding/decoding of cryptogram (with padding content
indicator), mac and le (depending on the APDU case)
- ISO padding of APDU header and data
4. General problems with code quality:
- A lot of dead code pieces ("#if 0")
- Usage of global switches instead of switches in the card context
- No or wrong documentation of the SM stuff
- directory "sm" should be renamed to "sm-modules"
These issues, I think, disqualify the SM branch to be included in
OpenSC's trunk.
The biggest problem, I think is the coexistance of two independant SM
hooks. In general I dislike the concept of a SM module, because all
OpenSC initialization magic is lost, when only the APDU buffer is passed
to the module. If a module is only used for external keysets, then it
should do only encrypting/decrypting/authenticating instead of handling
the whole smart card stuff. Then, what you get is OpenSC that handles
smart card stuff, including SM encoding and a crypto layer with loadable
modules.
[1]
http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015121.html
[2] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-epass2003.c
[3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h
--
Frank Morgner
Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE http://openpace.sourceforge.net
IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc
pgp2Rj2DuK9Gz.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
