Hello, Now this is a really neat idea.
For actual implementation there are people even on this list that have done it before and probably could help: https://www.privacyfoundation.de/wiki/GPFCryptoStick For what it's worth, I'd suggest to call it USB-HSM (as "normal" HSM-s would usually be PCI-HSM or NET-HSM-s) I don't think that TCP/IP would do any good in this picture, better use PKCS#11. Somewhat it is similar to what GnuPG tries/tried to do - take control of the CCID interface itself, but sadly GnuPG did not provide a PKCS#11 interface, just claimed the interface... About pushing PDFs: I think that this could be reasonable to have a small LCD display these days on the USB device? That could be used to display a partial hash of the input data, so that it could be matched on screen and on the stick. On Apr 21, 2010, at 09:34 , Peter Stuge wrote: > Andreas Jellinghaus wrote: >>> >>> Implementing a new USB device and driver is actually pretty easy. >> >> device? driver? is that necessary? host, device or both? > > Both. Neccessary if it means an easier-to-use token and software > stack. (Where the previous stack is reduced to just one driver.) > > >> it would be nice to create a stream socket over usb somehow, >> best with simple user space ioctls (i.e. directly using the >> interface) or libusb as alternative. > > There's a lot more to USB than ioctl()s to make it really portable, > but libusb takes care of it and could be statically linked into a > PKCS#11 provider. > > Fundamentally USB communcation is either message based or stream > based. In general for hardware which supports a particular API I > think that message based seems to make the most sense. > > >>> One way to do SSL over USB would be to make the device into a USB >>> network device, and just implement SSL on the device. Not great fun. >> >> nah, you already need to address >> * selecting readers (and listing what is there) >> * select slots (and list what is there) >> * slot status >> * cards in range (for CL) >> * select card (for CL) >> * identification (replacement for ATR) >> >> not sure how to map that to networking. I think it would be too >> complex. > > Except TCP/IP is very well understood, while smart card protocols > aren't. But I'm also not arguing for the network device so much. > I think it makes more sense to have a simple protocol over USB that > is closer to the actual API. > > >>> Instead of a plug and play device driver, setup might then require >>> network configuration by the user, and probably a browser plugin. >> >> it is easier to access a usb device I think than to ask for a network >> change. remember all the network details like firewalls, routing, >> routing software, IPSEC, VPN and other tunnels etc. >> soo many components you would need to test to make sure you don't >> interfere with them. > > Yes, no USB firewalls yet. > > >>> What on the PC side would be authenticated by the device? >> >> well if each machine and each card has a certificate and key pair >> for direct authentication and they can establish a secured line >> (tls/ssl), that would be a good base. > > Again, what part of the PC system would be authenticated by the token? > > Basically; what purpose does the authentication serve for the token? > > Or for the PC, for that matter? > > >> talk whatever protocol you want over that, for example to request >> some signature from other keys (one that needs the user to enter >> the pin e.g.), push pdf's for signing or whatever. > > Is there a point in pushing a PDF if it can't be verified by the user > on the token? > > > //Peter > _______________________________________________ > opensc-devel mailing list > [email protected] > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
