Hello,
Frank Morgner wrote: >>>> What are the limitations in OpenSC? >>>> >>> 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. SM is not implemented by card driver, but the separate SM procedures. These procedures implement two kind of SM and are linked into the external loadable module. Actually the 'local' version of SM module is commited -- this module have an access to the keysets or KMC (defined in opensc.conf). This 'local' version have an interest for testing and, probably, for contactless cards and the using of the 'virtual reader' that allows 'remote card control'. >>> This leads to duplicated code. For example, what I saw >>> at the first glance is that every card driver implements bitpadding. >>> Can you illustrate your thesis by the references to the source lines, please? Once more, there is two kind of SM, each represented by one card. >>> 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. >>> Your approach (or similar) is declared in the future intentions of OpenSC. http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/apdu.c#L383 This approach means securization of the APDUs at the 'apdu-transmit' level and, sure, one day it will be implemented in OpenSC. (By the way, for the card that you are using, does all of the ISO commands can be protected by SM? In your source I do not found the filtering for such a commands.) What is actually implemented is the securization at the 'libopensc' level. Here, in a difference to the previous mode, SM is activated only when it's needed (according to the ACLs of the operation that is going to be executed). This approach allows the card objects to be protected by multiple keysets. It also allows to reduce the charge of the 'external SM securisation entity', that have an access to the keysets and can perform securisation of APDUs. >> 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. Actually are supported SM defined in Global Platform SCP01 and SM defined in ISO-7816 in it's IAS/ECC version. The first one is represented by Oberthur's AuthentIC v3 card, and second by IAS/ECC cards. > 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. > > >>> 2. I suggested a change for handling SCardControl (ticket 235), >>> because there are readers with special capabilities for the nPA. But >>> even this simple suggestion (and simple patch) was not accepted. >>> >> IMHO #236 does not make much sense, whereas #237 does. The patch in >> #237 makes perfect sense and will be included soon as it gets used by >> some piece of code in OpenSC, like one of the three tools. Until >> somebody finds the time to re-write those places to make use of it, it >> is not good to add a feature and then forget it and end up having dead >> code around. There's plenty of that already. >> >> Feel free to change some of those tools to make use of the new >> function to speed up the inclusion of your patch. >> >> >> >>> Currently the discussion is stuck at the argument that OpenSC is for >>> PKCS#15, which the nPA doesn't support. >>> >> The thing with standards is that you can call anything a standard, but >> nobody cares unless it is actually used by more than a few vendors >> (remember the XML thing by Microsoft?). PKCS#15 has been the best >> option this far (and has been around for quite some time), but >> nevertheless, it is not perfect and certainly not the only one. But it >> helps to try to "think like PKCS#15" when working with OpenSC. >> >> OpenSC aims for two targets: to provide tools for personalizing smart >> cards, and to provide tools and interfaces to use either those cards >> personalized by OpenSC or cards that get emulated to a PKCS#15-ish >> structure. OpenSC has settled on PKCS#15 for cards that it writes >> (but there's some code by Viktor that allows PKCS#15 initialization >> emulation-virtualization as well, don't know that so well yet), but it >> is not and should not be too hard to emulate a PKCS#15-like structure >> for read-only crypto cards on top of almost anything. >> >> 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 I suppose two things. First big patches are not welcome, or at >>> least they are unlikely to be accepted. >>> >> I'm very sorry if you feel like this. I did not find the time to reply >> any sooner, nor could anyone else reply to your e-mail as it was in >> the moderation queue. >> >> If you are in doubt, I'd like to assure you that there is no >> discrimination nor acceptance barriers except for common sense and >> best practices in OpenSC. This has also been described in the OpenSC >> development policy [1], to keep it very transparent to anyone who >> wishes to improve and work with OpenSC. >> > > I must admit that my statement above was quite harsh. 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. > > >>> 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. > > Greets, Frank. > Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
