This discussion is archived
13 Replies Latest reply: Jul 23, 2012 10:24 AM by safarmer RSS

Smartcardio Compute digital signature with 2048b Key

816731 Newbie
Currently Being Moderated
Hello,

This is a Smartcardio problem, not a Java Card one, but there is no specific forum for Smartcardio, if there is a more appropriate place please move this thread there...

I perform digital signatures using Java and Smartcardio without problems. Although, I have done it so far with 1024 bit keys. Now I have a card with a 2048 bits (256 bytes) RSA key in it. I didn't change a line in the code because the personalization steps of the card are the same (taking out the key sizes) and I got the following error when I perform the PSO_COMPUTE_DIGITAL_SIGNATURE:

sun.security.smartcardio.PCSCException: Unknown error 0x8010002f

Although, this error reported as "Unknown" is in fact 'SCARD_E_COMM_DATA_LOST' (defined in Winscard.h).

This is not that surprising, because the card needs to output a total of 258 bytes as answer (Signature + SW) and the APDU buffer is maxed at 256 bytes, so, Smartcardio needs to split the answer.

But instead it gives the 'SCARD_E_COMM_DATA_LOST' error. Does any one know how to go around this? This is not a bad answer from the card, it's an error in the communication channel...

Also, this did something to the card, after a couple of tries I can no longer used the card. Any command I send to it (including select the intended Applet) now returns the SW 6D00

Thank you for any help
Cad
  • 1. Re: Smartcardio Compute digital signature with 2048b Key
    893199 Explorer
    Currently Being Moderated
    This depends more on the smart card than javax.smartcardio. The client side can only do what the card side is set up to expect.

    Find out if your card supports ExtendedLength APDUs. If so, have your applet implement the ExtendedLength interface and use 65535 as your expected return length when you call for a signature.

    Otherwise, create a RAM buffer (JCSystem.makeTransientByteArray()) long enough to hold your signature. Use that for the signature destination, and write your program to break the process into a signing process and then multiple retrievals of parts of the signature buffer.

    WRT to what's going on with your card - try deleting and re-installing the applet if you can talk to the card manager. Otherwise you've probably bricked the card. My guess is that the card read your attempt to write past the end of the APDU buffer multiple times as an attack.
  • 2. Re: Smartcardio Compute digital signature with 2048b Key
    safarmer Expert
    Currently Being Moderated
    Hi,

    Did you only get this error once and then the card was unresponsive? The 6D00 may mean that a security violation has been detected by the JCRE/Card OS and has locked the card.

    As for the APDU buffer, that is for your data. The SW is appended by the card OS/JCRE when the process method completes. It will add 0x9000 if the method succeeded, the value of any ISOException that was thrown, or 0x6f00 if an unhandled exception occurred. 256 bytes is the limit for a standard length APDU.

    Shane
  • 3. Re: Smartcardio Compute digital signature with 2048b Key
    893199 Explorer
    Currently Being Moderated
    Except that various cards allow more space for the APDU field - especially if the card supports Extended Length APDUs. For example, a JCOP J3A has an APDU buffer of 1462 bytes.

    And AIRC the actual APDU buffer length is usually 256 + 5 or 261 to allow for the maximum length APDU (4 bytes of header, 1 byte of payload length, 255 bytes of payload and 1 byte of expected return length)

    In any event, an RSA 2048 bit signature is 256 bytes in length (without ASN1 encoding). Without support for extended length APDU's he's going to have to do multiple calls to retrieve the signature in segments.

    He's going to need to place the signature somewhere other than the APDU buffer - either NVRAM or transient space - since the APDU buffer would be cleared at the beginning of a second call to retrieve data.
  • 4. Re: Smartcardio Compute digital signature with 2048b Key
    safarmer Expert
    Currently Being Moderated
    Except that various cards allow more space for the APDU field - especially if the card supports Extended Length APDUs. For example, a JCOP J3A has an APDU buffer of 1462 bytes.
    The applet needs to be modified to implement the ExtendedLength interface to be able to handle extended length APDU's. It also requires a JC 2.2.2 card and support is optional.
    And AIRC the actual APDU buffer length is usually 256 + 5 or 261 to allow for the maximum length APDU (4 bytes of header, 1 byte of payload length, 255 bytes of payload and 1 byte of expected return length)
    That is correct. The buffer can generally fit the maximum command APDU but this is not required. The buffer may be as small as 133 bytes. The question was about responses and the maximum standard length response APDU is 256 bytes (exluding SW).
    In any event, an RSA 2048 bit signature is 256 bytes in length (without ASN1 encoding). Without support for extended length APDU's he's going to have to do multiple calls to retrieve the signature in segments.
    The signature istest does not have ASN.1 encoding. Something like a PKCS7 message would have encoding, as would an X.509 certificate. If there is more data than 256 bytes to return, response chaining is well defined in ISO7816-4.
    He's going to need to place the signature somewhere other than the APDU buffer - either NVRAM or transient space - since the APDU buffer would be cleared at the beginning of a second call to retrieve data.
    That will not be a problem in this case.

    Shane
  • 5. Re: Smartcardio Compute digital signature with 2048b Key
    816731 Newbie
    Currently Being Moderated
    Otherwise, create a RAM buffer (JCSystem.makeTransientByteArray()) long enough to hold your signature. Use that for the signature destination, and write your program to break the process into a signing process and then multiple retrievals of parts of the signature buffer.
    I think I may have mislead you a bit in my first post. I do not own the applet nor I can make any type of change in it although, what I meant is that I know about it's life cicle and personalization methods. The Applet owned by an external provider, the same one that also sells the cards.

    I thought the problem was in the communication channel, but by what I understand now, the problem is purely on the Applets of the card. Being so, and since I have no control over the Applet, all I have left is to present the issue to the provider right?
    Did you only get this error once and then the card was unresponsive? The 6D00 may mean that a security violation has been detected by the JCRE/Card OS and has locked the card.
    No, between different tests and showing off to other ppl the behavior of the cards and code when the keys were 1024 bits or 2048 bits, I must have tried like, I guess it must have a counter similar to the PIN counter, although I had no idea at the time...
    The applet needs to be modified to implement the ExtendedLength interface to be able to handle extended length APDU's. It also requires a JC 2.2.2 card and support is optional.
    I tried to found out the Java Card version of the card, I even found this thread {thread:id=1749759} but I couldn't get the JCOP Tools anywhere in order to run the command 'get-data 0066'
  • 6. Re: Smartcardio Compute digital signature with 2048b Key
    893199 Explorer
    Currently Being Moderated
    Ah ha. Then you may not be able to do anything. I assume RSA keys of length 1538 work?

    With respect to GET DATA and the JCOP tools - I'd recommend grabbing either or both of Global Platform for Java (GPJ) and GPShell. In addition, if you're talking to the card with javax.smartcardio, its pretty easy to create a GET DATA APDU and send it. Don't forget to first select the card manager AID.

    It is possible that if the card is a JCOP card, that GET DATA will have been locked out unless you open a secure channel. This is pretty rare.

    And lastly - if its a JCOP card, chances are the type of card is embedded in the ATR historical bytes (or go to http://smartcard-atr.appspot.com and type in the ATR).
  • 7. Re: Smartcardio Compute digital signature with 2048b Key
    816731 Newbie
    Currently Being Moderated
    I assume RSA keys of length 1538 work?
    I'll propose that option to the vendor in order to see what happens
    its pretty easy to create a GET DATA APDU and send it. Don't forget to first select the card manager AID
    I did that, I just can't interpret the ASN.1 in order to identify the Java Card version, anyway, the output I get is:
    66 4C
         73 4A
              06 07
                   2A 86 48 86 FC 6B 01                         
              60 0C
                   06 0A
                        2A 86 48 86 FC 6B 02 02 01 01          - Card Recognition Data (Note 2)
              63 09
                   06 07
                        2A 86 48 86 FC 6B 03                    - Card Identification Scheme (Note 3)
              64 0B
                   06 09
                        2A 86 48 86 FC 6B 04 01 05               - Secure Channel Protocol (Note 4)
              65 0B
                   06 09
                        2B 85 10 86 48 64 02 01 03               - Card Conf Details (Note 5)
              66 0C 
                   06 0A
                        2B 06 01 04 01 2A 02 6E 01 02          - Card Chip Details (Note 6)
    But I see in no place the Java Card version, that's why I wanted to use JCOP and have that work done for me... :)
  • 8. Re: Smartcardio Compute digital signature with 2048b Key
    893199 Explorer
    Currently Being Moderated
    These are all object identifiers:

    the last three bytes of the card recognition data are the GP level - 2.2.1
    the last two bytes of the secure channel protocol data are the SCP type (1) and the options "0x05".

    The card chip details is an OID - 1.3.6.1.4.1.42.2.110.1.2 - which is an oid in the SUN javaXML software arc. I don't recognize the specific type.

    The card config details are on the 1.3.656 arc - which doesn't seem to have been legitimately registered (at least 656 isn't in the ICD registry).


    But now I'm confused again. You've got a card that has an applet - you can't twiddle with the applet. Why does it matter whether its JCOP or anything else? All that matters is which APDUs and key lengths the applet supports.
  • 9. Re: Smartcardio Compute digital signature with 2048b Key
    safarmer Expert
    Currently Being Moderated
    I thought the problem was in the communication channel, but by what I understand now, the problem is purely on the Applets of the card. Being so, and since I have no control over the Applet, all I have left is to present the issue to the provider right?
    That is correct. The applet may actually be working as intended. It is possible there are security mechanisms built in that will prevent any command being processed after some condition is reached.
    Did you only get this error once and then the card was unresponsive? The 6D00 may mean that a security violation has been detected by the JCRE/Card OS and has locked the card.
    No, between different tests and showing off to other ppl the behavior of the cards and code when the keys were 1024 bits or 2048 bits, I must have tried like, I guess it must have a counter similar to the PIN counter, although I had no idea at the time...
    It sounds like you need to get in touch with the applet provider and see if there is anything in the documentation.
    The applet needs to be modified to implement the ExtendedLength interface to be able to handle extended length APDU's. It also requires a JC 2.2.2 card and support is optional.
    I tried to found out the Java Card version of the card, I even found this thread {thread:id=1749759} but I couldn't get the JCOP Tools anywhere in order to run the command 'get-data 0066'
    There is no need to do this. If you a generating a RSA2048 signature, you can return the entire signature in one response APDU. Even though it was stated elsewhere that you need more than 256 bytes, that is incorrect. Also, you have no way of modifying the applet. Extended APDU's are not required and the comments just caused more confusion than anything else.

    Shane
  • 10. Re: Smartcardio Compute digital signature with 2048b Key
    safarmer Expert
    Currently Being Moderated
    If you a generating a RSA2048 signature, you can return the entire signature in one response APDU.
    This is of course if it is just a signature and not some other data object that contains a signature.

    Shane
  • 11. Re: Smartcardio Compute digital signature with 2048b Key
    816731 Newbie
    Currently Being Moderated
    I'm already contacting the Vendor, although, this will take a lot of time.
    The card config details are on the 1.3.656 arc - which doesn't seem to have been legitimately registered (at least 656 isn't in the ICD registry).
    It's probably because these are still testcards
    But now I'm confused again. You've got a card that has an applet - you can't twiddle with the applet. Why does it matter whether its JCOP or anything else? All that matters is which APDUs and key lengths the applet supports.
    You're right, I just wanted to use the JCOP tools to verify the Card OS version, I read in this post that the Java Card version should be at least 2.2.2 to support 256+ bytes communication buffers (if I didn't interpret anything badly)
  • 12. Re: Smartcardio Compute digital signature with 2048b Key
    816731 Newbie
    Currently Being Moderated
    If you a generating a RSA2048 signature, you can return the entire signature in one response APDU.
    This is of course if it is just a signature and not some other data object that contains a signature.
    I'm having some doubts about the process here (at the communication level).

    The signature is a simple PKCS1, it's not wrapped in any kind of object. If I have a 1024b key I get 1024b signature from the card, no problem. However, that signature comes with a trail of 2 extra bytes that are the SW, so, I have a total of 130 bytes output answer.

    Since it's less then 256 bytes, there are no problems.

    However, with the 2048b key, we have 256 bytes signature + 2 bytes from the SW, giving 258 bytes of total output.

    My doubt now, is if this is a problem or not. I thought it was, but, did I misinterpreted, or you're telling me the SW bytes don't count for the total communication buffer length?

    Cad
  • 13. Re: Smartcardio Compute digital signature with 2048b Key
    safarmer Expert
    Currently Being Moderated
    A standard length response APDU is 256 bytes data + 2 bytes status word totaling 258 bytes. Sending a command with an Le of 00 means that you want the maximum available data up to 256 bytes.

    Shane

Legend

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