Andreas Jellinghaus a écrit : > Hi Viktor, > > I like the idea of adding secure messagin! > > but in general: I think it would be nice to be able to > encrypt all communication. think of contactless smart > cards, I don't want data like the certificate go over > the air unencrypted for privacy reasons. Ok, it can be done at APDU transmit level, as Nils suggested. I'll think about it. Key-set can be placed locally: into opensc.conf or into the loadable module.
Rather, I supposed, that SC midlleware do not know the card's key-set. SM_server (or entity that know key-set) is an integral part of the Smart Card Manager, that in its turn is coupled with PKI. The cards key-sets are stored (or generated with some master key stored ) somewhere in secure place (cryptobox, other smartcard, ...). So, the intention was to reduce the requests to SM_server and encrypt only the sensible exchanges. > about the code: why add it as loadable module? > if you have cards where the secure messaging details are > under NDA that is ok. still it might be easier for all > of us if you had a private opensc version with that patched > in, rather than us loading modules. For me it seemed more flexible: in one case you place the key-set localy, in other case the key-set is on a distant server. The OpenSC library is the same, the difference is in a relatively small module. Also, with the loadable module there not so much changes to the OpenSC common part. > > also the patch adds a "sm" subdirectory, but does not include > any files in that dir. so we can't compile/test it. personally > I would prefer to keep all files in one directory (the > libopensc/ libpkcs15init split for example is something we now > regret, didn't get us much except complexity). It can be moved to "tools" or to the "contribution". For me essential is that OpenSC API gives the possibility to implement at least on the card driver level. > >> - secured APDUs are generated by some external SM_server (in my case >> it's HTTPS server). >> OpenSC access SM_server via the SM_module. SM_module to be used is >> defined in opensc.conf >> and is loaded during the sc_context initialization. > > why that? if you want a server to send commands to the card, that could > be done much easier without using opensc on the client at all - a simple > openct or pcsc app could do that. The to use SM inside the normal pkcs15 or pkcs11 sessions, and to hide (as far as possible) the SM specifities from these levels. > it is ok for you to do that, but I wonder if other people will want that > as well - whether it makes sence to have this in the generic code we > ship? That's why I posted it. I would like to get know if there is an interest to SM, and how the people are currently use it. IMHO, implementation of loadable module has little impact to the common OpenSC part. Then each card driver decides for its own if it will use SM . > >> Current trunk version of libopensc/card-oberthur.c contains (in >> comments) >> the SM specific procedures. >> Full patch (too voluminous for this mail) >> contains SM_server tool to generate secured APDUs, and SM_module >> implementations. > > I guess for the general use it might be nicer to have everything build > into opensc, without external modules and external server. still if we > find a scenario where other people will want that too, we can think > of adding it. but normal users will not want to install a webserver > to initialized a oberthur card with secure messaging ... I do not propose to include external server. I propose extention to API, that makes possible using of SM via the loadable module. If there will be an interest, part of SM procedures, currently included in card-oberthur.c, can be generalized into the separate file in libopensc. In the full patch there are examples of the loadable modules, library that contains the procedures of the GlobalPlatform SM processing and command line tool that helps generate secured APDUs. > > we could merge a generic secure messaging into opensc, and offer the > webserver / rpc / ... code as patch in the contrib directory and see > if people want to use it? sure, would be extra work to maintain, but > I would prefer not to merge it till we get feedback (adds a lot of > complexity most people won't need). > > can you put up a full diff somewhere? either post it to the list, > attach it to a new bug, or commit it to > https://www.opensc-project.org/svn/files/trunk/contrib > ? contrib/opensc-0.11.1.trunk.20061204-sm.patch.tgz It's the full patch for opensc-0.11.1/trunk of 2006.12.04 . > > Thanks, Andreas > p.s. sorry for answering this late. currently I have next to no time > for opensc. Thank you, kind wishes, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
