Re: [Muscle] muscle applet deletion of keys, change of parms

Sun, 11 Jan 2004 10:24:11 -0800

Thanks for the comments: Ill assume the original design team is no longer

active, and I can set some new goals. I see no reason why the target should

not keep RSA raw as a block cipher, to support the legacy apps. We can also design

changes mandated by a common criteria evaluator, reflected in javacard 2.2 specification,

in this area.

 

(1) Ill assume that the old SUNFED group published their protection profile for JavaCards around

the time you programmed muscle, and have updated it for javacard 2.2 RMI (solves

the end-end T0 integrity problem) and Object Deletion functional group (addressing

KeyPair deletion, and parameter reconfiguration, indirectly).

(2) I assume that most of the CC evaluation work focussed on the wider card

management system view of the smartcard - rather than the crypto services, per se, that

must support online applications such as SSL which switch cipher suites on demand.

 

(3) Ill assume modern die for ICCs support USB, have flash for post-issuance applets

and heap, and have MMU that support JavaCard Os's least privilege model.

 

(4) Ill assume the ICC is mounted in the 7816-1 package, managed, personalised and

issued in that form by a card management system; is used operationally mostly

in a PCMCIA reader (whose own reader is present in most command and control

workstations) and a PKI manages the lifecycle of the combined unit (trusted PC card +

7816-1 ICC)

 

(5) Finally, my big assumption, is that the trusted ICC is rekeyed regularly, over the

air (or net) by a PKI, and rekey means in practice deleting and reissuing post-issuance applets

and their alloced' persistent heap objects, recovering resources. I do not assume JavaCard

garbage collection, or evaluation of the JavaCard OS's own object delete TOE SEF.

 

All that said, this set of supposed rationales motivates two programming changes, and

one JavaCard OS manufacturing  change:

(a) a new access right, to control execution of the rekey/delete behaviour

(b) conclusion of strong identity login, an authentication assurance necessary for asserting

an authorization seeking the rights in (a)

(c) the OS in ROM will contain root keys in a non-deletable package. The package can

allow post-isstance applet to register root keys to the secure storage (TCPA style), for

limited purposes.

>From: Tommaso Cucinotta <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [Muscle] muscle applet deletion of keys, change of parms
>Date: Sun, 11 Jan 2004 12:21:48 +0100
>
>Peter Williams wrote:
> > [...]
>>I noticed in passing that one cannot change a signature object,
>>once
>>[...]
>>Keypairs, this situation seems unsatisfactory/./
> > Can anyone remember why this key initialization behavour was
> > programmed.
> > I can change
>
>I agree with you. The DeleteKey command was not embedded in the
>first
>protocol release because the JVM was not able to free the key object
>memory anycase. But the protocol is open, and the implementation
>too,
>so, if you added that command, and you're happy with one (or more)
>garbage key objects within your card (up to memory exhaustion), I
>agree
>it is someway useful to others, too. Furthermore, I don't know if
>there
>are JavaCards out there that perform garbage collection, at the
>moment.
>On those cards, your DeleteKey (or overwrite with different params)
>command would just work fine.
>Also, consider a card lifecycle: usually it is formatted once, and a
>change of the on-board key(s) is not so frequent (still justifying
>why
>the DeleteKey command APDU was missing in the first place). Of
>course,
>developers may need to do that more frequently...
>
>>it so I free and realloc a persisitent KeyPair, once a change in
>
>Of course, this is the right way. As already pointed out, on the
>cards
>we were working with (almost three years ago), the old key object
>would
>have remained allocated as garbage, and never reclaimed....
>
>(And, AFAICR, there were similar troubles with other
>JavaCard objects related to the actual signing algorithm).
>
>As a final note, I would suggest leaving the ImportKey and
>GenerateKey
>behaviour untouched (e.g. they only allow to overwrite a key with
>same
>parameters), and instead add a DeleteKey command APDU.
>
>So, just publish a URL to your changes.
>
>Bye,
> T.
>
>_______________________________________________
>Muscle mailing list
>[EMAIL PROTECTED]
>http://lists.musclecard.com/mailman/listinfo/muscle

Let the new MSN Premium Internet Software make the most of your high-speed experience. _______________________________________________ Muscle mailing list [EMAIL PROTECTED] http://lists.musclecard.com/mailman/listinfo/muscle

Reply via email to