Tommaso Cucinotta wrote: > Karsten Ohme wrote: > >> that enough memory is left. The static initialization has another >> reason: To detect the capabilities of the card. When I use Garbage > > > Quite interesting, but you can only manage a few cases, I guess.
No. All. > And, AFAICR, trying to load an Applet on the Cyberflex 32k with > the compiled classes that used an unsupported key (e.g. dsa) > resulted in a load failure. Guess JC-2.2 has no issues like that > (or I can't remember / didn't test very well). The Cyberflex e-gate 32k does not support JC 2.2. It should never succeed in loading, if some JC 2.2 features are enabled. DSA I have never tested but its works with other cards. Except from this I have not the best experiences with CFlex e-gate 32k cards. You can try to enable 2048 bits keys for RSA and install the applet. Usually an CryptoException is thrown. All my CFlex cards do not do this. Instead a 6F00 error is thrown which is a real bug. Maybe for DSA the same applies. > Even if interesting, I think that just a little source configurator > that queries a card database based on card ATR is supposed to solve > the capability issue. Moreover, you would have on-board only the > code that can actually run on the card, with no space-waste due to > management code for unusable key types (this was the main reason > for the cpp preprocessing of the Java files) Yes, this would be a fine program. I have not examined in detail what algorithm is supported by what card. The file for a CFlex contains much more, that the card can actually do. Maybe an XML scheme for this and an XSL stylesheet can do this quite well and comfortable. > >>> 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. > > > Nope. Just was thinking to encrypt/decrypt data on the host. The card > sees and stores only encrypted data. OK. This is possible for objects. > >> Actually a PIN deletion would mean that also all objects owned by this >> ID must be deleted. > > > Absolutely a must-have feature with the current AC model. > >> 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? > > > It is exactly the current AC model (unless you modified the *and* policy > to become a *or* policy, it's open-source after all). OK, I have read it now in the Card Edge specification. I only took a look in the MuscleCard Framework documentation. > As one of the simplest extension to this behaviour, I was thinking of > an optional second ACL, to be placed who knows where, to be either > managed by separate commands (would retain maximum compatibility), or > embedded in the current createXXXX APDUs. So, it would become the > operation is available if either the main ACL is satisfied, or if the > secondary ACL is satisfied, or both of them. What'd'u think ? I didn't get the point. Well, I thought only the admin can delete a PIN / ID. And if he does this, all objects only owned by this ID are deleted. For all other objects the ACL is removed. >> 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. > > > There's a standard out there with SQL-like query of on-card data > arranged into relational-like tables. Just ask them :-) Uff. > And, yes, you could place a named (and even hierarchical) filesystem > in the TODO, if you really wanted, but, you know, there's ISO7816 > for /completicated/ stuff, if you really need it. I only come up with PKCS#15 to be useful for it. But probably this would mean also other changes. It's not on my task list to make MuscleCard also PKCS#15 capable. >> 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. > > The problem is when you search. In order to avoid searching the > entire object, you should build and manage smth like an index > into a (possibly) separate object. This can be interesting for future cards with more memory. If the object name is not meaningful enough. Should the search be also possible within objects, that means objects are table like structures with primary keys and indexes and ... At the moment these few kb of data can also be handled by a brute force search, I guess. >> 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 > > > I just compacted contiguous free mem, sorry. Defrag is a TODO. > > T. Karsten > -- > 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
