On Thu, May 28, 2009 at 11:32:39PM +0200, s.ferey wrote:
> Jakob Bohm a écrit :
> >>
> >>if the "-nvCodeLimit" parameter is supposed to build the
> >>load parameter field it is quite strange that it chooses
> >>to change 8500d to 8512d.
> >
> >In GlobalPlatform.c, get_load_data() adds the size of the padding
> >for DES CBC MAC (1..8 bytes 80 00... to make size multiple of 8)
> >and the size of the CBC MAC itself (8 more bytes).  The size
> >calculation is not commented, so I am guessing at the purpose... .
> 
> if you're right, it doesn't make sense! the MACs (one per LOAD APDU)
> are not stored by the JCRE as part of the CAP file, and that parameter
> defines the size of requested EEPROM used to store that CAP file
> (some - most of - components of that CAP file).

Ok, so maybe some GP cards want the extra space needed the MAC or
its calculation to be included in the EEPROM space allocation.

> 
> >But how do I determine if a card (any card) is supporting 2.1.0,
> >2.1.1 or 2.1.2, the JCSystem.getVersion() call only return the two
> >first parts of the version.
> 
> for "any" card it isn't possible, since GP and JVC does not define
> a mean to do so (both are welling to ... for a while, but...).
> some cards propose a proprietary GET DATA tag to list all available
> runtime packages.
> 

Bad move VISA/Sun...

> >Is CosmopolIC a 2.1.x card?
> 
> CosmopolIC is a familly brand name, so yes 'old' cosmo (v.3 & 4)
> were 2.1.x card, current ones cosmo v.7 (80 or 128k) are 2.2.2
> 
And the one you tested my CAP file on is which of those?

> >Does CosmopolIC have the on-card byte code verifier?
> 
> no; a very few number of cards include an on-card verifier,
> I would say it is definitively useless, my opinion ...

IF the on-card verifier actually prevents the execution of
dangerous non-standard byte code it actually closes a big
potential security hole in the JC architecture:  SOMETHING needs
to ensure that no applet can escape its sandbox.

> 
> >Well Cyberflex 32K is the easiest card to buy
> 
> you're definitively right, it is something I never understood,
> all other card suppliers seem to refuse to sell their cards.
> 
> >the highly certified Oberthur card has a dead US website
> 
> oberthurusa.com is closed, oberthur.com provides very generic
> info, oberthurcs.com / Identity Product Line / Corporate
> gives a "page under construction", they don't want to sell,
> or I'm missing something ?!
> 

My observation too...

> >Besides, Cyberflex e-gate 32K has been supported card #1 for the
> >CardEdge applet for years, so just dropping support when something
> >fails would be very bad for users who (like me) have already spent
> >money based on past recommendations.
> 
> (for commercial availabillity more than technical reasons).
> I agree with your point, my point was simply that I can't help
> you on for a Cyberflex specific issue (I don't know this card
> very well) so I just confirmed that your CAP file is OK.
> 

Well at least when used on a functionally different card, which is
why I ask about the detailed card differences to get a clue to the
cause.


-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to