Peter Williams wrote on 3/8/2004, 6:55 PM: > lets be clear: to sign a SSL client authentication message ,we must > 1. use NSS API, which maps onto > 2. the JCA API, which calls a > 3. PKCS11 API card abstraction, which loads a PKCS11 provider, which calls the MSC > API... > 4. which translates C calls into CardEdge APDUs, which calls > 5. MSC IFD API and its slot management abstraction , which calls > 6. the PCSC API for slot/resource and mutex/thread management > 7. which loads an IFD driver for the lun and operates the T0/T1 TPDU2APDU state > machine, which > 8. wraps the TPDU in either TLP224 or Gemplus T1-like host->reader block transfer > protocol, which > 9. interfaces to the USB service access point for a pre-enumated CCID NSAP > 10. which on the reader must pass across a transport bridge, via a > host<->controller<->UART A-layer dispatch loop, which adds events to a queue > signalling > 11. a T0/T1 protocol state machine handling T1 block or T0 async timeouts on a 7816 > UART, which > 11.5 pass across either a French or German encoding of bit levels and bit ordering, > which > 12. traverses an inverse path up the ICC stack > 13. through the javacard OS io drivers (elide several layers) > 14. to the applet/APDU dispatch interface...to > 15. finally, a method in the CardEdge class (written in Java), which > 16. calls the JCA, whose provider invoke a software RSA library - written in C > probably - > 17, which makes trusted kernel call to access the 16bit exponentiator co-processor. > > And this is only the Unix path. On Windows, add smartcard API drivers and CAPI > providers...and the interaction between these two > > Ever wonder why smartcards dont take off, apart from being a $30 cost per head??
One can put together equally long event sequences for the connection between a web browser and a web server or the connection between two modern cell phones. Web browsing and cell phones are both much more widely used than smartcards. The length of the code path doesn't matter to the users as long as it doesn't result in unacceptable performance. Using NSS directly (without the JNI and JCA overhead of JSS) with the MuscleCard applet on Windows, we measured an SSL client auth performance of approx. 2.0 ops/second. If we modify the applet to doublecheck the signature (for extra security), we still get approx. 1.35 ops/second. I suspect that even at 1.0 SSL client auth handshake/second the performance is acceptable for most applications. Wan-Teh _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
