Hello, On Oct 10, 2010, at 10:07 PM, Frank Morgner wrote: >>> 1. There is no kind of abstraction in the current SM code. At the >>> moment every card driver implements its own version of secure >>> messaging. This leads to duplicated code. For example, what I saw >>> at the first glance is that every card driver implements bitpadding. >>> In my implementation I am trying to separate encoding of a SM >>> message (which is for the nPA defined by ISO 7816-4 section 6) and >>> the actual cryptography. I described the process here for my SM >>> wrapper, sm_transmit_apdu, >>> https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace/sm.h >>> Adopting my aproach on the other hand would mean a rewrite of all >>> other card drivers with SM. >> >> There are not many card drivers with SM support (yet) and generally SM >> support is a somewhat moving target. Do you have practical suggestions >> for improvement? > > From what I have seen, message padding, the construction of the > authentication data and encoding of the SM APDU data is conform to > ISO-7916 for all SM cards, which opensc already supports. What I am > suggesting (and implemented in my SM implementation, see above) is that > these operations could be done by an abstraction layer that sits between > user input and the card specific configuration and implementations for > ciphers and authentication. So the card initializes some flags for which > parts should be included in the authentication data or the SM APDU data > and sets call back functions for the actual encrypting/decrypting or > authentication of buffers. Isn't it what Viktor is doing? With the addition of adding "remote encryptors"?.
>>> Currently the discussion is stuck at the argument that OpenSC is for >>> PKCS#15, which the nPA doesn't support. >> >> If the internal PKCS#15 layer is not sufficient to represent the >> (crypto) objects on your card, please point out the deficiencies so >> that it could be improved. > > The process for the new German identity card is complicated and doesn't > involve PKCS#15 at all: First EAC, then the terminal is authenticated, > and then the chip authenticates to the terminal. If this all was > successful, the data is send encrypted to the terminal. But the data > itself is not signed by a CA or simalar, the correctness of the data is > solely based on the 3 step protocol. I am not too familiar with OpenSC > PKCS#15 layer, but maybe I can have a further look, when/if there is > more support for the nPA. So nPA is a travel document style electronic password with no crypto capabilities itself? OpenSC is focusing on cryptographic smart cards. If there are no keys to be used via PKCS#11 or Tokend or something similar, it can't be "integrated" with the rest of OpenSC like a casual driver. be If there's only data to be read from the card, it would make sense to add it as a tool that brings in some from libopensc and some from a very fresh / patched version of OpenSSL (I see from OpenSSL list that this depends on Brainpool curves support in OpenSSL) to read out the data. Maybe improving "eidenv" tool to make the data available to applications. > Big patches are always harder to integrate, there is more discussion about it > and so on. > That's why it's more unlikely to be accepted. For example, supporting > the nPA would not only require to change OpenSC, but it would also mean > that you would have to use a patched version of OpenSSL. The whole > code we (at the Humboldt University, Berlin) have written to support the > nPA contains something like 8k (5k in OpenSSL, 3k for the card itself) > lines of code. So what I meant is that this is unrealistic to be > integrated, I did not mean that you don't appreciate the work and > participation of others. I would not be that pessimistic :) You have not shown a possible patch that would be needed for nPA in OpenSC so it is hard to say. I've tried to look at the vsmartcard project but as I don't have the hardware it makes little sense to me. And it does not seem try to integrate into OpenSC, in a way that it would be possible to extract a patch. > >>> Second, support for the nPA is not very important since it lacks >>> PKCS#15. >> If it has crypto capabilities, it is useful. It is hard if not >> impossible to objectively measure the importance of a card against >> others. As long as there's a developer and a maintainer and/or users >> for a card, the card becomes relevant. I think the best measure is the >> activity of users and developers for a given card. If you want to use >> nPA cards with/via OpenSC just let us know what needs to be improved >> or changed in OpenSC to make it happen. > > Well, in Germany everyone will get this card who applies for an identity > card after the 1st of november. So very soon millions of people will > have such a card since in Germany you must possess at least an identity > card or a passport. So there *is* relevance. But there are at the moment > only a hand full of developers since the card is not out in the public. > > So what needs to be changed? I have an implementation up and running > which is based on OpenSC. It should be easily integrated as card driver. > But my implementation uses also the SM abstraction I described above. > This abstraction layer of course only implements what is needed for the > nPA. So if integration in OpenSC is wanted, the question is whether to > rewrite the SM layer to match the card-centric aproach which is used at > the moment in OpenSC, whether to rewrite the SM card drivers of OpenSC > to use the abstraction or to use the already running nPA-tool and not > integrate it into libopensc. Can you prepare two patches against current trunk: the card driver and the related secure messaging code? -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
