Hi Peter,
At 21:20 22/03/2008 -0700, Peter Williams wrote:
I did alot of work on the applet, a couple of years ago, profiling its
cypto, object and pin model for a custom embedded application.
We have to recognise that it has little commercial future, compared to
more advanced applet architectures for ICCs/javacards - that US got pumps
money into
well, it can be a long story.
for one part of the story, the future of a card based service is up to its
users.
commercial or governmental card initiatives often use their own card
specification, something for good reasons, something for the pleasure of
issuing yet another specification.
for sure muscle-applet will hardly address some governmental projects but
corporate or "free" initiatives - like trustbearer - can use applets like
muscle card-edge, in their scope actually used crypto-provider (smartcard,
token, ...) is not that relevant.
What is does represent is possibly the ONLY mainstream, open technology
smartcards internals, that the average person can get their hands on. Its
a great learning tool.
yes, agree. smartcard providers don't offer a lot of valuable samples.
One has to recognize, as we did in our project, that javacard architecture
is not the ony approach. We ended up build a custom card (a spinoff of a
PIV card) in C, without the intepreter, that also bunded GlobalPlatform.
It was just a better "Engineering" approach.
I did wrote some PIV implementation in JavaCard, it wasn't meaningless neither.
If you are going to build a hihgly custom javacard, you might aswell
just build a custom card. At least you have direct control of your COS
and the hardware resources, then. I know we needed that, to talk to the
ICC's co-processor in a way that javacards COS prevented one from
accomplishing.
if you are developing a single card-application, yes, do it in C it will be
faster & cheaper.
for a card manufacturer, the expected ROI of a JavaCard platform justifies
to provide application / services with JVC applets; this can also allow a
safer implementation of the crypto. services: the VM & crypto. developers
make no assumption regarding how the JVC API will be used and thus shall
enforce all security rules; OOH when the same guys develop crypto. base
services as well as high level driven-based APDU, some leaks of expertises
can be present (I do not say it's always the case).
Sylvain.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
