Hi! > > 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 am happy with whatever works. All I am saying is, that so far do_single_transmit only transmits APDUs without modifying its content where sc_transmit_apdu does this splitting hence modifies the APDU. > > 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 ? Are your key sets relevant to the encoding of the APDU? If not, then you could see key sets as part of the crypto layer. > > 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) . I agree. But you have to keep in mind that ISO-7816 subsumes multiple cards, which only differ in crypto. Cheers, Frank.
pgpFd7YrrU3cw.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
