Forum Stats

  • 3,826,756 Users
  • 2,260,705 Discussions


Java Card APDU Format Verification?

Archie Yang
Archie Yang Member Posts: 2
edited Apr 28, 2017 4:38AM in Java Card

Hi! I have a problem about APDU format in Java Card Applet.

Does Java Card Runtime verify APDU format before pass it to Applet.process method?

I do not find the informations about this in JCRE Specification.

For example:

When APDU =  00 01 02 03 FF 00 01

          CLA = 00

          INS  = 01

          P1 = 02

          P2 = 03

          LC = FF

          Data = 00, 01

This case, data length is not matched to LC, some card does pass it to Applet.process method, some card does not, just return SW 6700(Wrong Length) to reader.

Message was edited by: Archie Yang Correct, P3 => P2


  • patrick.vh-Oracle
    patrick.vh-Oracle Member Posts: 18 Employee
    edited Apr 6, 2017 8:58AM

    What you're describing here is an inconsistent APDU and consistency checks might happen at many different levels, starting from your card-reader and its driver, or in the secure element, and this may vary depending on transport protocol used.

    In particular, the APDU you describe cannot be mapped/encoded directly on ISO 7816 T=0 transport protocol, so the reader may either reject the command without sending it to the card, or might adjust the length to reflect the actual length, or pad the command payload with 0, ...
    With another transport protocol, the inconsistency might be discovered later (e.g. in T=1, data are sent in several chunks and the first chunk might be received and transmitted to the Applet but a subsequent call to receiveBytes may return 0 even though incoming length was expected to be more).

    In any case, your application should use APDU.getIncomingLength(), APDU.setIncomingAndReceive() and loop on APDU.receiveBytes(...) to be compatible with any transport protocol.

  • Archie Yang
    Archie Yang Member Posts: 2
    edited Apr 11, 2017 1:36AM

    Hi! Patrick, thanks for your help!

    Follow your words, such APDU might be rejected even adjusted by reader or driver.

    And in Applet, we shall check actual length received, like Wallet Applet of JCDK's sample codes does.

    (I have written checking process in code, but Applet would not run to there in some T=1 cards)

    My question is: Runtime(OS) should verify APDU before calling Applet.process or not?

    Or, this in non-specified in JCRE Spec., just decided by OS developer?

    Now I have different cards from NXP and Gemalto, all in T=1, using the same environment,

    all cards from Gemalto would not verify APDU, just pass it to Applet.process;

    but cards from NXP have various behavior, some just respond SW 6700 without calling Applet.process.

    My goal is doing other work(Clear buffer, security data..., etc.) in Applet when APDU comes with wrong length, but Applet.process is not been called in some NXP cards.

  • patrick.vh-Oracle
    patrick.vh-Oracle Member Posts: 18 Employee
    edited Apr 28, 2017 4:38AM

    Yes, this is (OS) implementation dependent and several combinations are possible, specifically in T=1: the implementation may decide to do some buffering first and fill the APDU buffer or transmit each received block to the Applet.

    Rejecting the command without invoking the Applet is not always possible in particular if the APDU buffer is not large enough to hold the entire message. This could be the case because of resource constraints, in particular if the implementation supports extended APDU.

    So the Applet should not expect the command to be rejected automatically and should use the APDU.getIncomingLength(), APDU.setIncomingAndReceive() and APDU.receiveBytes(...) to write code that behave consistently on different implementations and it's a good (security) practice to check the consistency of data received to behave accordingly and perform the required clean-up.

    On the other hand, the Applet should not expect to always receive such message, because this depends on the implementation and also on the protocol. Is this critical for the behavior and security of your Applet?

This discussion has been closed.