|
Philippe C. Martin
pmartin at snakecard.com
Wed Oct 19 11:01:05 EDT 2005
On Wednesday 19 October 2005 02:43 pm, Nicolas Lehuen wrote: > A good book and a lot of reading on the web can't harm you, but your > problem is not a typical web application design problem. OK > > What you must straighten out is where you card reader resides : on the > client side or on the server side ? First you asked us questions about > running the card reader API on the server side, and now you ask us about > running it on the client side... > > If the card reader is on the client side, as I guess it is, then you're in > deep shtrouble. How deep depends on whether the client side is closed > (limited to a single enterprise) or opened (your app will be used by many > customers). > (****) Both; I'll get a bit into the smart card issue here: 1) On the server side there is a "Master" card which holds a Master crypto key 2) On the client sides there are "Children" cards each with a "diversified" crypto key 3) The point is for the Master card to decide whether such or such protected page can be accessed by the client. In order to do so, the following must happen: 3.a) the client card sends some card unique data to the master card 3.b) the master card sends a random sequence to the client card 3.c) the client card encrypts the random sequence (with its diversified key) and sends the result to the Master card 3.d) the Master card re-generates the client key with the earlier received data, uses it to decrypt the encrypted sequence and matches it with the earlier sent random sequence. if they match, the requested page access is allowed. > Neither Java or Flash applets can simply access low-level hardware nor call > a C API. You could try writing a JNI wrapper around your C API and see if a > signed applet loaded through the Sun JVM (which will have to be installed > on the clients) can use it, but it will be difficult and non-portable. I do not know about Flash, but the java VM will forbid me to access a local hardware device. > > Then, you can go the plugin way but it's even more difficult than the > applet way. All the more if you want to be multi-browser (as I've > understood since you wrote about IE and Firefox) and multi-platform. You'll > have to learn two different plugin APIs, learn COM and ATL, master the > delicate art of C/C++ multi-platform programming, etc. etc. Yeap > > In both cases, Javascript could be used to provide the glue between the > applet / plugin and the rest of the HTML app, but tthat's another level of > crap to handle since supporting scripting from a plugin is not something > automatically granted. OK > > Believe me, your problem is far from trivial, and given the level of the > other questions you asked, it will be way out of your league. You'd better > seek professional (and expensive) help. I'm sorry to be harsh but that's > the sad truth. Time will tell :-) > > If the card reader is on the server side, then it'll be difficult (you'll > have troubles with the API support for re-entrant calls or multi-threading) > but far more feasable. I understood that apache had "global" flags, I need to use something like that to keep two client from accessing the card at the same time (as it is not feasible for concurent access to an ISO7816 SC) My question on this NG is on the issue (****) and this back and forth of data without any user interaction - but again that is possibly a very trivial question. Regards, Philippe > > Regards, > Nicolas > > 2005/10/19, Philippe C. Martin <pmartin at snakecard.com>: > > PS: are these basic web dev questions, and I should just go read a book/ > > join > > a web design newsgroup ? > > > > Thanks > > > > Philippe > > > > On Wednesday 19 October 2005 03:03 am, Philippe C. Martin wrote: > > > Hi, > > > > > > I have "disabled" the xml feature for now to go on with my study. > > > > > > I can talk to my smart card on the server side and get the information > > > > on > > > > > the browser. > > > > > > On the browser side, I will, most likely, need to write browsers > > > > pluggins > > > > > as it seem the only way (besides stuff like activeX which does not > > > cover all the necessary platforms :-) to get access to a hardware > > > device from > > > > the > > > > > browser. > > > > > > The current authentication mechanism my cards use requires that data go > > > back and forth a couple of times between the server (master/mother > > > card) and the client (child card). > > > > > > Also the data exchanged, if possible, must not appear on the display. > > > So > > > > I > > > > > need some type of handler that'll allow that "back and forth/hidden > > > exchange". > > > > > > My current assumption is that the two pluggins I will attack: > > > firefox/mozilla and I/E will give me access to Javascript to discuss > > > > with > > > > > mod_python. > > > > > > I know a _little_ about Javascript and it always has to do with writing > > > > and > > > > > reading HTML tags (I'm not even sure that's the correct term) > > > > > > Is there some common mechanism avaialbe ? > > > > > > Is one of the solution to put the data on the page (maybe hidden tags > > > > ?). > > > > > Still there is a need for some type of synchronization between both > > > > world. > > > > > I hope my questions make sense. > > > > > > Thanks and regards, > > > > > > Philippe > > > > -- > > ************************************* > > Philippe C. Martin > > SnakeCard, LLC > > www.snakecard.com <http://www.snakecard.com> > > +1 405 694 8098 > > ************************************* > > _______________________________________________ > > Mod_python mailing list > > Mod_python at modpython.org > > http://mailman.modpython.org/mailman/listinfo/mod_python -- ************************************* Philippe C. Martin SnakeCard, LLC www.snakecard.com +1 405 694 8098 *************************************
|