Multiple calls of sendBytes+cipher.update are "very slowly"

Question

Hi all,
My applet encrypts own data and returns them within the APDU response. For encryption Im using the AES 128bit CBC without padding. Because my data stored in EEPROM are too large I encrypt them in parts to APDU buffer and then send these parts by sendBytes method.
I found very interesting thing:
I call multiple cipher.update followed by sendBytes method in the loop until all data are encrypted and sent. My response is very very late.
Here are single cases and time duration for them. Please dont think about these unused cases.
They was written to simulate my problem and for time measurement.
byte[] data = new byte[4096];//created in applet constructor
*1.test case*
cipher.update(data, (short) 0, (short) 1440, apdu.getBuffer(), (short) 0);
apdu.sendBytes((short) 0, (short) 1440);
cipher.update(data, (short) 1440, (short) 1440, apdu.getBuffer(), (short) 0);
apdu.sendBytes((short) 0, (short) 1440);
cipher.update(data, (short) 2880, (short) 1200, apdu.getBuffer(), (short) 0);
apdu.sendBytes((short) 0, (short) 1200);
cipher.update(data, (short) 4080, (short) 16, apdu.getBuffer(), (short) 0);
apdu.sendBytes((short) 0, (short) 16);
Time duration: 5.126s
*2.test case*
cipher.update(data, (short) 0, (short) 1440, apdu.getBuffer(), (short) 0);          
cipher.update(data, (short) 1440, (short) 1440, apdu.getBuffer(), (short) 0);
cipher.update(data, (short) 2880, (short) 1200, apdu.getBuffer(), (short) 0);          
cipher.update(data, (short) 4080, (short) 16, apdu.getBuffer(), (short) 0);
apdu.sendBytes((short) 0, (short) 1440);
apdu.sendBytes((short) 0, (short) 1440);
apdu.sendBytes((short) 0, (short) 1200);
apdu.sendBytes((short) 0, (short) 16);
Time duration: 1.278s
*3.test case (just encryption)*
cipher.update(data, (short) 0, (short) 1440, apdu.getBuffer(), (short) 0);          
cipher.update(data, (short) 1440, (short) 1440, apdu.getBuffer(), (short) 0);
cipher.update(data, (short) 2880, (short) 1200, apdu.getBuffer(), (short) 0);          
cipher.update(data, (short) 4080, (short) 16, apdu.getBuffer(), (short) 0);
Time duration: 1.132s
*4.test case (just send dummy data from APDU buffer)*
apdu.sendBytes((short) 0, (short) 1440);
apdu.sendBytes((short) 0, (short) 1440);
apdu.sendBytes((short) 0, (short) 1200);
apdu.sendBytes((short) 0, (short) 16);
Time duration: 0.224s
Can somebody explain me what could rapidly reduce a speed of operation in case 1? Any ideas?
thanks

Answer 1

An observation: in the slow case, encryption can be concurrent with data transmissionWhy are these two operations concurrent? They should be synchronized or not?In the first example, but not the second, it could conceivably be that the second <tt>cipher.update</tt> is concurrent with the first <tt>apdu.sendBytes</tt> (that is: occurs simultaneously; <tt>apdu.sendBytes</tt> schedules a transfers that could occur later, while <tt>cipher.update</tt> runs). Never seen this, but that could be, especially if there is some intelligent device (e.g. NFC mobile phone) in-between the card and reader.What I know, the JCOP version I'm using doesn't support multithreading.
What is the communication context/chain ? ISO 7816-3, T=0 or 1, f=, F/D= ? Straight ISO 14443-4, type = A or B, parameters like ATQB and ATTRIB, or analog for type A ? SWP + what ?Sorry, I'm newbie in JavaCard, so I don't know detail information about protocols I use in my case. (..)
What I know is that T=1, (..)
My reader is OmniKey 5321, last driver 1.2.9.2 for Win7. That reader is both contact and contactless. Which one is in use ?
If you use contacts, the protocol could be ISO 7816-3, T=1. If you use contactless, the protocol is most likely ISO 14443-4, even though T=1 appears in the (simulated) ATR that you obtain from the (PCSC interface of) the reader.
By "chain" I mean the various things linked between your code and the card. E.g. assuming the card is a straight contactless card (not a mobile phone) and you use Oracle's Java (1.)6 or later, most likely: card <-> OmniKey 5321 <-> it's driver <-> PCSC aka winscard <-> JVM <-> javax.smartcardio. Complications occurs with mobile phones.I use contactless mode. For connection I'm using either SSComm tool from NXP or javax.smartcardio, so your chain above is good.
Have you looked for retries ? Waiting time extension ?Maybe you mean APDU.waitExtension(). Am i right? I've tried to call this after sendBytes but without success.I was asking if you investigated if there are communication retries by the reader, and waiting time extension requests sent by the card to the reader, which are some of the likely causes of the slowdown (the answer is clearly: you so far used no tool allowing you to check that).No, I didn't check if some retries exist. Does exist some tool for such purpose?
If not, at least: is the timing in the slow case consistent from one experiment to the other ? When card/device is moved at a different position from the reader, if applicable ?I dont't understand the term consistent timing.Consistent = repeatable from one experiment to another, including moving the card at a slightly different position/height from the reader (assumed contactless). If the timing was very variable, that would suggest random errors and a retry mechanism.The time are very similar also for different height from the reader. Differences are cca +-10%.
thanks