Karsten Ohme wrote:
The applet does now support all cipher and signature algorithms of Java
Card 2.2, that means RSA, DES, AES, DSA, EC.
A good set of updates to the MuscleCard protocol and related components,
sounds great. Just a
few questions for you.
Did you test any of the new features ? On what cards ? Can you put into
the archive a document about
that (if it's not already there, of course -- didn't open it yet) ?
Garbage Collection is supported for keys, signatures and ciphers, but at
installation time this unfortunately consumes more memory than the
static allocation of all necessary objects and it is not possible to
enable all features. Hopefully this can be programmed more efficiently.
hmmm... this makes me curious. Can you detail the problem, please ?
Read this and give your comments:
http://www.inf.tu-dresden.de/~ko189283/MuscleCard/MCardAppletChanges.html
I will, I promise.
The applet is there:
http://www.inf.tu-dresden.de/~ko189283/MuscleCard/
Did you also modify JMuscleCard for compliance with the new features ?
What is not done:
1.) Card data encryption
A supplied other key from the outer world would introduce the problem,
that this key must be available together with the PIN. This can limit
the mobility.
I guess you don't want that key on the card, do you ? So, if one or more
external hosts have
the key(s) to encrypt/decrypt an object, why don't just leave that task
at the application
level (how it is now) ? Or maybe you're supposing that an on-card
JavaCard key is stored more
securely than an on-card JavaCard byte array (where the objects reside).
3.) Renaming of objects
Key, objects, ... could be renamed. E.g. If a key has number 5 is in the
way and should be renamed to number 7. Useful?
Cool ! If you cannot delete them, just rename them ! (if card has no GC ...)
It would break applications using that key, wouldn't it ? (unless you're
using some on-card directory...)
If you have control on what keys the app is looking for, then you don't
probably need to rename at all.
What about security risks ? When can the host rename ? need a new ACW ?
Just use the
"overwrite key" ACW ?
4.) Change of ACLs of objects and keys
Access Control would complicate: who can change ACLs ? You would need an
ACWs for
ACL management permissions. Can you propose application scenarios where
it would help ?
Finally, just add this to the TODO list:
-) optimize management (retrieval) of on-card objects: anyone ever tried
to create some
hundreds of objects ? how much slow does it become ?
-) support for searchable properties (name/value pairs), proposed
sometime ago from someone
on this list (would avoid the transfer of large objects on the host
when a single information
is needed from inside them) -- needed ? -- what are the transfer
speeds of up-to-date cards ?
I could place everything into a new CVS repository @ sssup.it, if you need.
Bye,
T.
--
Tommaso Cucinotta, Computer Engineer PhD
Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 883 093, Fax +39 050 883 452
http://feanor.sssup.it/~tommaso
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
