I wouldn't hold my breath on this one. External tokens on mobile phones is a difficult idea that most likely will be marginalized by on-line schemes using embedded crypto hardware.
If there was this "One Provider" things could be OK, but it is really the opposite, and it is also getting worse. Unlike the external tokens that haven't a reasonable enrollment system in spite of being on the market for decades, the embedded solutions will be enrollable through the mobile browser. You just have to forget NSS and PKCS #11 because they don't support on-line enrollment of the kind that can be used by "mere mortals", and at a security level banks could accept. Actually, the makers of traditional tokens need to take action because embedded tokens extended with NFC and swift browser enrollment, may go *way* outside of their normal "habitat". We can talk about it on FOSDEM :-) C U! Anders Martin Paljak wrote: > Hello, > > On Jan 26, 2011, at 10:09 AM, Ludovic Rousseau wrote: >> I just found the page "SmartCardPKI" [1] on the seek-for-android >> project. The goal is to build OpenSC for Android. They provide a patch >> [2] but I do not remember reading any discussion about it on the >> OpenSC mailing lists. Maybe they do not want to integrate their >> changes upstream. > > Interesting. I briefly followed seek-for-android last spring after getting an > android phone. But couldn't get far as I understood there are no readily > available and reasonable bluetooth smart card readers [1] that could be > securely integrated with a smartphone platform in semi-universal way (what is > my primary interest) without a *lot* of work. I never saw this patch though, > although I briefly read the SmartCardPKI page. It looked like a port to > YetAnotherSpecialLinuxDistro that can run on commodity hardware and make use > of the overall Linux bits and pieces. > > I believe meanwhile with the rise of tablets, which have real USB sockets (I > guess), Android integration can become interesting again. Especially > integration with Android system API-s (if available, smilar to Tokend or CSP) > and also removing the CPU hogs from OpenSC to make it usable on battery > powered devices. > > I have not heard from that project on the list either, looking at the patch > it seems more like a "make it compile for us" than a "we have a patch for > improvements in upstream". > > But their patch show possible deficiencies with OpenSC: >> So far the changes I have seen are: >> - use dlopen() instead of lt_dlopen() > Which is reasonable, as libltdl is an annoying dependency not always > available (on Android or Windows) which requires additional steps to be built > for non-Linux platforms or, patching as demonstrated. There was once, a long > time ago, another "mini-library" in OpenSC called scdl that dealt with > dynamic loading. It was removed in favor of libltdl. I would see as an > optimal solution the use of an internal mini-api (sc_dlopen, sc_dlsym) that > would use libltdl if available, but fall back to simple dlopen/LoadLibrary > implementation otherwise (Which, IIRC, was my suggestion also back then). For > Windows integration that would be preferable, as it would remove the need to > compile libltdl. > >> - direct linking with libpcsclite.so > A reasonable choice again. Defaulting to direct linking if possible should be > preferred for dlopen-ing, or at at least be made configurable. Tracking the > subtle changes in pcsc-lite is a lot of work that can cause mismatches. It > would also allow to build OpenSC binary runtime package without any dynamic > loading capabilities for the simple cases (no pkcs11-tool and no driver > loading, only static drivers). > >> - use of getpassword() instead of getpass() > Quick googling did not reveal the differences? I assume it brings up a > graphical password dialog on the device? > >> - disable RSA_generate_key() in sc_pkcs11_gen_keypair_soft() > Has been removed in 0.12.0, together with other plaintext key operations. > > Do you have pointers to devices (with USB, integrated smart card and reader > or similar) or projects (PKCS#11 capable or similar) where the integration > would actually be useful and usable as of now? > > [1] http://www.opensc-project.org/opensc/wiki/CardReaders#Bluetoothreaders _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
