I don't know what you had in mind with an "USB P11 token" but in case you would like to participate in an effort making sort of a USB P11 token there is already a project to dig in to:
http://webpki.org/auth-token-4-the-cloud.html If you take a deep peek in the extensive documentation you will note that it is not a P11 token; it is a token that will run P11 for "using" keys, but an entirely different system for "provisioning" keys. The reason for this division is that P11 represent a dead-end for provisioning since it doesn't support SM (Secure Messaging). If you look into the RI (Reference Implementation) of the token you will see that SM is piece of cake. Converting the Java code to ARM C/C++ shouldn't be much of an issue, it is only storage in NVM that requires a bit more thinking to not end-up with wear out problems. Just drop me a line if you are interested. I'm particularly interested in USB, P11, Mac, Electronics, and Browser competences. An unusual (unique?) aspect of the mentioned project is that it is designed to be integrated in browsers. Although maybe not exactly what you guys are looking for, the prime target for the project are people who are NOT interested in security or at least know very little about it! Since they represent 99% of all users it looks a bigger market :-) Anders On 2011-04-26 11:28, Alon Bar-Lev wrote: > On Tue, Apr 26, 2011 at 11:45 AM, NdK <ndk.cla...@gmail.com> wrote: >>> I was thinking microcontroller size, but if you're using a more >>> powerful USB device hardware that can run Linux then it could be >>> realized pretty quickly using softhsm. >> Since speed is quite critical, I was thinking to use something like G20 >> Fox Board ( http://acmesystems.com/ ). It's surely not cheap (anyway it >> can be WAY cheaper than other solutions), but it's tiny, fast (400MHz >> ARM9), can work as USB device (and host, maybe to keep a master key on a >> standard smart card used only once at boot time), can accomodate a >> (small) display and many keys, and there's a module with an FPGA if you >> want/need to implement some crypto acceleration in HW. >> There's even an Ethernet port (better not to use it... :) ). Too bad USB >> runs at most at 12Mbps, but that shouldn't be an issue. >> >> Didn't know softhsm... I'll have a look at it. > > There is no reference for this board in the link you sent. > > It would be a great solution if the device will be very small and run Linux! > It would be lovely to have PIN keypad and BIO reader on board as-well. > > However, I want to raise some issues. > Developing an implementation that directly accesses the USB device > impose fundamental security issue. As it requires the user to have > special privilege. It is true that on modern linux, udev can deal with > some device privilege settings, but it would be better to emulate some > standard interface, such as serial over USB. > > Serial over USB has the advantage to work on all modern operating > systems, including Windows (PKCS#11 only not mini CSP). While > implementing all logic within userspace. > > It will even be possible to access these devices in remote terminal > services of Windows. > > Serial over USB has also the potential to be a very secured implementation. > > Then you need to deal with device sharing. Stateless implementation > (connect, operate, disconnect) would solve this, while creating some > authentication cookie with the device. > > And need to deal with channel encryption.... secured messaging is not > this strong... > > And last, power management should be applied, so device will be able > to be powered down while inactive. This should be simple if stateless > mode is used and if authentication cookies are stored in non-volatile > memory. > > After solving the above, it is all about PKCS#11 API serialization. > Most of the PKCS#11 objects may be loaded into the host computer. Only > private key operations should be serialized and sent to device in > runtime. > > Proper definition of the communication interface of the device will > enable people to provide compatible hardware. Which would be great. > > Alon > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
