3 Replies Latest reply on Jul 18, 2012 10:32 PM by NickNack

    What limits are there in code running in an SIO


      I wonder if one of you good folks out there can tell me if there are any limits on what code can be executed (or memory accessed) by a Server side Shareable Interface Object (SIO) method?

      I have a server applet that implements an SIO that has a single method - IncNumber(). It simply increments a single byte field that's one of many fields in a non-volatile memory array. BUT, before the number can be incremented IncNumber() has to check a DES seal that protects the whole array. If the DES seal is OK then the field may be incremented and a new DES seal is created for the whole array. The server applet has an APDU that calls IncNumber and I can issue these APDUs to my heart's content and see the number incrementing always protected by correctly formed Seals. So when running in the server applet it all works great.

      The problem comes when I create a Client applet that tries to call the SIO.IncNumber() method because it always returns a 6F00 error. I've ascertained that the problem comes when the Server applet executes the following command (when trying to check the DES certificate):

      cipherDES.init(keyTest[0], Cipher.MODE_ENCRYPT);

      cipherDES is declared in non-volatile memory and is initialised in the Server's constructor. keyTest is an array of possible keys (also residing in non-volatile memory) but at the moment only [0] is ever used. The server has to go through an initialisation phase which initialises keyTest[0] so I'm pretty certain that all objects exist. Remember that I can issue an APDU to the server applet that runs this self same code without problem.

      My understanding of how the SIO system works is that when the client calls the SIO method the client gets kicked out of memory to be replaced by the server as if the server had been selected itself so I don't see why it's failing on this line of code. Is that understanding correct?

      So my QUESTION is this. Is it known that this will not work? If so, can you please explain why and give me ideas on how I might get around it (if possible). If you think that it should work can you give me ideas why it isn't (or things I could try to find out). Could it be a limitation on the card I'm using (as far as I can tell, the card I'm running this on is an NXP JCop 2.4.1 card running Javacard 2.2.2 and Global Platform 2.1.1)?

      Any ideas would be gratefully welcomed.
        • 1. Re: What limits are there in code running in an SIO
          I don't have an idea on why things are blowing up, but you can wrap the Cipher.init line with a try-catch block. According to the documentation, this should be throwing a CryptoException of one of two types. You can read the exception code and then re-throw as an ISOException so you can get a code other than 0x6f00.


          try {} catch (CryptoException ex) { ISOException.throwIt((short)(ex.getReason() | 0x7000)); }

          Which should give you either 0x7001 or 0x7002. If you're still getting a 0x6f00 after that its going to be something like array initialization or null pointers.
          1 person found this helpful
          • 2. Re: What limits are there in code running in an SIO

            The problem is with how the Cipher object was created. You need to set externalAccess to true in the call to getInstance(). The javadoc says:
            externalAccess true indicates that the instance will be shared among multiple applet instances and that the Cipher instance will also be accessed (via a Shareable interface) when the owner of the Cipher instance is not the currently selected applet. If true the implementation must not allocate CLEAR_ON_DESELECT transient space for internal data.
            Also, when the SIO is called, the caller is not removed from memory, there is a context switch internally in the JCRE. The SIO server may not necessarily be currently selected. This is covered in a little more detail in the JCRE specs.

            • 3. Re: What limits are there in code running in an SIO
              Doh! Thanks Shane, I created that object so long ago I'd never have remembered there was a second parameter to the call. Back when I created it I didn't really understand the idea of SIOs but I figured keeping the object private was the most sensible thing to do - if only I'd realised then that it would come back to bite me.

              Many thanks again


              PS for anyone following this thread, I was writing the Seal out to a bunch of bytes in RAM (created using makeTransientByteArray() with CLEAR_ON_DESELECT). As Shane's post quotes, these bytes needed to change to be CLEAR_ON_RESET otherwise the 6F00 error was still occurring.