David Corcoran wrote:
Hi Karsten,
When it was defined, there was no notion of garbage collection in the Java Card specificiations. As of JC 2.2, this is now possible, so an extension set of APDUs for deletion might be a good idea ...
Sort of a strange phenomenon ... after almost 4 years somebody cared about destroying resources (aligned with "think Java"). This was well known since the first day, and it's not just about the keys, it's also about the PIN codes. Thanks Karen for pointing out the issue.
I'm porting at the moment the Applet. So it can also support Key Deletion. But to support also cards with JC 2.1.1 I saw the only way to init all possible variations of keys (key length, algorithms, variations like RSA CRT) and did this also for all supported Cipher and Signature algorithms and KeyPairs. The keys are not store as keys. They stay as a key blob in the ObjectManager and if they are needed they are transferred to the preallocated key instance. If the card has not enough memory for this, key deletion can't be supported or only a subrange of the possible keys can be supported.
I have a Giesecke & Devrient [EMAIL PROTECTED] Expert 64 and this card should support the Java Card reclaiming memory technology. It supports JC 2.2
I do not know how the implementations for the keys looks like, but i assume the biggest amount of their size are the byte arrays for the key contents. I calculated that the size for preallocating each possible key should work (I have assumed maximum sizes):
RSA keys:
Public keys: 512 + 768 + 1024 + 2048 Bit = 524 Byte Private Keys: 512 + 768 + 1024 + 2048 Bit = 524 Byte Private CRT keys: 512 + 768 + 1024 + 2048 Bit = 524 Byte
DSA Public Keys:
q=160 Bit, p=512, 768, 1024 bit, alpha(g)=512, 768, 1024 Bit, y=512, 768, 1024 Bit = 696 Byte
DSA Private Keys:
q=160 Bit, p=512, 768, 1024 bit, alpha(g)=512, 768, 1024 Bit, a(x)=160 Bit = 696 Byte
DES: 8 Byte 3DES2KEY: 16 Byte 3DES3KEY: 24 Byte
All together: = 3012 Byte
The Signature, Ciphers and KeyPairs should not take so much memory.
I have to try out if this works also with cards with only 32k memory.
Dave, what about an update to the CardEdge definition ?
With this implementation, a method DeleteKey must be added the specification. The only needed parameter is the key_nb.
By the way I have added a method GetCapabilies() to retrieve all support algorithms, key length, ... ciphers, signatures, pin char sets, ... from the applet.
I hope it will work how I figured it out.
Bye the way I have added an ISOVerify method, an CHV UNBLOCK PIN (after GSM11.11) and an CHV CHANGE PIN (also after GSM 11.11) to support readers with keypad). This changes are transparent and no change to the specification is necessary.
Some thrown exceptions will change, e.g. instead of SW_INVALID_PARAMETER SW_OBJECT_NOT_FOUND (or how they are called.)
In some time I hope I can release this Applet with an updated muscletool, MCardPlugin and musclecard library.
Bye, Karsten
Object memory is the only thing that has been made to be reclaimable, thanks to the MemoryManager class. Is it still useful in JC-2.2 cards ? Anyone knows how many cards out there have on-board garbage collection ?
Tommaso.
Thanks, Dave
On Tue, 29 Mar 2005, Karsten Ohme wrote:
Hello,
What's the reason that the CardEdge Definition does not define a function for deleting a key?
Bye, Karsten _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
