Le 10/11/2011 16:46, Frank Morgner a écrit : > 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
Ok, afais, the last words in this discussion "two different SM protocols -- GP and ISO-7816". >>> 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). This separation is already present -- SM specific 'sm-cwa14890.c' and card specific 'sm-card-iasecc.c'. I suppose that the delimitation of the procedures is not perfect -- most of the 'iasecc' specific could be renamed into 'cwa14890' and generalized into the 'sm-cwa14890'. For me, at the current stage, it's not so important and can be improved when support of some another cwa14890 card will be included. > My implementation for nPA > separates 7816 encoding from card speciffic encryption/decryption using > call back functions. I looked already your code, will look it once more. > Do you want me to introduce this kind of abstraction for 7816 cards? Any suggestions are heartily welcome. > 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). You have a reason. Sometimes a trivial TLV data are encoded by hand -- to make the things more simple. More complicated encoding are made with the OpenSC asn1 procedures -- your can see them in the same file. Will look how a simple encoding with the asn1 procedures looks like in code. > AFAIK OpenSC's implementation does not support that. Why? Do you mean technical or coding-style reasons ? > Greets, Frank. Kind regards, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
