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...
Yes, entirely. It is incredibly silly to create a protocol on top of stream emulation on top of a protocol which is *ALREADY* structured and reliable. > >> 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 .. > I don't think a device that won't work in Windows, or will force > writing kernel level driver is something that is usable. You seem not to know the USB driver situation so well. I wouldn't pick USB without knowing that it's a good fit. Sorry, but this is just FUD. The kernel drivers exist since many years. Microsoft have even released their own variant, included since Vista and freely redistributable for XP. > Also using libusb is much more difficult than using a plain tty. Please try to attend my USB firmware development workshop at your earliest convenience. If you'd like to have a look at the files: http://stuge.se/lpc-p1343_buttons.tar.bz2 USB takes care of *all* the shit that needs to be dealt with by *both* application *and* firmware if using a stream interface. Serial ports were popular in the 80s, it's time to move on. And remember that USB is *NOT* a serial port with power. > I really see a lot of advantages of using the most primitive > channel for communication. You contradict yourself. Implementing a protocol on top of stream emulation on top of USB is two layers more than simply using USB directly. > 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. "forces local communications" makes no sense. If the device is connected via USB then it will be local regardless of which interface class it uses. Maybe you will argue that it should implement CDC Ethernet and expose a network protocol over USB, so that the device can be anywhere on the network. > >> 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 security is derived from the complexity of the implementation. > Adding libusb dependency (on both sides) libusb is not a dependency, it's just damn handy. And of course libusb or not is completely irrelevant for the device firmware. > and more complex code of handling the device allocation, makes the > probability of security issues higher. Sorry, what do you mean by device allocation? > > Or maybe you suggest exposing a PKCS#15 filesystem using MSC? > > I thought about exposing the device using standard interfaces. It's a bad idea because the standard interfaces do not fit the purpose of the device. It's *very* difficult for people to get their head around this - you're not the only one - but vendor specific is very very useful in USB. It's not a bad thing, it just takes a bit of detail knowledge about USB to see the benefits. > Yes, accessing the file system can be done using MSC. > Performing private key operations can be done using serial. Sigh. > However, I do not recommend of using MSC as it won't allow to proxy > the device into a remote location. Networking the device is a new requirement. It could make good sense to go there later, but I would like to start with something that fits easily into the existing p11 model. > > 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. I thought you meant encryption between applications and device? Do you mean user to user? > > I basically have PKCS#11 over USB in mind. > > PKCS#11 is API not a protocol... The API can be implemented over USB just as well as over DLL. There's really not a big difference. > In order to share the device and in order to perform device > authentication you need to define a protocol. How are devices shared and authenticated in existing p11s? > 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. Go for it! It's also an interesting idea. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
