[Muscle] Cyberflex e-gate 32k install error 6A80

[Joao Pedro]

Thanks for the suggestions Sylvain. I've created a small patch that  
tries to allocate the extended buffer on RAM, but fallbacks to EEPROM  
memory if something should fail.

The extended APDU buffer size is 268 bytes to accommodate for the  
entire received APDU. Ideally this could be only 256 bytes for a 2048  
bit key, but that implies more changes to the existing code and, at  
this time, I'm trying to make this code the least intrusive as possible.

I've compiled the applet, loaded it and can confirm that is working  
correctly with OpenSC on an Aladdin eToken 72K (engineering version).

According to (very non scientific tests), the running time of  
"pkcs11-tool --login --test" appears to be ~ 1.2 seconds faster using  
RAM vs EEPROM.

If you anyone can comment, I'll be grateful :)

Best regards,
Joao

"s.ferey" <s.ferey at wanadoo.fr> wrote:

> Joao Pedro a écrit :
>>
>> 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.
>
> my previous point ! there a lot of EEPROM uses in the applet that
> shall be avoided!
>
> based on a quick review, the ObjectManager & MemoryManager classes
> are a very bad idea, now there are may be some reasons to use them
> for instance to store some "session objects" that stay alive across
> several APDU, so my last question regarding a specification that
> explains how, why and when such 'semi-persistent' objects may exist
> (or not).
>
>> 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! :)
>
> it could be a solution, it depends on use of the transient memory
> by other applets, if one allocate a big transient reset buffer,
> that memory won't be available for other applets.
>
> it also depends on the actual need of memory, only some very specific
> cryptographic functions may require to have "huge" data all available
> at one time in a buffer, for instance if your card / applet supports
> 4096-bit signature in RAW mode, you need to store the 512-byte to be
> signed, but I don't know a lot of card that supports 4096-bit keys.
>
> the easier context to manage extended length functions is the checksum
> or digest functions, you need to input a lot of data but you will return
> a short amount of data. for instance for a digest process, you will use:
> (one can write the loop according different rules).
>
> short part = apdu.setIncomingAndReceive();
> short length = apdu.getIncomingLength();
> if (length == part)
>    length = digest.doFinal(buffer, apdu.getOffsetCdata(),
>          length, buffer, (short) 5);
> else {
>    digest.update(buffer, apdu.getOffsetCdata(), part);
>    length -= part;
>    for (;;){
>       part = apdu.receiveBytes((short) 5);
>       if (part == length){
>          length = digest.doFinal(
>             buffer, (short) 5, part, buffer, (short) 5);
>          break;
>       }
>       else {
>          digest.update(buffer, (short) 5, part);
>          length -= part;
>       }
>    }
> }
> apdu.setOutgoingAndSend((short) 5, length);
>
>
> regarding a "stream function" like encrypt or decrypt, you can not
> start to return the ciphertext while you will continue to receive
> the next plain text; something likes
>
> for (;;){
>   apdu.receiveBytes()
>   cipher.update();
>   apdu.sendBytes();
> }
> is of course invalid.
>
> so you have no choice and must limit the amount of transmitted data
> to fit the maximal length of APDU buffer or to use - as suggested -
> a transient buffer; both options would require a "get card/applet
> capabilities" function (a dedicated APDU) to let the terminal aware
> of how many bytes it can send per APDU (and thus it obvioulsy means
> a tailored middleware).
>
> as an exemple, the Cosmo v.7 card I was dealing with has a transient
> deselect buffer of 1536 bytes - and most of cards issued in 2007-2008
> certainly offer at least 1024 bytes, so at least, you can encrypt /
> decrypt by block of 1024 bytes (instead of 256) w/o any EEPROM writing.
>
>
>>> 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?
>
> well, as explained at the beginning some points are not that obvious
> and easy to understand when one just looks at the source code of the
> CardEdge applet; I beleive someone wrote a sort of specifications
> before coding it this way and these functionality and behaviors,
> the guys that had implemented by CardEgde middleware had certainly
> used that guide to know wich APDU are supported, what are their
> syntax, what kind of containers (tagged data object or binary files)
> can be created and used, and so on. I'm looking for such document.
>
> Sylvain.
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: muscle.ext_apdu_ram.diff
Type: text/x-patch
Size: 1487 bytes
Desc: not available
Url : http://lists.drizzle.com/pipermail/muscle/attachments/20090529/9a1ae97b/muscle.ext_apdu_ram.bin