[Muscle] Impossible to crypt using MuscleTool

[Sylvain Ferey]

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.