Just wanted to note that exposing such device to IP stack makes it a target to hack, packaging is much more difficult.
Also, that in crypto caching is not a problem as 99.999999% of time the content of the crypto device is constant. About using USB directly, well, I disagree... I see this much like GPS device, with a simple optional multiplexer for applications (local and remote). We discussed PKCS#11 forwarding some time ago [1] and some time before. Implementation of hardware independent stream protocol will allow using crypto in many scenarios (serial, USB, unix sockets, tcp, ssh) with the PKCS#11 forwarding features built-in. Just a though... but any implementation will do. [1] http://www.mail-archive.com/opensc-devel@lists.opensc-project.org/msg01733.html On Tue, Apr 26, 2011 at 3:44 PM, NdK <ndk.cla...@gmail.com> wrote: > Il 26/04/2011 11:28, Alon Bar-Lev ha scritto: > >>> 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. >> There is no reference for this board in the link you sent. > Ops! Sorry: http://acmesystems.it ! Translated first level domain too :( > >> 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. > There are a lot of IO lines available. Just don't count too much on > serial (UART) interfaces: known to have some speed problems (should be > fixed soon, BTW). > >> 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. > Possible, but I'm sure we can come to something better :) Encapsulating > too many protocols one inside the other always gives troubles. > > [...] >> Then you need to deal with device sharing. Stateless implementation >> (connect, operate, disconnect) would solve this, while creating some >> authentication cookie with the device. > I'm usually not for stateless implementations for stateful devices. To > avoid DoS attacks, state can be kept (for a reasonable time) by client, > in encrypted form. > >> And need to deal with channel encryption.... secured messaging is not >> this strong... > Since it's a completely new device with its own protocol, it's even > possible to do something like: > - get device's cert (or public key) together with an encrypted nonce > - send it your cert (or public key) and another nonce > - get first nonce's decryption key, encrypted under your public key and > signed by device > - setup session key as an hash of the two nonces > - use this session key for the rest of the session > > But maybe it's "a bit" overkill: USB is "enough" point-to point (much > more than standard card interface, that could be "received" from a > certain distance by its interferences...). > >> 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. > That's one of the last problems... It consumes so little (and aims a > target where power saving is not really a priority) that you can simply > use internal powersaving. Even if it gets detached, it's like if you > detach a smart card while in use. > >> 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. > Well, since you can have up to *16GB* memory (SDHC) on that device, > storing objects is not a real problem :) > > BYtE, > Diego. > _______________________________________________ > 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
