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? > >>> 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. > >>> 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) > 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. 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? Greets, Frank.
pgpKkrUwazWDi.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
