1 2 Previous Next 17 Replies Latest reply: Apr 4, 2012 3:27 AM by 915199 RSS

    6E00 ADPU Response

    915199
      Hello,

      I'm trying to dialog with an EMV chip card. For this I'm using the package "javax.smartcardio". Everything goes well at the beginning, until the final application selection, as I'm using Class 0x00.
      At this point, after the selection of one of the EMV application, I must send a new APDU command (GET PROCESSING OPTION) with class 0x80
      Here is the command that I send: "80 A8 00 00 02 83 00 00"

      Here is an extract of the code:

      byte[] myPDOLData={ (byte) 0x83, 0x00};
      CommandAPDU myCommand = new CommandAPDU((byte)0x80, (byte)0xA8, 0x00, 0x00, myPDOLData, 0x100);
      myChannel.transmit(myCommand);

      At this moment the status bytes returned are "6E 00" which, I think, means that the Class is incorrect.

      I'm working with the JDK1.6
      My card is a T=0 card.
      ATR is 0x3B 0x6C 0x00 0x00 0x00 0x31 0xc0 0x71 0xd6 0x64 0x00 0x01 0x01 0x01 0x5d 0x84

      I have any clue on this problems.
      Can someone tells me what I did wrong or what am I missing?

      Thanks in advance
        • 1. Re: 6E00 ADPU Response
          Umer
          Hi,

          The complete flow should be like that:

          1. Select a terminal
          2. Connect to card either T=0 or T=1
          3. Select an applet currently installed on the card
          4. start sending subsequent apdu commands....

          I think you might missing the 3rd step.

          Regards
          • 2. Re: 6E00 ADPU Response
            Umer
            Can you mentioned that status word returned by selecting the application ?

            also below is a link just for the idea for you:
            http://blog.saush.com/2006/09/08/getting-information-from-an-emv-chip-card/

            Regards
            • 3. Re: 6E00 ADPU Response
              915199
              Thank you for your answers and for the link to the "saush blog". I indeed did not provide the complete flow of APDU with the card, here is it


              ATR:3b6500002063cb6600
              ATR: 9 bytes
              Direct convention
              TB1 present value:0
              TC1 Extra guard time present value:0
              Proprietary category indicator byte
              Historical bytes:20
              Historical bytes:63
              Historical bytes:cb
              Historical bytes:66
              Historical bytes: 0

              The ATR indicates a T=0 card.

              I first try to select the PSE
              SEND():
              00 A4 04 00 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00

              RECV():
              6F 1C 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 0A 88 01 07 5F 2D 04 66 72 65 6E 90 00 01


              Then, based on the PSE content, a read all the record of the Payment System Directory, starting with record 1, in order to get the list of ADF.

              Read record n°1
              SEND():
              00 B2 01 3C 00

              ADF received
              RECV():
              70 12 61 10 4F 07 A0 00 00 00 42 10 10 50 02 43 42 87 01 01 90 00

              Read record n°2
              SEND():
              00 B2 02 3C 00

              ADF received
              RECV():
              70 1A 61 18 4F 07 A0 00 00 00 03 10 10 50 0A 56 49 53 41 20 44 45 42 49 54 87 01 02 90 00

              Read record n°3
              SEND():
              00 B2 03 3C 00

              RECV():
              6A 83 --> no more records

              I, then have a list of two ADF (2 AIDs) and I select one of them.
              SEND():
              00 A4 04 00 07 A0 00 00 00 42 10 10 00

              RECV():
              6F 26 84 07 A0 00 00 00 42 10 10 A5 1B 50 02 43 42 87 01 01 5F 2D 04 66 72 65 6E BF 0C 0A DF 60 02 0B 14 9F 4D 02 0B 14 90 00 --> the status bytes are 90 00 everything seems fine

              Then I send the Get Processing Option with no PDOL Data as this data is missing in the previous select (tag 9F38), so PDOL is send with a length of 0 (83 00)
              SEND():
              80 A8 00 00 02 83 00 00

              RECV():
              6E 00
              • 4. Re: 6E00 ADPU Response
                Umer
                I have't seen response on selecting the application like ever:
                RECV():
                6F 1C 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 0A 88 01 07 5F 2D 04 66 72 65 6E 90 00 *01*

                Regards
                Umer
                • 5. Re: 6E00 ADPU Response
                  915199
                  Sorry for this, it is a bad copy/paste of my logs. As I trace the binary and then the ASCII data, I withdraw the ASCII data but forget an extra 01 at the end. This 01 is not in the response, sorry for the misleading...
                  • 6. Re: 6E00 ADPU Response
                    safarmer
                    Hi,

                    Have you tried sending the command with CLA=0x00? Does this work or do you get a different error?

                    Cheers,
                    Shane
                    • 7. Re: 6E00 ADPU Response
                      915199
                      Yes, I get the exact same result but thank you for trying to help me. By the way, why do you think it should react differently? Because my scenario is fully compliant with the EMV processing (in fact I think it is).
                      • 8. Re: 6E00 ADPU Response
                        safarmer
                        Umer wrote:
                        I have't seen response on selecting the application like ever:
                        RECV():
                        6F 1C 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 0A 88 01 07 5F 2D 04 66 72 65 6E 90 00 *01*
                        That is the File Control Information (FCI template) as defined in the GP card spec. It is a way of encoding specific data in a response to selecting an applet.

                        Cheers,
                        Shane
                        • 9. Re: 6E00 ADPU Response
                          safarmer
                          That was just a trouble shooting step to see if there was some code only allowing on particular CLA values. If you cannot support a standard inter-industry ISO command or a proprietary command it may be doing some specific checks for logical channels etc. Since the CLA is a bit mask defined in 7816-4, you would expect a specific error if it was something other than being the wrong type of CLA (as in standard or proprietary, b8 )

                          Do you know what implementation of EMV you have? Is MasterCard PayPass (MChip4 etc) or Visa Mobile Payment Applet?

                          Cheers,
                          Shane
                          • 10. Re: 6E00 ADPU Response
                            801926
                            I recall there was a bug in smartcardio for T=0. Check out Oracle's bug database.
                            • 11. Re: 6E00 ADPU Response
                              915199
                              Hello Shane,

                              It is a VISA card but don't know if it is a Visa Mobile Payment Applet. I've done the test with a Mastercard card with the same result. What is unclear for me is that the scenario seems correct to me (at the APDU level with the card) therefore I would havec suspected that the problem comes from the PC/SC driver and your approach with putting the CLASS to 00 was a good approach. I would need a USB spy to check if the command (GetProcessingOption) is really send to the card and the card respond 6E00 or it is the PC/SC driver that reject the command without sending it to the card. As I don't have a card emulator, it's a bit hard to progress on this topic.

                              Nevertheless thanks for your help
                              • 12. Re: 6E00 ADPU Response
                                safarmer
                                Hi,

                                As lexdabear mentioned, there are some issues with smartcardio and T=0 cards. I came across an issue where response chaining would not return the last block if the previous SW was not 0x6100 as smartcardio sends the GET-RESPONSE command on your behalf. There may also be other issues.

                                You could try sending some APDU's with GPShell as it uses pcsc directly and not smartcardio.

                                Cheers,
                                Shane
                                • 13. Re: 6E00 ADPU Response
                                  915199
                                  Hi Shane,

                                  I used GPShell, and I send the exact same APDU sequence. And the problem disapeared. When I send :

                                  80A80000028300

                                  The Card answers correctly (GPShell logs):
                                  80123C00080101001001020118010401200101019000

                                  So I presume the problem comes from the SmartcardIO API. I think I'll have to check the ORACLE database or try to skip this API.

                                  Regards.
                                  • 14. Re: 6E00 ADPU Response
                                    915199
                                    I investigate further on with an USB spy, the problem comes from the Get Response command (effectively in the case of the chaining mode). When I send the get processing option (80A80000028300) the card respond 6114 meaning there is 14 bytes available. But, instead of sending the following APDU (00 C0 00 00 14) it sends (80 C0 00 00 14) which is a Class error, the card than respond 6E00. I suppose SmartCardIO put in the class field of the Get Response the class of the original command (the Get Processing Option) which is an error.
                                    Does anyone has an idea how to fix this problem? Is this problem known from Oracle and is there a fix available? I have, so far, no clue to fix this point.
                                    1 2 Previous Next