Hi! > > SM is a term from ISO-7816, which AFAIK only has something like a > > security environment to group operations. So why do you propose to wrap > > chained APDUs with SM? > > Thanks for the comment. To tell the truth, I didn't explain this. I > propose to apply the general "transformation" concept both to single > APDUs and chained APDUs. In this way, we would be able to: > > 1. build a non-SM APDU > 2. if we need to, transform it into a SM APDU; > 3. if we need to, transform this APDU into a sequence of chained > APDUs, or something else; for instance, if I understand correctly, the > Spanish DNIe doesn't support command chaining, but rather wants this a > sequence of ENVELOPE APDUs;
Enveloped APDUs and Chained APDUs are not strictly the same: Enveloped APDUs can send effectively only one APDU (such as an APDU with a lot of data), where chained APDUs can perform a certain operation consisting of one or more APDUs (such as a get challenge chained with a PSO). > 4. finally, apply the last transform – the "send to the smart card" > transform – to the whole sequence. So your transformation concept is not strictly bound to SM but rather to smart card operations in general. An other approach would be to hard code the single steps of transmission rather than to use a more flexible chain. Note that hardcoding is already done in sc_transmit_apdu: An APDU, that is too long (e.g. extended length) is broken into multiple pieces and sent. The same is done for the response via get response commands. So what is the advantage of coding all this with your approach? > > I understand that it can be useful to separate > > potentially interfering operations, but this should be done on top of > > SM. To be more concrete, such a separation should be done on top of > > libopensc, since this could also be needed for non-SM-APDUs. > > I'm not sure I understand what you mean by "potentially interfering > operations", but the way I'm seeing it now, I think I agree fully with > your viewpoint. I was not thinking of merging two different APDUs that > both require SM into a single sequence. Rather, I was thinking of > being able to take what the upper layers see as a single APDU and turn > it into a sequence of APDUs to suit the card's needs (lack of extended > APDUs and the like). > > The only case that comes to my mind right now where two different > operations intermingle during the processing of a transformation chain > is this: it may happen that one of the stages needs to issue a > particular command to the smart card (like GET CHALLENGE, or GIVE > RANDOM). In this case, the upper layer (libopensc, or above libopensc) > does not know that there is a need for such a command to be issued, > since it is only needed to carry out the crypto operations; this is > why I see a need for the lower layer to be able to issue it > independently. (More precisely: one of the stages of the transform > chain would pause processing the SM APDU before having sent anything > to the card, issue the command, get the result, and use this result it > to carry on processing the SM APDU.) > > Concrete example: let's say we have to ask the card to perform a > digital signature. If the security environment and/or the private > key's BSO do not call for SM, we must only issue one APDU, and it will > probably be a standard ISO 7816-8 command (INS=0x2A, "Perform security > operation"). If, on the contrary, they do call for SM, then we *may* > have to issue different APDUs before that, but they aren't defined by > ISO 7816 and they depend on the card, on the crypto algorithms, on the > BSOs, etc. Therefore, I think it might be an advantage to keep the > upper layer clean and delegate these matters to the SM transformation > layer and to the card drivers (who, anyway, control fully how the > transform chain is composed). Don't fix what is not broken. Your approach is useful and could be integrated, but if you don't have something in mind that can be done only or better by your approach, it's hard to justify the work it needs. The German identity card uses a very good replacement for basic access control. It is basically an anonymous key agreement consisting of something like 6 APDUs. If some other APDU slips into this sequence, then it breaks the command chaining (this is what I mean with interfering). The key agreement could be one single operation queued up with multiple APDUs in one chain. But it could also be superseded by sending a sequence of subsequent APDUs (one at a time). This would not require the overhead of a transmit chain. Take for example sc_set_security_env or sc_pin_cmd. They are interpreted by the card driver and the driver can also send multiple (hard coded) APDUs instead of just one (no matter if they are standardized or not). > Sorry for being rather verbose; there's still some handwaving in this > architecture and I try to explain it as clearly as I can. Your > comments are obviously most welcome! :) (And please, let me know if I > got your point or if I missed it! :) ) I think I understand your approach. The question aims more at the advantages of it. Cheers, Frank.
pgppcz6lGa3Qw.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
