Hi Sylvain,
"s.ferey" <[email protected]> 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
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
