gilles Bernabé wrote: > Hello, > Oh Victor I've recently realized a Firefox plugin with XPCOM C++, > for the moment I've implemented a scriptable interface that permit to > send APDUs from the Javascript code, > so you can do HTTP GET and POST(in Javascript) to exchange APDUs with > a server. > It's a very basic plugin, but it's the beginning, I will improve it > soon(interface and make it more portable), > > Dunno if it can help you for your project, but here is the source > code: http://github.com/gilb/SmartC > on the repo I have mentioned the systems on which the plugin works fine. > (in fact this plugin is a subproject of an academic project which is > an OpenID provider that authenticate smart cards owners)
Oh thanks. Here we use some XPCOM plugin to (re)load applets onto the card in a distant manner. Will be interesting to compare with your implementation. > > regards, > Gilles Kind wishes, Viktor. > > 2010/4/22 Viktor TARASOV <viktor.tara...@opentrust.com > <mailto:viktor.tara...@opentrust.com>> > > Hi, > > Martin Paljak wrote: > > On Apr 21, 2010, at 20:25 , Viktor TARASOV wrote: > > > >> I would like to start a new OpenSC sub-project, forked from the > current > >> trunk, > >> that should be an experimental branch for the implementation of > >> SecureMessaging, MultiApplication, > >> combined ACLs, etc. > >> > >> At the beginning this sub-project should support the cards natively > >> compatibles with PKCS#15. > >> > > A sub-project or a branch? I suspect the latter? > > > > Rather branch. > I guess that the svn, trac, wiki, ... facilities are the same for > sub-project and branch. > > > > >> The main features are: > >> - 'Secure Messaging' and 'External Authentication' are performed by > >> external, dynamically loadable module. This relatively small > module have > >> different implementations: > >> -- 'local' version have access to the keysets and used mostly > for tests; > >> -- 'distant' version should communicate with some distant > entity capable > >> to generate secured APDUs. (In our SCM application such a > module uses > >> IPC to communicate with XPCOM extention of the application's XUL > >> client-side part. This last one, in its turn, uses > XMLHttpRequest to > >> communicate with the distant server that has a knowledge of > keysets.) > >> > >> - two 'Secure Messaging' usage modes: > >> -- 'config' mode: all transactions that, according to card > >> specification, can be done under SM will be secured with SM (as > it was > >> suggested long time ago by the comments in 'do_single_transmit' > procedure); > >> -- 'acl' mode: SM (as well as External Authentication) used > only when > >> really needed and is triggered by ACL of the next operation. > >> > >> - Multi oncard PKCS#15 applications: example IAS/ECC card with > >> administration support that have 'general' and 'administation' > applications. > >> > >> - Combined ACLs: for example signature with NonRepudiation key > can ask > >> 'Sign-PIN && Sign-SM'; PIN unblock can be protected by 'PUK || > >> ExternalAuthentication'. > >> > > > > > > Just a curious: for "Sign-PIN && Sign-SM" the operation would > look how with pinpads? > > a) PIN is verified with a pinpad, without SM, sign operation is > sent with SM? > > > > Yes. Some of the cards that I have are initialized in this manner. > > I have other cards that protect with SM also PIN verification -- it > makes impossible using of PIN pad. > (Another example -- italian CNS card, that is going to be integrated > into OpenSC, have Sign PIN verification protected by SM.) > > > > b) PIN can not be verified with a pinpad, the PIN verification > and the sign operation both require SM (and thus the PIN block can > not be built by the reader) ? > > > .. > > > Does the "multi oncard PKCS#15 application" support require SM? > > > > Multi applications itself do not require it. > > The particular application can be initialized in the manner, for > example, that will need SM for the all administrative tasks. > Card manager can also ask SM for the operations with keys (generate, > import), even if on-card application allows to do it without SM. > > > Kind wishes, > Viktor. > > -- > Viktor Tarasov <viktor.tara...@opentrust.com > <mailto:viktor.tara...@opentrust.com>> > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > <mailto:opensc-devel@lists.opensc-project.org> > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
