This discussion is archived
9 Replies Latest reply: Feb 13, 2013 3:41 AM by fgrieu RSS

0x45D - PC/SC SCardTransmit: unknown error code

966781 Newbie
Currently Being Moderated
Hi,

i have a weird problem with my card. First i thought it is maybe a timeout error, but the following Applet works fine:

package mk.test;
import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISOException;
import javacard.framework.JCSystem;
import javacard.security.MessageDigest;
import javacard.security.RandomData;

public class Main extends Applet {

    private MessageDigest hashAlgo;
    private RandomData rnd;
    private byte[] arr1;

    public Main(byte[] bArray, short bOffset, byte bLength) 
    {
        arr1 = JCSystem.makeTransientByteArray((short)32, JCSystem.CLEAR_ON_RESET);
        hashAlgo = MessageDigest.getInstance(MessageDigest.ALG_SHA_256, false);
        rnd = RandomData.getInstance(RandomData.ALG_SECURE_RANDOM);

        register(bArray, (short) (bOffset + 1), bArray[bOffset]);
    }

    public static void install(byte[] bArray, short bOffset, byte bLength) 
    {
        new Main(bArray, bOffset, bLength);
    }

    public void process(APDU apdu) throws ISOException 
    {
          
        if(selectingApplet())
            return;
          
        rnd.generateData(arr1, (short)0, (short)arr1.length);
     
        for(int i = 0; i < 100; i++)
        {
            for(int j = 0; j < 30000; j++)
            {
                    
            }
    }
}
If i call this it runs about 55 seconds an returns 9000. So my card seems to send the "waitExtension" automatically.
Now when i change the loop from the above example to:

for(int j = 0; j < 100; j++)
{
    hashAlgo.doFinal(arr1, (short)0, (short)arr1.length, arr1, (short)0);
}
it returns the error described in the thread title.
The applet is as simple as it could be, i dont know wheres the problem.

And a second question, where ist the MessageDigest object stored ? In RAM or EEPROM ?

Best regards
  • 1. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    Umer Journeyer
    Currently Being Moderated
    As you see you are using int in the for loops to iterate. Does your card supports in data type ? if not then please change it to short.

    everything except the local variables and the variables not declared as transient are stored in EEPROM and others to RAM.
  • 2. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    Umer Journeyer
    Currently Being Moderated
    I tried the code which you said troubling you and everything is fine on my side.
    package third;
    
    import javacard.framework.APDU;
    import javacard.framework.Applet;
    import javacard.framework.ISO7816;
    import javacard.framework.ISOException;
    import javacard.framework.JCSystem;
    import javacard.security.MessageDigest;
    import javacard.security.RandomData;
    
    public class ThirdApplet extends Applet {
        private MessageDigest hashAlgo;
        private RandomData rnd;
        private byte[] arr1;
     
        public ThirdApplet(byte[] bArray, short bOffset, byte bLength) 
        {
            arr1 = JCSystem.makeTransientByteArray((short)32, JCSystem.CLEAR_ON_RESET);
            hashAlgo = MessageDigest.getInstance(MessageDigest.ALG_SHA, false);
            rnd = RandomData.getInstance(RandomData.ALG_SECURE_RANDOM);
     
            register(bArray, (short) (bOffset + 1), bArray[bOffset]);
        }
     
        public static void install(byte[] bArray, short bOffset, byte bLength) 
        {
            new ThirdApplet(bArray, bOffset, bLength);
        }
     
        public void process(APDU apdu) throws ISOException 
        {
              
            if(selectingApplet())
                return;
              
            rnd.generateData(arr1, (short)0, (short)arr1.length);
         
            for(short j = 0; j < 100; j++)
            {
                hashAlgo.doFinal(arr1, (short)0, (short)arr1.length, arr1, (short)0);
            }
    
        }
    }
    output
    cm>  /select |third.app
     => 00 A4 04 00 09 74 68 69 72 64 2E 61 70 70 00       .....third.app.
     (249636 nsec)
     <= 90 00                                              ..
    Status: No Error
    cm>  /send 0000000000
     => 00 00 00 00 00                                     .....
     (14905 usec)
     <= 90 00                                              ..
    Status: No Error
  • 3. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    966781 Newbie
    Currently Being Moderated
    Hi Umer

    thanks for your answer.
    Yes my card does support int. If this works for you, maybe i have to contact my card vendor, i have absolut no idea why this doesnt work... :(
    In my real applet i have to calculate al lot of hashes (for key creation) and everytime the card crashes into this error...


    If the MessageDigest object stored in EEPROM so its internal buffers to calculate a hash are also in EEPROM ? This would also explain why the hash algorithm is so slow.
  • 4. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    966781 Newbie
    Currently Being Moderated
    Hi Umer,

    i saw you changed the hash algorithm to SHA. If i do the same, it works.

    So it seems to be a SHA_256 problem ?!
  • 5. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    Umer Journeyer
    Currently Being Moderated
    Oh yes sorry i forget to mention this change :)
    when i copy pasted your code, eclipse said to me that it is not a valid field so i changed it to the one i mention. Hope it works for you too now.
  • 6. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    966781 Newbie
    Currently Being Moderated
    Hi Umer,

    yah now it works for me with the SHA Hash-Algorithm. Thanks for your help !

    But im still confused why the card crashes into this error wenn i use the SHA_256 algorithm. My card supports this algorithm, only when i use it multiple times in a row it does not work. Maybe anyone has an idea
  • 7. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    fgrieu Newbie
    Currently Being Moderated
    I'm still confused why the card crashes into this error when i use the SHA_256 algorithm. My card supports this algorithm, only when i use it multiple times in a row it does not work. Maybe anyone has an idea?
    The problem is similar to the one in the thread "PC/SC SCardTransmit 0x45D error" (edit: that's the same person asking!)
    It could be a protocol timeout problem, in either the PC/SC reader or the card.
    See my answer to Re: PC/SC SCardTransmit 0x45D error
    It may help knowing the model/brand of PC/SC reader, version of the driver that it uses, and the card's ATR as reported by PC/SC; and if the card interface used is contact or contactless.
  • 8. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    966781 Newbie
    Currently Being Moderated
    Hi there,

    i found the problem.
    It seems to be a problem with the card and the T1 protocol. If i call a function in the applet which process a lot of SHA2 hashes, the card (or maybe the algorithm) suppresses the waitExtenstion from the card to the reader for any reason and then the error occur.

    If i use T1 protocol and SHA1 everything works fine.
    If i use T0 protocol and SHA2 also everything works fine.

    Only the combination of T1 protocol and SHA2 algorithm produces this timeout error. I sent this to my card vendor and hope he will/can help me.

    Best regards
  • 9. Re: 0x45D - PC/SC SCardTransmit: unknown error code
    fgrieu Newbie
    Currently Being Moderated
    I had not met this exact problem before, but a similar one, where using the T=1 protocol (but not T=0) a Java Card (capable of both at the discretion of the reader) would at some point, after some cryptographic computations, stop to send waiting time extension requests (but still otherwise work) until the next reset.

    Problem was worsened by several factors:
    - occurrence of that incident depended on parameters varying from sample to sample,
    - there was a different understanding between the manufacturer of a reading equipment, and card manufacturer, about if an R-block which N(R) encodes a non-acknowledgment, but which 4 lower bits encodes "Error-free" (according to ISO 7816-3:1997) or "Error-free acknowledgment" (according to ISO 7816-3:2006), is an acceptable non-acknowledgment.
    - after some number of failed retries due to the above, the reader attempted a resynchronization, but that left a broken sequence number in the secure messaging (which, if you look closely, is a design limitation of T=1 that nobody cares about); then all hells got loose in some bad way.

    In my experience, Murphy's law strikes often when there is need for a waiting time extension, and that was not tested carefully; that's true for ISO 7816-3 T=0, T=1, and ISO 14443-4.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points