5 Replies Latest reply: May 6, 2013 8:23 AM by fgrieu RSS

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

    PavolAlcohol
      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
        • 1. Re: Multiple calls of sendBytes+cipher.update are "very slowly"
          fgrieu
          An observation: in the slow case, encryption can be concurrent with data transmission. Perhaps that concurrency triggers some communication fault, software or (especially for contactless) hardware: the encryption could cause Electro-Magnetic Disturbance sensed by the reader, requiring retries. Perhaps the crypto-processor is switched to lower speed during communication, and not turned up when communication is done. Perhaps, somewhat, concurrency causes communication to be split into much more physical frames.

          We need to know more to make an informed guess.

          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 ?
          How/at what point is the time measured ?
          Have you looked for retries ? Waiting time extension ?
          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 ? If possible: with a different reader brand ?
          Any hints on the hardware involved (as many of the first characters of IC type as possible, reader model) ?

          I would first observe what's actually going on using a basic digital scope, plus (for contactless) a field amplitude probe (coil/diode/RC) to see modulation by reader and card. A protocol analyzer (I use ProxiSPY) could help, but that would be my second choice.
          • 2. Re: Multiple calls of sendBytes+cipher.update are "very slowly"
            PavolAlcohol
            Hi fqrieu,

            thanks for answers. Here are my comments.
            An observation: in the slow case, encryption can be concurrent with data transmission
            Why are these two operations concurent? They should be synchronized or not?
            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 newie in JavaCard, so I don't know detail information about protocols I use in my case. What I know that T=1, I just call sendBytes methods to send data from the card. So, i don't know what do you think abou communication context/chain. How can I obtain such information? Is the chaining hidden behind the sendBytes method. I found something about 0x61 for remaining response data but I don't know either it's necessary or not.
            How/at what point is the time measured ?
            Times are measured between send APDU command and receive APDU response in my test application. They present duration of following routine:
            ResponseAPDU r = cc.transmit(new CommandAPDU(SELECT)); // cc is instance of CardChannel class
            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.
            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 ? If possible: with a different reader brand ?
            I dont't understand the term consistent timing. I don't dispose with another readers.
            Any hints on the hardware involved (as many of the first characters of IC type as possible, reader model) ?
            I don't know IC type of card? My reader is OmniKey 5321, last driver 1.2.9.2 for Win7.

            Edited by: PavolAlcohol on 6.5.2013 0:44
            • 3. Re: Multiple calls of sendBytes+cipher.update are "very slowly"
              fgrieu
              An observation: in the slow case, encryption can be concurrent with data transmission
              Why 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 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.
              Note chaining is a different thing; in ISO 14443-4 it describes how long APDUs are split into physical frames in card<->reader exchanges.
              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).
              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.
              • 4. Re: Multiple calls of sendBytes+cipher.update are "very slowly"
                PavolAlcohol
                An observation: in the slow case, encryption can be concurrent with data transmission
                Why 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
                • 5. Re: Multiple calls of sendBytes+cipher.update are "very slowly"
                  fgrieu
                  To investigate what goes on between card and reader, there are commercial tools.
                  I sometime use Proxispy.
                  http://www.keolabs.com/SC-ProxiSPY__product__smart-card-testing.html

                  But a digital oscilloscope and a simple field amplitude probe is very useful to get a global picture quickly, and see some kinds of problems. A field amplitude probe converts the average field amplitude to a voltage that the scope can display and (most importantly) sync on. One is easily made with a few turns of wire, a series rectifier, and RC. I use this with the LED replaced by 1kOhm + scope.
                  http://www.spirtech.com/spirtech/field-detector
                  http://www.spirtech.com/phocadownload/category/27-detecteur-de-champs-schema/16-detecteur