Tommaso Cucinotta wrote: > 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) ?
The Elliptic curve features were tested with a JCOP 41 v2.2 card. The AES and DSA algorithms I have tested with a Giesecke & Devrient SmartCafe Expert 64, the RSA stuff, with the G&D and CFlex e-gate 32k. For the elliptic curve I'm just testing. I had not possibility to test elliptic curves over prime fields. I have no card supporting this. At the moment I try to verify the elliptic curve signatures with JMuscleCard (also nearly completely new.). But standard Java does not support elliptic curves until version 1.5, and there are no appropriate functions (?!) to decode the X9.62 returned format of elliptic curve points. I guess I must use BouncyCastle because of this. >> 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 ? I cannot track it down. The static version tries to allocate at the installation time all signature, cipher and key object for use. So for every combination one object is there. Key are filled in from the object manager from their key blob representation. This works well with 64k cards. For 32k cards you must restrict the algorithms to a minimum, so that enough memory is left. The static initialization has another reason: To detect the capabilities of the card. When I use Garbage Collection I use only one Signature, one Cipher, one Key and one KeyPair object. This is allocated with new for every possible object. So the Garbage Collector maybe has problem to keep track of the lost references and the allocation fails after a certain number of allocations. At least this is true for the Giesecke & Devrient. I have also the possibility to try it out with a JCOP 41 and an Oberthur 64. You can download it an try to detect an error. If there is an error. > >> 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 ? Yes. The version of the site is not up to date. (It does not contain the new cipher, signature, ... definitions for Java Card 2.2). Except for this it should work. The new version will be there this night or in some days. > >> 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 ? No, because this key in plain text would reveal the same problem. If it can be read, everything can be read. For a PIN maybe the same is true. > 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) ? That means that the application must give the key to the card, before the card can operate. Because also keys on the card are stored in the ObjectManager they must be decrypted before they are useful. > 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). I don't know if key are stored more securely than byte arrays. > >> 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...) Usually an application should not rely on a certain key number. If two applications rely on the same key number both together cannot be used. Because I think this problem exists, I thought of this functionality. The code is already contained in the card manager for doing this. The problem is, that this cannot be done with the current API of MuscleCard. OK, I have also done this for the MSCKeyPolicy and MSCTokenInit structures and some definitions. Maybe this change is valuable for a 2.0.1 release. > 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 ? Well, the object name / key number must be free. If the logged in authentity is OK, it can be renamed. The ACL stays the same. Everybody how can write can also rename. Is their a security risk? A security risk related with this is the possibility to delete PINs. The admin can do this. The question is now, if the admin like the other IDs is only a special role for one person or if the semantic of an ID can also mean a different person. Because a admin can delete a PIN (that means an ID), he could do this, create a new PIN (a known PIN now) and use all stuff of the former id, i.e. forge signature, decrypt and so on. Actually a PIN deletion would mean that also all objects owned by this ID must be deleted. This can be trivial, but what is if an object is associated with different IDs? Means the association of multiple IDs to an object that this object can only be used/read/written if all of this identities are logged in? So also these IDs will have no access any more to the deleted object or key. > >> 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 ? Well, it's the same like in every file system. The user how can write to an object, can also change the ACL. But if the admin can do this, he could again reach unallowed access rights. But for an admin this cpuild be useful, if another user wants access to something which another former user owned ... But I don't know how to eliminate the securioty problems. > > Finally, just add this to the TODO list: OK, I will add this. > -) optimize management (retrieval) of on-card objects: anyone ever tried > to create some > hundreds of objects ? how much slow does it become ? Can be slow. See below. I have created over twenty key pairs on a card. Then a memory limit of 10 kb is reached. > -) support for searchable properties (name/value pairs), proposed > sometime ago from someone Nice feature but every feature consumes memory space. What exactly is meant with this? To search for an object with an certain name? This could probably be done with only little extra amount of code. > 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 think this is already possible. You can read something with an offset and so not read the whole bulk object. I suppose that reading and writing is still very slow. But reading and wrting objects is not the problem, there are only 64 kb on modern cards. A test to sign with ECDSA sme hundred kbs lasted some dozen minutes ... Another problem which can be much more dramatic after a while. The memory manager is not able to reallocate memory to defragment to memory. Actually the should be compacted sometime. If there is much traffic it can be imagined that actually enough memory would be there, would no memory block large enough is available. What is need is a fast memory algorithm for this. > I could place everything into a new CVS repository @ sssup.it, if you need. Thanks. At the moment I have my own private SVN and CVS location. I would appreciate a location. But is this an official MuscleCard CVS? I would be interested if someday there is a common single version for the CardEdge applet. Karsten > 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 _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
