I've finished my analysis of the javaCard implementation of the
muscle applet implementing CardEdge. Excellent, yet unfinished - in this embodiment. And
this is the surprising fact - the unfinished parts are the javacard crypto interfacing parts - the
easist parts on a Javacard. All the hard parts (access controls, state machine,
protocol work suited to the restricted ram and PDU buffer resouces, support for
ciphers, persistent keys and streaming state) are all done, and very well done. The host
API library, and the shell program are complete, the API looks generally reentrant and the shell
can bespawned for muli-processing with minor changes to context globals, there is
supprot for manufacturing and personalization time tools, and all code is well
synced with the javacard implementation of the wire protocol and the cardedge services.
Given the sophistication of the work, I cant believe that the crypto services were left
unfinished . Its almost as if the code actually released backed up
to a development verison, whose early port supported only RSA signing, ignoring and
somewhat hacking the support clearly coded and and already for more general cipher
support.
Anyways, what the state of the work? is my summary reasonably accurate, or far off?
Who is still motivated to work on this?
I certainly intend to finish off the secure messaging, so host and applet can communciate
over DES Macs, and of course, ensure the device can RSA verify a stored (signed) object
to support trust boostrapping.
Is there wider and general interest in this work, or should I just do it as a set of
proprietary changes, for my specific client's needs?
Check out the new MSN 9 Dial-up � fast & reliable Internet access with prime features! _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle
