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

[Joao Pedro]

Hi Sylvain,

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

>
> 1024 bytes allocated to transients data !
> [...]
> the JCRE (JavaCard Runtime Environment) of course needs RAM for its
> own purpose and applets will never see or use that RAM.
> for the amount of RAM not used by the runtime and thus available to
> the applets, the JCRE split it into (at least) 2 entities:
It makes sense, I understand it now.

> you very seldom need an input AND an output buffer of the same size
> at the same moment - none comes spontaneously to my mind.
>
> for all "stream" functions, so encrypt / decrypt, you must process
> data in place.
> let imagine a card w/o extended length support and an encrypt process
> with 3DES key, in block size shall be a multiple of 8, so 248 is the
> upper limit (assuming 'plain' data are transmitted, meaning there is
> no trans-encryption, eg decryption with GP keys, prior encryption
> with proprietary keys), you will simply implement:
>
> // a "Init Crypto context" was issued to initialise the cipher
> // it could be an ISO Manage Security Environment APDU or a CIPHER_INIT
> // I use CardEdge APDU hereafter:
>
> "length" is a short, "int8" is a byte, both defined as local variables
> of the process() method.
>
>
> switch (buffer[1]){
> case (byte) 0x36:
>    int8 = buffer[3]; // get operation
>    length = apdu.setIncomingAndReceive();
>    if (int8 == 1){
>    // initialize the cipher, not illustrated
>    }
>    else if (int8 == 2)
>       length = cipher.update(buffer,(short)5,length,buffer,(short)5);
>    else if (int8 == 3)
>       length = cipher.doFinal(buffer,(short)5,length,buffer,(short)5);
>    else
>       ISOException((short) 0x6A86);
>    apdu.setOutgoingAndSend((short) 5, length);
>    return;
>
> no more, no less, no don't need 2 buffers, you only need the existing
> APDU buffer.
>
I though of something similar, except I thought the only possible way  
was to use a transient buffer. So, one version of the code had only a  
transient buffer but, after reading the JC API, I had some doubts, for  
example, in the method doFinal() of the Cipher class:

"When using block-aligned data (multiple of block size), if the input  
buffer, inBuff and the output buffer, outBuff  are the same array,  
then the output data area must not partially overlap the input data  
area such that the input data is modified before it is used; if  
inBuff==outBuff and
inOffset < outOffset < inOffset+inLength, incorrect output may  
result." - OK no problem with this.

But on the next line:
"When non-block aligned data is presented as input data, no amount of  
input and output buffer data overlap is allowed; if inBuff==outBuff  
and outOffset < inOffset+inLength, incorrect output may result. "

One question is: wouldn't non-block aligned data make using (only) the  
APDU buffer problematic? Since it's not big enough and the data would  
overlap?
The other question is: Does one frequently use non-block aligned data?

> No, all code issued from the CardEdge package can access it, so the
> applet the ObjectManager and the MemoryManager, and BTW indeed these
> 3 parts may need to access data.
>
> the ACLs, as well as the keys or file-storage are allocated from
> the EEPROM and the applet firewall grants that only this applet
> (and utility classes if any) hace access to these blocks, there
> is no security concerns around that, a file (a CardEgde's object)
> should be a byte[] allocated with 14 + 'object size' bytes; a key
> could be a JavaCard instance storing a Key instance and the 4-byte
> ACLs.
Thanks for the clarification on this.

>
> the APDU buffer is your friend !
> some cards provide an APDU buffer of 500 bytes or more (635 for the
> Cosmo v.7). did you check it ?
>
> // assuming "buffer" is the result of apdu.getBuffer()
>
> switch (INS){
> case (byte) 0: // dummy get info
>    Util.setShort(buffer, (short) 5, (short) buffer.length);
>    apdu.setOutgoingAndSend((short) 5, (short) 2);
>    return;
>
>
I've tried this code and the size of the APDU buffer on the card  
appears to be 261 bytes long - enough for 2048 bit keys :)

>
> I start a review of the full code recently downloaded, there are a lot
Great!
> of things to clean up; my first try - since I'm using Eclipse - is to
> let it understand the #ifdef clause ! is there any way to do that ?
I have the same problem, but I didn't find any solution. If you find  
out anything please share.

>
> another issue is that some points should be broken because they are
> nosense (when data are returned they are prefixed by their length as
> a short ?! the protocol does provides that information (the length of
> returned data) as the very first data, why to duplicate it ??)
I have the same question and never understand why this choice was  
made. Maybe it was meant as an extra safety check...

>
> but is there a voluntary to implement a new middleware module?
>
As I said before, until I finish the semester I won't have much time  
available. But I'm willing to help out in any way I can.If you're  
interested, let me know.

Thank you Sylvain.

Best regards,
Joao