Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: s.ferey (s.fereywanadoo.fr)
Date: Thu May 28 2009 - 19:08:24 CDT
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).
Muscle mailing list