Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: [Muscle] CardEdge applet (MCardApplet) version to review
From: Tommaso Cucinotta (cucinottasssup.it)
Date: Sat Oct 01 2005 - 20:22:22 CDT
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.
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).
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)
>>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.
> 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).
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 ?
> 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 :-)
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 think this is already possible. You can read something with an
> 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.
> 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.
Tommaso Cucinotta, Computer Engineer PhD
Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 883 093, Fax +39 050 883 452
Muscle mailing list