Hi! Jean-Michel Pouré - GOOZE wrote: > > It's my old idea of implementing PKCS#11 directly over USB. Issues > > have been pointed out, and they would have to be solved of course. > > Feitian offers two ranges of products: CCID (ePass2003 and other > products) and HID over USB (ePass2001 and other products).
Don't get me started on HID. :) The libusb FAQ http://libusb.org/wiki/FAQ#CanIcreateadriverlessdeviceusingHIDclass tries to give an overview of the considerations for using HID. Executive summary is that it's a bad idea if you want to run on anything but Windows, and even there it may not be a very good idea because you have to re-implement some features which USB otherwise offers your protocol design for free. > At Gooze, we have HID over USB products in stock (around 100 unused > tokens) but we did not released them as they were incompatible with > OpenSC. > > Under Windows, it seems that HID over USB range of products can be > used without drivers, just over USB. Do you know how it is used by CryptoAPI and/or PKCS#11 applications? > Under Linux, a small proprietary USB framework is needed. Proprietary? You know that I think that's the wrong approach. :) The FAQ page mentions HIDAPI which can be used to communicate with HID class devices in some cases, but if portability is a concern, it should be clear from the FAQ page that using HID is not the best choice anyway. > If this is what you mean, Sorry, no, it's not. What I have in mind is to implement the actual PKCS#11 API directly over USB, as far as that is possible. Again, issues have been pointed out with doing this, but I still think it's worth a shot. > IMHO, CCID is superior as it is really plug-and-play under all > systems. So much software is running which is completely unneccessary. I agree that CCID has sufficient usability, but it is by far not the best that can be done. > Pure plug-and-play never exists, It does, actually. At least in Windows and Linux pure plug-and-play would be possible with my USB P11 idea, but I believe also in other systems. As always with PKCS#11 it would be neccessary to point applications to the correct PKCS#11-provider file (.dll or .so) but still I find the idea worth exploring. > What we need is: > * Cheap hardware available worldwide, with onlines sales. Yes, and the logistics of this can be tricky, but as you know with some volume it can indeed be done. And if the solution is good enough I think the volume will come. > * A common framework under all systems, this is OpenSC. I'd be much happier without any framework at all actually. > * Compatibility with all systems, including Linux, Mac, Windows and > Android. Yes, the portability is important. iOS would also be nice, but well that may be pushing one's luck. :p > From my point of view, I would be more in favor of an Android phone > acting as a CCID device overs some secure wireless link over OpenSC. As you probably know, anything wireless is a quite significant attack vector. No "secure" transactions there please. But with a cable maybe. However, Android devices so far do not have a strong history of local IO either coming in or going out. :\ This can change along with market demands of course, but it raises the barrier for development. > GOOZE will soon release crypto chips for Android What kind of chips? How do they connect? > The only reason why Apple removed smartcard support is that (in my > opinion) it may be working secretly on a new iPhone replacing > smartcards and offering secure payment. Yes, I think this is a common belief, and I don't think it's wrong. > The target for new OpenSC developments should be smart phones. Much of OpenSC doesn't really apply in smartphones, but I agree that smartphones may be very relevant security devices. //Peter
pgpLnKnaGHQ64.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
