Jakob Bohm a écrit :
And the one you tested my CAP file on is which of those?
well, it works on v.7, v.5.5, I just perform a try on v.5.2 and I got a '6700' on the last APDU !?!! I have a tool to verify CAP structure and your is fine (I rebuilt it from text APDU & remove the last extra '00' inserted as Le in the last APDU of course). Did yo check it with an off-card verifier - in case it may give a warning/advice ? I don't perfectly remember if that 5.2 had (also) some specific loading behaviours (it's a 2.2 card) but my conversion tools had an option to prevent insertion of the descriptor component into the CAP file - of course I would prefer a 6A80 when the directory component is loaded (likely first or 2nd APDU) if it was the reason but since I haven't other idea you may try to generate your CAP without that component (I start but renounce to edit the directory component and rebuild all lengths manually - so can't do the test from my side).
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
yes but no. the on-card verifier prevents the loading (rather than execution) of dangerous code. this mean it can detect invalid byte-code (that will simply throw a CardRuntimeExecution at runtime), but it does not mean that it can detect illegal JavaCard uses built with nice 100% compliant byte codes.
SOMETHING needs to ensure that no applet can escape its sandbox.
the applet firewall (that isolates each code coming from a package to codes from other packages) does that. (the "on-card sandbox" is defined by a package and the only way to exchange data across packages is by a Shareable interface). Sylvain. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
