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
