On Fri, Mar 25, 2011 at 22:34, Frank Morgner <morg...@informatik.hu-berlin.de> wrote:
> 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; 4. finally, apply the last transform – the "send to the smart card" transform – to the whole sequence. > 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). 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! :) ) Best regards, -- Emanuele _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
