Frank Morgner wrote: > Hi! > > On Tuesday, October 12 at 10:33AM, Viktor TARASOV 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. >>>>> >> 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 aproach sounds indeed more flexible than I thought it was. Does it > mean that you can choose between multiple keys for encryption/decryption > or can you also choose between multiple algorithms for > encryption/decryption/authentication/keyagreement? > Multiple keysets concern rather the card IAS/ECC, where, for example, 'unblock PIN, 'create Sign key', 'update internal PKCS#15 structure', can be protected by the different keysets.
>>>>> 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. >> > > Bitpadding is done here: sm-global-platform.c:222,250 sm-iasecc.c:450,92 > > Also ASN.1 encoding looks similar. But if there are two different > standards, where one of them does not include the other, this might be > OK. > OK, thanks. >>>>> 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.) >> > > Yes, once the SM channel is established, everything else is encrypted. > That's why I need to do it at the transmit-level. (For the key agreement > see EstablishPACEChannel in > https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace.c) > Not all cards allow using of SM for all the commands. Example 'SELECT FILE', 'GET CHALLENGE' for Oberthur's AuthentIC. That's why, I think that general implementation 'sm-apdu-transmit' should use somewhere the card specific filter. >> 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. >> > > Correct me if I am wrong, but isn't the apdu-transmit-aproach the more > flexible one. Meaning that you can do local and on demand SM with it. > There is no 'demand SM'. OpenSC can be configurated to use SM in a transparent for the application manner. Then everything depends on the where your keysets are. If they are local -- OpenSC is configurated to load 'local' SM module. If your keysets are distant -- OpenSC uses 'distant' module, that communicates with the distans entity to get secured APDUs, Also entire of card middleware and application (OpenSC, OpenSSL&engineOpenSC, ...) can be replaced to the distant entity to be closer to your keysets and to the confidential data (keys, unblock codes, ...) . In this case 'virtual reader' is used. > And in addition you can pass every command from the user through a SM > channel. This brings me to a more general question: Why developing in a > separate branch? > Because some experience is needed to be accumulated, to settle down the approach and concepts, with your help and the help of the other interested persons. SM implementation is rather heavy intervention into the common part of OpenSC. There are a lot of different cards that needs to be tested for non-regression. Also in this branch there is support of the multi applications. It also needs to be settled down before integration into the trunk. Branch allows to have rapidly some 'visible' extended support of the IAS/ECC cards. > Greets, Frank. > Kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
