[Muscle] [PATCH] Do not use EEPROM (at all) with cards that support extended APDUs

[Joao Pedro]

Hello everyone,

this message is intended as a "request for ideas/opinions/comments" on  
how the CardEdge applet manages its memory.

Recently, Sylvain Ferey and Sébastien Lorquet pointed out in the list  
that using EEPROM for operations like signing and ciphering in the  
CardEdge applet (i.e. operations that currently write very frequently  
to the EEPROM memory) should really be avoided (Sébastien even  
suggested that it shouldn't be allowed).

One (of several) possible solution was mentioned: the RAM should, if  
available, be used for these kinds of operations, since writing to the  
EEPROM too frequently will/may shorten considerably the card's lifetime.

Sylvain Ferey pointed out that, on all newer cards, it should be safe  
to assume that they provide, at least, 1024 bytes of RAM memory.  
Sylvain also pointed out that, even if the card has sufficient RAM,  
one must be careful while using it, since it is possible that other  
applets (if present on the card) may already have allocated it for its  
own purposes...

With this in mind (and since I'm not rich, it would be nice that my  
card lasted a little bit more :P), I've written a small patch that  
avoids EEPROM memory usage altogether if the applet is compiled with  
the extended APDU option. The applet will need to have 526 bytes of  
RAM memory available (268 bytes for the incoming buffer, 258 bytes for  
the outgoing buffer) - this can be much more optimized, but I think it  
should be part of a bigger effort...)

The main advantages are:
- It's faster  - "pkcs11-tool --login --test" appears to be ~20% faster;
- It will not kill the card's memory.

The disvantages are:
- It's less secure (?) - the original memory allocation with  
ObjectManager creates ACLs on the allocated memory so only the creator  
of the object can access it. To try to mitigate this, I've added code  
to clear the buffer after it is used, but is this secure enough? What  
are the security implications?;
- RAM is needed... - shouldn't be a problem on cards that support  
extended APDUs. For example, my card has 8KB of RAM.

Again, this patch only affects the applet if the WITH_EXT_APDU option  
is enabled. If not, the old behavior is used. But, maybe, it could be  
a good idea to use a smaller buffer even without the WITH_EXT_APDU  
option? For example, a smaller buffer on the RAM, since the current  
behavior is not very nice on the card...

If anyone can comment on this it would be great.

Thanks everyone for the discussion on the last days. It's a privilege  
(and a pleasure) to learn about smart card development with people  
like you.

Best regards,
Joao
-------------- next part --------------
A non-text attachment was scrubbed...
Name: muscle.ext_apdu.noeeprom.diff
Type: text/x-patch
Size: 8026 bytes
Desc: not available
Url : http://lists.drizzle.com/pipermail/muscle/attachments/20090530/47bc8416/muscle.ext_apdu.noeeprom.bin