Hi! In OpenSC, the caller allocates memory if needed, afaik. Is there a specific reason why sc_single_sm_transmit breaks with this approach when getting the SM APDU?
> > 1. In struct sm_secure_channel, what is the difference between the > > keyset and the session? The GP/CWA structures of keysets and sessions > > all hold cryptographic keys. > > Session keys are the result of mutual authentication and are > calculated by both sides (IFD and ICC) that share (or trust) some > common secret. > > Keyset are static symmetric key(s), shared by both sides, and that are > used to calculate session keys in the case of symmetric authentication > scheme. In GP and CWA the keysets have a different look: three parts > in GP, two parts in CWA. GP keysets can be presented to application as > direct values, or as a 'master' key that needs to be 'diversified'. So the key set is the basis for a SM key agreement, where the derived keys are put into session, right? > > 2. Which roles play host_challenge and card_challenge in struct > > sm_secure_channel? AFAIK, an SM channel does not depend on a nonce. > > > > What do you mean 'SM channel'? > ICC and IFD challenges are used by both sides to calculate session keys. > Both sides exchange these values during the authentication negotiation. This is card specific and does not globally apply to SM. I know cards which use longer nonces and different key agreements. I think sm_secure_channel.session would be the right place to put it. > > 3. Have you thought about unifying struct sm_module_operations and > > struct sm_card_operations? The operations open/initialize, > > get_sm_apdu/get_apdus, close/finalize essentially seem to do the > > same. > > > The difference is in prototypes, in data types, in 'context'. > > Caller and executor of the sm_card_operation handlers share a lot of > common data via the 'sc_card' data, including the common SM session. > The data of the only one APDU is exchanged. > > The module is 'session-less' -- every handle call needs all necessary > data to re-calculate session key, restore SM context, etc. > Module can return chained data of multiple APDUs . 1. Sessions: sm_ctx is always present in sc_card_t, when sm_card_operation.get_sm_apdu is called. The session information is available in both cases. 2. APDU chains: Why not handle multiple APDUs with subsequent calls to sm_card_operations.get_sm_apdu (an error code could indicate if more APDUs must be transmitted)? Look at card-authentic.c:2349 where you are actually already converting a call from sm_card_operation to sm_module_operations. Is there a case where this conversion can't be done? -- Frank Morgner Virtual Smart Card Architecture http://vsmartcard.sourceforge.net OpenPACE http://openpace.sourceforge.net IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc
pgp89r36ySKzg.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
