Hello, Le 04/07/2012 00:06, Frank Morgner a écrit : > 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?
Difficult to divine what you mean. Is it card specific 'free-sm-apdu' called inside sc_single_sm_transmit() ? Memory for SM-APDUs is allocated by card specific 'get-apdu()', so it's quite natural that it's freed by card specific 'free-apdu()' . Allocation of sm-apdu and especially it's freeing are card specific and could be more then simple call to malloc() and free() -- let it be the card specific. >>> 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. This and previous are not card specific but SM type (GP, CWA) and authentication scheme (symmetric, asymmetric) specific. But you have a reason -- challenges and keysets can be moved inside the session typed data. >>> 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. Module handlers have not access to the 'sc_card' data, and I prefer to not change it. > 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)? It could be, I don't see the advantage. Note also that module handles use not the 'sc_apdu' but the 'sc_remote_data' data type . > 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? For this card only the 'APDU-TRANSMIT' SM mode is implemented. It uses only one 'remote-command' (APDU_TRANSMIT) type. Such conversion is possible only in this case. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
