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 -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
