Le 27/03/2011 19:25, Frank Morgner a écrit : > On Sunday, March 27 at 01:42PM, Viktor TARASOV wrote: >>> http://www.opensc-project.org/opensc/wiki/SecureMessaging >> I've added my vision onto the SM implementation . >> Still to be finalized the proposal for the SM data types. >> I'll try to look over the prior works to see how their needs can be reflected >> in the common data types. > I think you should call the SM routines in sc_transmit_apdu instead of > in do_single_transmit. The SM APDU is usually longer than the > non-SM APDU. So the secured APDU could extend the readers/cards maximum > APDU length and is subject to splitting via chaining (which is done in > sc_transmit_apdu before do_single_transmit).
Probably you have a reason, but 'chaining' is not an argument . Imho, card driver has to be conscious that the card is used with SM and so, driver has to set the max_send/recv_size to the value that takes into account the possible increasing of the APDU length due to SM. Not all APDUs can be used via chaining. Example write/read_binary -- for these commands the only way to pass them through SM is to limit max/send/recv_size. > I think I implemented a simpler version of your approach for nPA without > file specific SM and without key sets (all this is entirely handled by > the card driver). Maybe it's simpler. In your 'npa' I see only asymmetrical authentication (that's why 'without key sets'), how do you propose to integrate symmetric authentication scheme into your layer ? Where from you will inject the keyset into your crypto layer to calculate session keys ? > What I am missing is a separation of ISO 7816 and the > specific cryptographic layer as stated before [1]. This is what Emanuele > calls a "building block" for reuse with different card drivers [2]. It seemed I've already answered this question, and you've done impression to agree. Its going about implementation of the two different SM protocols -- GP SCP01 and ISO-7816 . As authentication the first one uses symmetric, the second one should be able to use symmetric and asymmetric . The both uses (will use) a common 'involved cryptography' library. SM module (static or dynamic) make abstraction of the crypto layer for the non-SM ISO-7816 (libopensc) . > Greets, > Frank. Kind wishes, Viktor. > [1] > http://www.opensc-project.org/pipermail/opensc-devel/2010-October/015093.html > [2] http://www.opensc-project.org/opensc/wiki/SecureMessaging#Modularity > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
