Hello, Le 14/06/2012 23:55, Frank Morgner a écrit : >>> However, sm.h still requires you to know cwa structures and gp >>> structures. This is typically what you would want to abstract with a >>> SM layer. Look at opensc.h and cards.h, which offer a similar >>> abstraction to the smart card driver. If you add a smart card driver >>> to opensc, you only have to add sc_get_yourcard_driver to card.h and >>> add it to internal_card_drivers in ctx.c. Effectively, you have to >>> add only two lines to OpenSC's core files and your card driver is >>> integrated. Now think about what you would have to change when >>> adding a new SM implementation with your architecture. >> The difference between libopensc and SM is that there is only one ISO >> specification for the cards, and there are at least two SM >> specifications -- GlobalPlatform and CWA . > I don't get your argument. libopensc doesn't force you to base your card > driver on the iso7816 driver you are free to implement the call back > functions as you want. This is absolutely compatible with non-7816 > cards -- simply change the call back functions as needed. > > To be clear on the terminology: CWA'SM extends ISO 7816-4's SM. *Please* > look at both documents and search for the differences regarding SM. You > will find out that CWA is more specific in that it allows only one > specific configuration of ISO 7816. Also, it requires the usage of > Triple DES and Retail MAC. Thus, the two SM standards are ISO and GP.
I do not separate ISO and CWA -- for me it one entity. I'm talking about difference between GP and ISO&CWA version of SM. > Now imagine, you have a SM driver for ISO 7816. And you have built into > the ISO 7816 SM driver call back functions for doing the crypto > operations. Then CWA is perfectly compatible with the ISO 7816 driver > with call back functions for DES and Retail MAC. That's what I am > proposing. In the SM of actual 'staging' the essential part (in libopensc) is the SM related call back handlers for the card driver and external SM module. And also the general and type specific SM data. What you are proposing (afaiu) is the further stage -- optimizing and structuring of SM crypto library and APIs that have to be used by SM handlers and module . In the current SM framework I do not see contradictions or excluded possibilities. >> In sm.h the SM data types include the sub-types specific for the SM >> specification, in the same manner as pkcs15-key data type includes the >> data types specific to the different key types -- RSA, DSA, GOST, ... > If that's the case, using an abstraction layer for the crypto operations > can be useful here, too. I do not understand what you are looking for: there is the generic level of crypto data types and operations, there is level of data and operations that is a key type specific . The same in SM: generic SM data types that has 'parameter' member where are the SM type specific data to be placed. >>>>> 2. There are at least two methods to hook into SM, using a SM module and >>>>> implementing SM at the driver level. This conceptually introduces >>>>> duplication. It is sure to be followed with code duplication. Both >>>>> should be unified: Each card driver has a SM driver, which provides >>>>> wrapping and unwrapping SM. A SM driver can then also be a SM module >>>>> with external key sets. >>>> Was it a question? >>>> Yes, there are two methods to trigger SM wrapping: 'APDU transmit' and >>>> 'ACL' mode. >>> I don't understand ACL mode, because it isn't used anywhere. (This, by >>> the way, begs the question why it is defined...) The two hooks I see is >>> via module or via implementation by the card driver. I am advocating >>> for merging sm_module_operations and sm_card_operations. >> ACL mode is used when decision to-use or not-to-use SM for the next >> operation is derived by the ACL for this operation. >> Example is the iasecc card driver. > Hmm, SM_MODE_ACL isn't used anywhere... > >>>> Duplication can happen due to fact that each card driver implement SM >>>> as it wants, and can include into card specific part entire SM crypto >>>> library. >>> Code duplication is bad. It leads to error duplication and other >>> problems. >> Once more, the card drivers are relatively free inside their >> card-specific part. >> >> My humble opinion is that during the period of implementing of the >> common SM framework, we could tolerate some code duplication. > Although every driver in every card is free to do whatever it wants, you > might want to give it some possibilities for simplifications. So let's > *design* a flexible SM framework instead of saying "you are free to do > whatever you want". CWA, epass2003, nPA, OpenPGP, DNie (afaik) are > all based on ISO 7816 SM. Abstraction layers will help to find a common > and robust code base between those cards. Agree, but let's start from definition of (the most) generic SM types and SM related handlers . The abstraction of SM related crypto can be the next stage. >>>> I do not contest that duplication can happen, but: >>>> - it should not be obstacle to the implementation; >>>> - please point out exactly, where in code you see duplication. >>> - CWA implements SM according to ISO 7816 ([4], p67) and so does >>> epass3000. >> Once more, >> card driver can do what it want if this do not hurts the common part, >> or until the moment when the common SM framework will be installed. > What do you mean with "will be installed"? As I understood it, patches > that go to staging will later go to master, when they are more or less > evaluated. What changes to the SM framework are you planning to do? I mean the common SM related crypto library, that can be used by drivers or external SM module. Afaiu, that's the main point of your intentions. >>> - About two years ago I have pointed at some places where bit >>> padding is implemented multiple times (with different >>> implementations) -- this still holds today. >> Sorry, I will not be looking for where two years ago you pointed these >> places, please, point them here and now . > http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015129.html > The places have not changed much. > >> If this bit padding takes more then few lines in codes, we will >> certainly create some dedicated procedure. > http://lmgtfy.com/?q=bit+padding > > grep for 0x80 Greatly appreciated, but please, make a reference to the actual code in 'staging'. >>>>> 3. As stated earlier, I am advocating for an additional abstraction >>>>> between encoding and encryption. Thus, a SM driver would only >>>>> implement encoding, offering an other abstraction to the crypto. >>>>> Not implementing this abstraction has led to code duplication [1]. >>>>> And reinventing the wheel will continue, when all ISO-7816-like >>>>> cards [2, for example] (or modules) offer their own implementation >>>>> of: >>>>> - TLV-encoding/decoding of cryptogram (with padding content >>>>> indicator), mac and le (depending on the APDU case) >>>>> - ISO padding of APDU header and data >>>> As stated ealier, every card driver (at least at the beginning) can do >>>> roughly what it wants inside it's card specific part. We have only >>>> started to introduce the common SM framework, and for a while, we will >>>> not blame the card driver if it includes it's own SM related crypto >>>> procedures (... and thus duplicates the code. Is that the code >>>> duplication that you are talking about? >>> Yes, a good architecture can reduce code duplication. Again, look at >>> OpenSC's card drivers. All can do what they want -- that's fine. >>> However, most drivers are reusing the iso7816 driver adding some tweaks. >>> For SM implementations, we should offer the same possibility. >> >> Already answered: one specification for card, two specifications for SM. > I don't quite see what question you have answered. I am not saying that > we should abandon the GP SM implementation. Instead I want to keep GP > and ISO SM. But what I am saying is that it should be possible to > configure the ISO driver to be used in multiple configurations (e.g. > with different crypto functions). Agree, it's not the answer, sorry. The answer is that in 'staging' actually defined are the generic SM data types and handlers. That allows different cards to use SMs right now. We can improve it further by introducing of the common SM crypto library and API. What do you mean by 'configure ISO driver'? Actually in opensc.conf there is possibility to define the card specific SM section. I do not understand 'driver to be used with different crypto functions' . Example of different crypto functions? >>>>> - Usage of global switches instead of switches in the card context >>>> What do you mean? >>> g_sm in epass3000 >> Already answered, >> 'g_sm' is the epass2003 internal issue. >> It has no relation to the common SM framework. > Well, it *uses* the SM framework. So I consider it as related. That > epass2003 re-implements ISO 7816 SM shows the deficits of the current SM > framework. It uses the SM related callbacks and implements it's own SM related cryptography. I agree, here is the deficit of the current SM framework and it's opened for the further improvements. > g_sm, however, is only flaw that I saw at the first glance. Earlier, > someone was talking about "perfect patches". g_sm shows that the SM > patches (regarded as series of patches that introduce SM as framework > and some actual implementations) need more reviews. Once more, 'g_sm' is the internal affair of this driver. It's true that it could be easily replaced by using of current 'sm_mode' member of sm context. You could make a proposal for the attention of the owner of this driver. >>> By the way, is there a possibility to comment on code? I think, >>> github only lets you comment on commits. I looked through the code >>> yesterday and found some other problems, which would have been easy >>> to report... >> All these codes was pending long time in the dedicated branches and in >> the github pull requests -- you could comment them there. >> >> Now you can do it here. > Our discussion so far lets me think that it can take a long time, here. > Also, I want convenience as in "click here to report a problem". Isn't > there anyone who has hacked that before? > >>>>> - No or wrong documentation of the SM stuff >>>>> - directory "sm" should be renamed to "sm-modules" >>>> ... >>>> >>>>> These issues, I think, disqualify the SM branch to be included in >>>>> OpenSC's trunk. >>>>> >>>>> The biggest problem, I think is the coexistance of two independant SM >>>>> hooks. >>>> You simply cannot cover all SM use cases with one low level SM wrapping >>>> method. >>>> But understand you quite well -- you know/use only this one. >>> I disagree. I think it is possible. Simply look at the interface to >>> OpenSC's card drivers. >> >> It's about ACL SM mode. >> >> Two years ago I asked you: >> how do you imagine to deal with more then one keysets for one >> card/application ? >> to deal with the mixed card operations -- when not all card transactions has >> to be SM wrapped? >> >> Until now I have no answer. > I think you didn't ask... Anyway, the solution is easy and it is present > since more than two years in my SM implementation [5]. I don't think that with your SM implementation it's easy to support the SM protection of different operations/files with the different keysets. Let's say, the update of files/SDOs in 'protected' application is protected with one keyset and the Q.signature or PIN unlock protected by another. (Just to remind -- only one SM session could be opened at the time.) > If sc_read_binary > (or whatever) is done on a non-protected file simply do: > sm_ctx.active = 0; Is that the 'configuration' that you mean? Configuration by changing the code? > (for struct sm_ctx see below). The idea is to let the card driver > configure the SM driver whenever needed. >>>>> In general I dislike the concept of a SM module, because all >>>>> OpenSC initialization magic is lost, when only the APDU buffer is pasfsed >>>>> to the module. If a module is only used for external keysets, then it >>>>> should do only encrypting/decrypting/authenticating instead of handling >>>>> the whole smart card stuff. >>>> External module do not handle all the smart card staff, but it has to >>>> do part of it. Example: when importing, the RSA key has to be >>>> presented by a sequence of 5-7 APDUs, which could be different for the >>>> different cards. So, external module has to be able to compose the >>>> plain APDUs . >>> Partly wrong: Yes, SM has to be smart card aware (as you have pointed >>> out with your RSA example). But the crypto module should not need to be >>> smart card aware. The whole point of your sm modules (correct me if I am >>> wrong) are cryptographic keys, which are located somewhere else. When it >>> comes to your RSA example: Simply let OpenSC collect all RSA data and >>> then send it to you crypto module. >> What 'OpenSC' are you talking about? The one that is installed on the >> client side? The hole idea is that this part have never access to the >> plain RSA key and cannot send data to the crypto module. > Hmm, you said that the RSA key is presented in 5-7 APDUs. Whatever this > representation is or who you are representing it to (card or SM module), > just forget about APDUs for a second. Look at this representation as one > big blob, that can be sent to (or from) the SM module (or to the card > driver). In libopensc's card driver you can split up (or assemble) the > data into APDUs. Remember, I am talking of three layers of abstraction: > Card driver (APDU aware, local/client), SM driver (for encoding of SM, > APDU aware, local/client) and Crypto (*not* APDU aware, remote/module). Probably here is a *certain* misunderstanding of the problematic. The RSA key data cannot be always presented as one continuous blob of data, and cannot be split in a arbitrary fashion by libopensc. Just to remind, in plain mode the libopensc driver receives key data as a RSA (OpenSSL or pkcs15-rsa) data. These data, component by component, are encoded by libopensc into the sequence of APDUs -- it's not a simple split or chaining of the unique blob. In SM mode with the distant keyset, libopensc do not receives the RSA plain data, and so cannot compose the APDUs and call the SM wrap procedures. It's up to external SM module to compose APDUs. These APDUs can be card specific, but also card-context specific (for ex. the # of allocated key slot is present the APDU data to be wrapped by SM). >>>>> Then, what you get is OpenSC that handles >>>>> smart card stuff, including SM encoding and a crypto layer with loadable >>>>> modules. >>>> Sorry, do not understood. >>> Do something like: >>> >>> struct sc_card_driver { >>> ... >>> struct sc_sm_driver *sm; >>> ... >>> } >>> struct sc_sm_driver { >>> ... >>> struct sm_ctx *sm_ctx; >>> int (*get_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct >>> sc_apdu **sm_apdu); >>> int (*free_sm_apdu)(struct sc_card *card, struct sc_apdu *apdu, struct >>> sc_apdu **sm_apdu); >>> ... >>> } >>> /** Secure messaging context */ >>> struct sm_ctx { >>> /** 1 if secure messaging is activated, 0 otherwise */ >>> unsigned char active; >>> >>> /** data of the specific crypto implementation */ >>> void *priv_data; >>> >>> /** Padding-content indicator byte (ISO 7816-4 Table 30) */ >>> u8 padding_indicator; >>> /** Pad to this block length */ >>> size_t block_length; >>> >>> /** Call back function for authentication of data */ >>> int (*authenticate)(sc_card_t *card, const struct sm_ctx *ctx, >>> const u8 *data, size_t datalen, u8 **outdata); >>> /** Call back function for verifying authentication data */ >>> int (*verify_authentication)(sc_card_t *card, const struct sm_ctx *ctx, >>> const u8 *mac, size_t maclen, >>> const u8 *macdata, size_t macdatalen); >>> >>> /** Call back function for encryption of data */ >>> int (*encrypt)(sc_card_t *card, const struct sm_ctx *ctx, >>> const u8 *data, size_t datalen, u8 **enc); >>> /** Call back function for decryption of data */ >>> int (*decrypt)(sc_card_t *card, const struct sm_ctx *ctx, >>> const u8 *enc, size_t enclen, u8 **data); >>> >>> /** Call back function for actions before encoding and encryption of \a >>> apdu */ >>> int (*pre_transmit)(sc_card_t *card, const struct sm_ctx *ctx, >>> sc_apdu_t *apdu); >>> /** Call back function for actions before decryption and decoding of \a >>> sm_apdu */ >>> int (*post_transmit)(sc_card_t *card, const struct sm_ctx *ctx, >>> sc_apdu_t *sm_apdu); >>> /** Call back function for actions after decrypting SM protected APDU */ >>> int (*finish)(sc_card_t *card, const struct sm_ctx *ctx, >>> sc_apdu_t *apdu); >>> >>> /** Clears and frees private data */ >>> void (*clear_free)(const struct sm_ctx *ctx); >>> }; >>> >>> (struct sm_ctx is actually copied from my approach to SM [5]) >>> >>> Now, you have two points to customize SM: First you can specify get_apdu and >>> free_apdu (which should really be renamed in something like sm_wrap_apdu and >>> sm_unwrap_apdu). Second, you can change the call back functions that >>> actually >>> calculate a cryptogram or a mac using external keys. The second hook does >>> not >>> need to be aware to smart card stuff. >> >> I do not see radical difference between what is currently committed to >> 'staging' and your proposals. >> >> We can longly argue about importance of one or other feature (post-transmit, >> pre-transmit, priv-data, ...) . >> The only question that I would like to ask is: >> I'm sure that the current SM framework can answer your needs that concerns >> the low level SM wrapping of APDUs. > Well, plain libopensc fitted my needs regarding SM. The current SM > framework, however, does not give me any advantages. What I want is > better integration of my cards (thats why I am bothering with the SM > framework so much), reusable code and clean interfaces. Both of the > latter points require changes to the current SM framework. Advantage ? Actually there is the *possibility* to integrate your card, as well as the other ones. The rest is up to you. If you looking for the common SM related crypto library and API -- you can propose it. As I've told, the current state of SM framework concerns mostly the generic SM data types and callbacks. >> Can you do the same in a regards to the needs of external SM module, >> support of the two SM specifications, more then one keysets per >> card/application ? > Again, this is easy to do: simply let the local card driver do all the > message parsing (because libopensc already does a lot of this magic) and > configure the external module appropriately. How you are configuring a > module is up to you. ..... >>>>> [1] >>>>> http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015121.html >>>>> [2] >>>>> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-epass2003.c >>>>> [3] https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/sm.h >>> [4] ftp://ftp.cenorm.be/Public/Cwas/e-europe/esign/cwa14890-01-2004-Mar.pdf >>> [5] http://vsmartcard.sourceforge.net > Look, I am currently integrating my iso 7816 SM driver into your framework. > I don't have much time, thats why this could take some weeks. But this > is only part of the problem. For several reasons, there are some things > I can't do: > - change CWA-cards and epass2003 to use the iso SM driver > - merge the card driver SM call back functions (`struct sm_card_operations`) > into an SM module (`struct sm_module_operations`) or the other way > round. > - testing with different real cards > As I understand it, you do not share my opinion on the deficits of the > current SM framework. If so, I don't see those things happen any time > soon. Is this correct? I do not share you opinion that current SM framework needs important changes. I agree that it has to be completed. I don't understand why you definitively need to merge the SM module and SM card operation. You can extend the SM card operations and leave aside the SM module. At the beginning you don't need to touch a lot the epass2003 driver. It uses three SM callbacks, you can easily bypass/reuse/slightly-change them -- leave alone this card until you implement the support of your own card. You can ask Jean-Michel for the ePass2003 token. I can send you the IAS/ECC card, and finally, you can send me the yours. > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
