Install:Install/MakeSelectable on Cyberflex Access 32K e-gate

Question

Hi at the JavaCard forum,
I used to load applets with my OCF loader to Cyberflex Access Developer 32K cards. Now, that these cards aren't sold anymore, I want to upgrade my loader to handle regular Access cards with CodeShield enabled. I managed it to build, transform and load those special CAPs successfully. BUT, the following Install:Install or Install:Install/MakeSelectable command keeps failing with 6A 80.
I do not use any DAP for loading, everything is in clear.
Install:Load
->80 E6 02 00 10 05 A0 00 00 00 01 00 00 06 EF 04 C6 02 28 F9 00
<-90 00
Load
->80 E8 00 00 FF C4 82 28 F9 01 00 0F DE CA FF ED ...
<-90 00
Install:Install/MakeSelectable
->80 E6 0C 00 1C 05 A0 00 00 00 01 06 A0 00 00 00 01 01 00 01 02 0A EF 08 C8 02 48 00 C9 02 00 00 00
<-6A 80
Is there anything suspicious in this command? It works with the Developer card, but that has not much to say in respect to the regular Access cards, I guess.
I also tried to include the load file's application ID again as instance AID but same result: 6A 80
Does somebody know, what's wrong here?
Thanks in advance
Martin

Answer 1

Hi Jo,
It strips out the cap component
header information and changes some of the data. The
CodeShield cards then read that data then discard it....
I did a diff on a transformed load file and found the Method and RefLocation components are also altered, which is reflected by changes in Applet, Class and Directory components, but that's just a guess. Header, Import and StaticField aren't changed at all. Somehow, the optional Descriptor component is also appended by makeIJC, maybe CodeShield needs it, but yes, this data is supposed to be discarded afterwards.
The .JAR file is the original Sun generated .CAP file
so you may use OTHER vendors cards.
One has just to skip the transform step to load other OP cards, basically.
CodeShield isn't friendly because it forces you to use
the Axalto kit in order to use their cards. Get the
kit or switch to more user friendly cards that don't
have on-card byte-code verifiers. JCOP family
cards,G&D, and Datakey.Yeah, you sound like me in http://lists.musclecard.com/pipermail/muscle/2003-May/000825.html. I somehow grew up with the Cyberflex cards and the early CITI tools. I just reanimated old Cyberflex 16K to support PKCS#15 aka OpenSC, my favourite PKCS#15 framework. And Schlumberger/Axalto isn't that bad, they are pioneers of JavaCard technology, sell also in small quantities and have public docs available. That's a fairly 'open' approach compared to their competitors. I still think its the only card where you just buy 5 cards and do all the rest by yourself.
>
Axalto does provide CodeShield disabled cards to its
strategic business partners. For a time they sold the so called Cyberflex Access Developer 32K card to the public, but it's somehow no more available. That was the reason for updating my loader to support the regular Access cards.
>
I don't believe in the on-card byte code verifier
because I believe all I have to do is a WinDiff on the
jar and the cap, and copy those differences to any cap
file to get it to load without running it thru the
makeIJC. I don't have the time to attempt it. I'd much
rather use more interoperable cards then waste my time
hacking Axalto to work. There are rumours, that C will soon fade away, like RSA 1024 (hehe), because it enforces you to write security holes in every second line of code. One asset of the Java language is its byte-code verification mechanism to detect malicious code that might compromise the VM in any way, and that's an asset for Axalto too. It was fairly easy to get the captransformer from Trusted Logic; since it's just another Jar, one could even incorporate it into the loader. But I am not a lawyer, and prefer to keep my code separate ;)
Actually with the help of a compassionate guy, who sent me a log output of the $DK, I could drill my install problem down to a simple Cyberflex Programmer's documentation ambiguity on p. 99:
The 'Load Parameters Data Block' for the Install:Install/MakeSelectable command is documented as
0A EF 08 C8 02 48 00 C9 02 00 00
______^^
which imposes on me that 08 is the length of the whole Cx tag buffer, BUT it's not, it's only the size of the C8 tag, bummer. With a size of 04 it works, and it does also if you revert the tags like:
0A C9 02 00 00 EF 04 C8 02 48 00
The error description for 6A 80 was completely misleading too...
I'll update the loader accordingly and it will be available in a few days at
http://home.vr-web.de/~martin.buechler/smartcard/CFlexAccess32Loader.zip
Just in case it happens, that a Cyberflex cards hits you :)
BTW, another thing. Didn't you mention in another post to this forum the need for an OS PKCS#15-CardEdge applet project? Something new about it? I'd like to have something like that; the MUSCLE applet might serve as crypto library and one could write against Chaskiel Grundmann's JCOP driver for OpenSC.
Cheers