>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've tried to write my comments into wiki but seems that my user "jonsito" is not recognized or has an incorrect email address. Please help.. >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). Sure: in DNIe SM this is the way to work, as DNIe does not use APDU chaining but envelope cmd, as states in iso7816-4 sect 7.6.2 for SM handling >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). 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]. Some comments on Victor's suggestions regarding on DNIe: DNIe doesn't need to stablish SM channel at init, but in the first "secure" operation (usually "verify pin" prior to any pso). But once the SM is stablished cwa-14890 states that SM must be used for every further transaction. A Solomon's solution is to get init() to prepare al SM related data, but relay SM stablishment until really required. Notice that for cwa-14890, external data (Certificates, keys,card serialnr and so) are just required in sm_init(); kenc, kmac and SSC u8 arrays are the only required data for SM session handling once stablished, cwa states that SM channel is to be off on deinit(), reset(), or SM transaction fail (66 88 apdu response). Some glue logic is required to detect SM tx fail and (if needed) reconnect. No specific APDU is provided to disable SM, but reset is suggested 'APDU' Mode is just what I do, so is ok for me :-)... But notice that -at least in cwa-14890- standard every SM transmit _requires_ a get_response() command About 'ACL' mode. Not sure, but perhaps a simple flag "SC_APDU_FLAGS_SM_REQUIRED" would avoid replication on every sc_xxxx_ function Finally: DNIe doesn't support Logical channel in APDU commands. This means that concurrent access to pkcs11 (ie: an https firefox connection to a page that runs a signing applet) doesn't work I'm writting a "SM apdu server" for DNIe. This splits opensc in a sort of client (libopensc) - server (reader driver at sc_transmit_apdu() call level) system. Not sure on collateral implications, or if there is a better approach to this problem. Perhaps a solution could be create an intermediate "SM reader driver" that catches every sc_transmit_apdu(), handles SM and calls in turn to the "real" reader driver ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/cwa14890-01-2004-Mar.pdf Juan Antonio
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
