From: Karsten Ohme (widerstandt-online.de)
Date: Sat Apr 02 2005 - 04:17:21 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Tommaso Cucinotta wrote:
> 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 SmrtCafe 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
>>> Musclelists.musclecard.com
>>> http://lists.drizzle.com/mailman/listinfo/muscle
>>>
>>
>>
>> _______________________________________________
>> Muscle mailing list
>> Musclelists.musclecard.com
>> http://lists.drizzle.com/mailman/listinfo/muscle
>
>
> _______________________________________________
> Muscle mailing list
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]