On Apr 19, 2010, at 22:53 , Jim Rees wrote: > Peter Stuge wrote: > > Are APDUs the best communications protocol for PKI tokens? For some reason, computer systems are usually made up of layers. Eventually, you can't beat the layering but can either choose to re-use or create new ones.
Don't know if ECDSA-over-PCIx would be any success or if the real market (HSM vendors) would pick it up if somebody came and created it. Also old, but the OSI model is actually a practical and real-life layering, which one should not just avoid. > We spent some time thinking about this many years ago. 7816 is a very > baroque interface, better suited to the days of 300 baud modems than to > modern computing. It is pretty archaic indeed. > One recent attempt was the Schlumberger etoken, which eliminated the card > reader and put a usb interface on the card. I don't remember whether it was > CCID compliant but it certainly could be. > > My own modest contribution was to implement tcp/ip (and a web server) on a > card. Some of you may remember that. It was really just a demonstration, > as the card still used apdus. The original idea was for the card to instead > speak ppp over rs232 or other serial protocol. We never got that far for > lack of funding, but I had a plan that involved Atmel cards and some card os > work. Is that JavaCard 3 Connected Edition? Yes, you can run a handful of protocols over ethernet (and some data centers do that for internal communication) but eventually you'd be wishing to talk TCP/IPv4 to the outside world, not SCTP or not only IPv6. Same with APDU-s: not really anything bad that should be avoided like a plague. Just as there is no reason to talk your own special protocol across USB because "you think it suits better the crypto needs" if CCID exists. > As for making the card speak something closer to pkcs11, that's not a bad > idea, but a bit too special purpose for my taste. What about the biometric > data from cac/piv? What about symmetric-key systems like kerberos? What > about non-crypto apps like the phone book on your sim? Don't mix domain specific interfaces (cryptoki) with a hardware domain (smart card). The "pipe" to talk to the card should have nothing to do with GSM phonebooks. In fact, they map nicely into PKCS#11 as PIN protected data objects. > 11 years ago we > thought turning the card into a web server, and the services into web > services, seemed like a good idea. That might not be the right model, but I > think it's useful to think of the card as a service provider, not just a > secure store. That's what JavaCard3 should cover to some extent. But the host-card connection can still have an abundance of implementations and a "long" journey to come. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
