"s.ferey" <[email protected]> wrote:
Joao Pedro a écrit :
Check http://svn.debian.org/viewsvn/muscleplugins/trunk/.
"s.ferey" <[email protected]> wrote:
Ludovic Rousseau a écrit :
Patch applied in revision 287.
may I request WHERE that revision is available ??
Thank Joao.
I do NOT understand how card may survive to such code !...
(I mean no-flash EEPROM cards).
Your support of extended APDU that uses an EEPROM buffer
to store up to 512 bytes is unsafe (on standard cards
it will kill the EEPROM cells in short time (100000
writing) and will provide lower performance than using
short APDU managed in the sole RAM (the APDU buffer).
I would suggest to not use extended lengths this way.
This is a very good point.
I understand what you mean, and this was a major concern of mine. If
I'm mistaken please correct me but, after looking at the rest of the
code, this kind of "memory usage pattern" is used many times, at least
in the ComputeCrypt() method.
If you look at this excerpt, where a temporary buffer is allocated to
store the result of the cipher operation:
1190 : // Create object with 2 more bytes for DataChunk Size
field
1191 : short dst_base = om.createObject(OUT_OBJECT_CLA,
OUT_OBJECT_ID,
1192 : (short) (size + 2),
1193 : getCurrentACL(), (short) 0);
1194 : if (dst_base == MemoryManager.NULL_OFFSET)
1195 : ISOException.throwIt(SW_NO_MEMORY_LEFT);
(...)
1201 : else /* op == OP_FINAL */
1202 : ciph.doFinal(src_buff, (short) (src_base + 2),
1203 : size, mem.getBuffer(), (short) (dst_base + 2));
As you can see, every time a cipher operation occurs, the output of
the of the doFinal() method is stored on this memory (i.e. the
EEPROM), so the problem already existed even without the extended APDU
buffer...
586 : mem = new MemoryManager((short) mem_size);
Now in MemoryManager.src:
42 : public MemoryManager(short mem_size) {
43 : Init(mem_size);
44 : }
45 :
46 : private void Init(short mem_size) {
47 : if (ptr != null)
48 : return;
49 : // Allocate the memory
50 : ptr = new byte[mem_size];
51 : // Setup the free memory list
52 : // set the size
53 : Util.setShort(ptr, (short) 0, (short) mem_size);
54 : // set the pointer to EndOfList
55 : Util.setShort(ptr, (short) 2, (short) NULL_OFFSET);
56 : // set the pointer to the head node
57 : free_head = (short) 0;
58 : }
Regarding the extended APDU buffer, maybe declaring it as transient
would be a good alternative? This card, at least, has 8KB of RAM... I
guess all new cards, that support extended APDU, should have plenty of
RAM too... Your feedback here would be really great! :)
More generic question, is there a specification that
describes the requierments for the CardEdge applet ?
(reverse understanding is still possible but paintful).
I did not understand your question. Could you please clarify?
Thank,
Sylvain.
Thank you Sylvain, for taking your time and give feedback :)
Regards,
Joao
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
