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
