On Tue, Apr 26, 2011 at 1:23 PM, Peter Stuge <pe...@stuge.se> wrote: > Alon Bar-Lev wrote: >> it would be better to emulate some standard interface, such as >> serial over USB. > > Absolutely not.
I would not dismiss this entirely... >> 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. > > The same is true for a vendor specific USB interface thanks to libusb. > Most importantly, the vendor specific interface allows to take full > advantage of the packet based nature of USB and built-in structured > communication. The protocol comes for free and does not need to be > implemented on top of a idiotic stream emulation on top of a packet > protocol. I don't think a device that won't work in Windows, or will force writing kernel level driver is something that is usable. Also using libusb is much more difficult than using a plain tty. I really see a lot of advantages of using the most primitive channel for communication. For example, the exact same protocol may be used over TCP/SSH socket. Or can be proxied to remote ssh session. While direct usage of libusb forces local communications. >> Serial over USB has also the potential to be a very secured >> implementation. > > That's BS. No device class is more or less secure than any other. The > only purpose of device classes are to bind a common driver to the > device. In this case there exists no fitting driver, so vendor > specific is the only correct choice. The security is derived from the complexity of the implementation. Adding libusb dependency (on both sides) and more complex code of handling the device allocation, makes the probability of security issues higher. > Or maybe you suggest exposing a PKCS#15 filesystem using MSC? I thought about exposing the device using standard interfaces. Yes, accessing the file system can be done using MSC. Performing private key operations can be done using serial. However, I do not recommend of using MSC as it won't allow to proxy the device into a remote location. >> And need to deal with channel encryption.... secured messaging is >> not this strong... > > Encrypt away. No problem. I did not find a decent solution for this, mind to share your view? How can two parties can communicate with each other while have nothing common? PGP/SSH like manual key exchange may be used, but it is too complex for most users. >> 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. > > I basically have PKCS#11 over USB in mind. There may need to be a few > tweaks, but not too many I think. PKCS#11 is API not a protocol... In order to share the device and in order to perform device authentication you need to define a protocol. What I have in mind is to pull all objects from the device into main computer and implement PKCS#11 locally, while delegating only private key operations to the device. This way you have much faster implementation, and a very simple protocol implementation. However, this protocol has little to do with PKCS#11... Alon. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
