The GemPlus site is stunningly absent any technical data.
On the Sun site, the "64 PK" is a JavaCard compliant with JC 2.1.1 & OP2.0.1' with large 64K EEPROM memory, well suited for identity schemes. The product is certified CCEAL5+ and FIPS140-1 level2.
on the CVMP site, there are disclosures for a particular firmware version (GXP3-FIPS EI19)
http://csrc.nist.gov/cryptval/140-1/140sp/140sp431.pdf
Is your card a "Pro R3 E64" and is it one of the validated firmware versions? Is it still OP2.0.1 or the updated GP 2.x.y?
Or it is "something else"? its hard to track down issues with cards of unknown definition. From the ATR, you can be pushy with the salesperson, and demand specifics.
One interesting security assurance point, however, is that for the muscle applet (a post-issuance applet) to be a FIPS-140-2 complying crypto module, the underlying card has to be FIPS 140-2 level _three_ evaluated (which it is, as is the Gemplus/ActiveCard variety)
Ive no idea what an EAL5+ level is. Perhaps its EAL5, with vendor representations about better assurance for some of the components. This is a common marketing gimmick.
Ok. its almost impossible to help you from the public data! I still have not determine what the underlying security controller is, and who makes the JCE. One can guess its may be of a bluez origin, given the older support for OP. Given the quality of bluez software, one might suspect the underlying controller, and/or the porting of bluez drivers to that chip.
--------
If noting similarity situations and fixes helps:
I had a similarish situation re EEPROM and the JCE on a UK card, based on a Atmel 6464C. The company eventually fixed their JCE firmware making a valuable GP card, finally. (But, then, they left their simulators RSA PKCS#1 padding broken - presumably to generate support revenue) In that case, one could only allocate large buffers in flash/EEPROM during the install method: I moved the object manager and memory manager instantiations back into the install method - removing them from the setup method, for that solution. In Summary: allocating the nK memory during the setup method failed: allocating it during install succeeded. In later firmwares with "bugs fixed", one could do both.
----- Original Message ----- From: "Bruce Barnett" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 13, 2004 7:00 AM
Subject: JCOP USB Token (was Re: [Muscle] Cheap Muscle?)
I'm following up on an earlier query I made.
I have verified that the GemPlus GemPCKey USB Reader + GemXpresso Pro 64K Plug Format Smart Card
when combined make a USB token that can be used with the Muscle framework.
The USB token acts as a CCID-compliant smart card reader + JCOP card.
I tried to allocate 7K, but this failed. Allocating 4K worked.
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.drizzle.com/mailman/listinfo/muscle
