Hi! > >>> BTW, what is the status of SM in trunk. It used to be scheduled for > >>> 0.12.3. If there is clearity about how to integrate it, I could also > >>> provide a generic implementation of PACE (generic = "PACE done by OpenSC > >>> not by the reader"). > >> > >> There is SM dedicated github branch > >> https://github.com/viktorTarasov/OpenSC/tree/secure-messaging > >> > >> > >> The main development is almost finished -- still pkcs#11 has to be > >> redesigned to meet the multi on-card application needs. > >> http://www.opensc-project.org/pipermail/opensc-devel/2011-November/017338.htmlid
So just to get the correct impression: All design decisions regarding SM are more or less final and consider the different needs stated in http://www.opensc-project.org/opensc/wiki/SecureMessaging ? > >> Two SM protocols are supported -- GP and CWA14890; > >> two types of SM usage -- 'apdu-transmit' and 'ACL'. > >> > >> > >> Development and tests where done with an external loadable SM module > >> (commited the 'local' version of SM module), > >> there is the possibility to implement (rather invitation to improve) > >> static card specific SM module. > >> # grep encode_apdu ./src/libopensc/*.[c,h] > >> > >> > >> GP& 'apdu-transmit' is tested with Oberthur AuthentIC 3.2, > >> CWA14890& 'acl' tested with IAS/ECC card from different producers. > > We discussed earlier that GP is a SM encoding for itself. > > Sorry, what do you mean? http://www.opensc-project.org/pipermail/opensc-devel/2011-April/016295.html > > Is CWA14890 > > (or an other implementation in the sm branch) conforming to ISO 7816-8? > > The card that I use for tests declares to be based on 7816 series, including > 7816-8, > as well as on prEN 14890-1:2006 and prEN 14890-2:2006. > These last ones also declares compatibility with 7816-8. > > This, and also rapid inspection of ISO 7816-8, gives me a reasonable > conviction that presented implementation conforms the 7816-8 . OK. So at least for 7816 compliant cards we should take a more layered approach than writing a encode_apdu/decode_apdu for each of these cards again (-> code duplication). I have advocated for this approach earlier (see the conversation referenced above). My implementation for nPA separates 7816 encoding from card speciffic encryption/decryption using call back functions. Do you want me to introduce this kind of abstraction for 7816 cards? Also having a look into your code, I can see that a more potent ASN.1 implementation is needed. I used OpenSSL for tags on more than one byte, you are encoding it by hand (sm-cwa14890.c:347). AFAIK OpenSC's implementation does not support that. Greets, Frank.
pgppcGFBYX1io.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
