Java Card: Send long response with T=0











up vote
2
down vote

favorite












I want to send a long response (1000+ bytes) from the card to the host. The reader only has T=0. I have a few questions wondering if anyone knows:




  1. My understanding is ExtendedLength only works on T=1, is this true?

  2. If so, is there best practice on sending long response on T=0?

  3. One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard


All the best!



Johnny










share|improve this question


























    up vote
    2
    down vote

    favorite












    I want to send a long response (1000+ bytes) from the card to the host. The reader only has T=0. I have a few questions wondering if anyone knows:




    1. My understanding is ExtendedLength only works on T=1, is this true?

    2. If so, is there best practice on sending long response on T=0?

    3. One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard


    All the best!



    Johnny










    share|improve this question
























      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      I want to send a long response (1000+ bytes) from the card to the host. The reader only has T=0. I have a few questions wondering if anyone knows:




      1. My understanding is ExtendedLength only works on T=1, is this true?

      2. If so, is there best practice on sending long response on T=0?

      3. One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard


      All the best!



      Johnny










      share|improve this question













      I want to send a long response (1000+ bytes) from the card to the host. The reader only has T=0. I have a few questions wondering if anyone knows:




      1. My understanding is ExtendedLength only works on T=1, is this true?

      2. If so, is there best practice on sending long response on T=0?

      3. One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard


      All the best!



      Johnny







      smartcard javacard apdu






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 8 at 4:53









      Johnny

      1,09851630




      1,09851630
























          2 Answers
          2






          active

          oldest

          votes

















          up vote
          2
          down vote














          My understanding is ExtendedLength only works on T=1, is this true?




          That is not true. No such limitation is specified in ISO/IEC 7816-4 anyway. However, the card should indicate support for extended length in the ATR / the EF.ATR. Readers may not just assume that extended length is present (but you could ignore this if you're the only one handling the application anyway).




          If so, is there best practice on sending long response on T=0?




          There are many issues with extended length, not all readers support it, Global Platform doesn't support it (the latest version might, I haven't checked) and Java Card only supports up to 32Ki - 1 bytes. Android only has enabled extended length support by default in the latest versions, but you'd better expect NFC enabled phones not to handle it correctly. ISO/IEC 7816-4 made a mess out of the extended length specification, especially in the later versions (2015 onwards).



          Unfortunately you are often constrained to using command chaining or simply by executing multiple READ BINARY commands. The latter is definitely the least error prone - but it is slow and end-of-file handling can be tricky.




          One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard.




          This is the command chaining solution, correct.



          Yes, it is rather idiotic that you cannot indicate warnings without throwing an exception. Well found. But you can just send data and generate the status word by throwing the exception. Probably best to save the status word and generate the exception at the end of your process method.






          share|improve this answer





















          • Reader support of extended length is quite good according to our experience (we have a non-Javacard in our product portfolio, but use T=1 or T=CL). Getting a digital signature with 4096 bit can't be easily partitioned using Read Binary, so this would become a major obstacle. All ICAO-compliant cards would also encounter severe performance problems for reading of photos and fingerprints otherwise due to the command processing overhead.
            – guidot
            Nov 9 at 13:10






          • 1




            NFC reader support sucks. And I specified the extended length for ICAO - or at least I proposed it to be used instead of command chaining. ICAO is a relatively closed eco-system though. I had a Dell laptop with build in NFC reader, it didn't do extended length either.
            – Maarten Bodewes
            Nov 9 at 13:12




















          up vote
          2
          down vote













          1 - extended length works in T=0 as explained by @Maarten in his answer.



          2 - I am not aware of any best practice. But you can try to implement as described in my next answer.



          3 - I partially agree with this, you can use response chaining to get all the response data. Good news is, depending on circumstances, you don't need to implement different protocol handling on applet level. My suggestion is just to do the same processing as you did in T=1, which I imagine is that you just call APDU.sendBytesLong. Then let the platform do the rest like magic.



          In javacard platforms that I have worked before, doing so will lead to the following behavior:



          Suppose you want to send a get Data command to retrieve 1000 bytes of data:




          • Send Get Data which will return 256 bytes of data followed by 61xx

          • Send Get Response APDU (00 C0 00 00 plus desired Le) as much as needed until the returned status word is 9000 which means that all data are returned.


          Take note that the 61xx and processing of Get Response command are handled on platform level and you don't need to do anything in the applet.



          You can give it a try and let me know if it works.






          share|improve this answer





















            Your Answer






            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "1"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














             

            draft saved


            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53201747%2fjava-card-send-long-response-with-t-0%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            2
            down vote














            My understanding is ExtendedLength only works on T=1, is this true?




            That is not true. No such limitation is specified in ISO/IEC 7816-4 anyway. However, the card should indicate support for extended length in the ATR / the EF.ATR. Readers may not just assume that extended length is present (but you could ignore this if you're the only one handling the application anyway).




            If so, is there best practice on sending long response on T=0?




            There are many issues with extended length, not all readers support it, Global Platform doesn't support it (the latest version might, I haven't checked) and Java Card only supports up to 32Ki - 1 bytes. Android only has enabled extended length support by default in the latest versions, but you'd better expect NFC enabled phones not to handle it correctly. ISO/IEC 7816-4 made a mess out of the extended length specification, especially in the later versions (2015 onwards).



            Unfortunately you are often constrained to using command chaining or simply by executing multiple READ BINARY commands. The latter is definitely the least error prone - but it is slow and end-of-file handling can be tricky.




            One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard.




            This is the command chaining solution, correct.



            Yes, it is rather idiotic that you cannot indicate warnings without throwing an exception. Well found. But you can just send data and generate the status word by throwing the exception. Probably best to save the status word and generate the exception at the end of your process method.






            share|improve this answer





















            • Reader support of extended length is quite good according to our experience (we have a non-Javacard in our product portfolio, but use T=1 or T=CL). Getting a digital signature with 4096 bit can't be easily partitioned using Read Binary, so this would become a major obstacle. All ICAO-compliant cards would also encounter severe performance problems for reading of photos and fingerprints otherwise due to the command processing overhead.
              – guidot
              Nov 9 at 13:10






            • 1




              NFC reader support sucks. And I specified the extended length for ICAO - or at least I proposed it to be used instead of command chaining. ICAO is a relatively closed eco-system though. I had a Dell laptop with build in NFC reader, it didn't do extended length either.
              – Maarten Bodewes
              Nov 9 at 13:12

















            up vote
            2
            down vote














            My understanding is ExtendedLength only works on T=1, is this true?




            That is not true. No such limitation is specified in ISO/IEC 7816-4 anyway. However, the card should indicate support for extended length in the ATR / the EF.ATR. Readers may not just assume that extended length is present (but you could ignore this if you're the only one handling the application anyway).




            If so, is there best practice on sending long response on T=0?




            There are many issues with extended length, not all readers support it, Global Platform doesn't support it (the latest version might, I haven't checked) and Java Card only supports up to 32Ki - 1 bytes. Android only has enabled extended length support by default in the latest versions, but you'd better expect NFC enabled phones not to handle it correctly. ISO/IEC 7816-4 made a mess out of the extended length specification, especially in the later versions (2015 onwards).



            Unfortunately you are often constrained to using command chaining or simply by executing multiple READ BINARY commands. The latter is definitely the least error prone - but it is slow and end-of-file handling can be tricky.




            One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard.




            This is the command chaining solution, correct.



            Yes, it is rather idiotic that you cannot indicate warnings without throwing an exception. Well found. But you can just send data and generate the status word by throwing the exception. Probably best to save the status word and generate the exception at the end of your process method.






            share|improve this answer





















            • Reader support of extended length is quite good according to our experience (we have a non-Javacard in our product portfolio, but use T=1 or T=CL). Getting a digital signature with 4096 bit can't be easily partitioned using Read Binary, so this would become a major obstacle. All ICAO-compliant cards would also encounter severe performance problems for reading of photos and fingerprints otherwise due to the command processing overhead.
              – guidot
              Nov 9 at 13:10






            • 1




              NFC reader support sucks. And I specified the extended length for ICAO - or at least I proposed it to be used instead of command chaining. ICAO is a relatively closed eco-system though. I had a Dell laptop with build in NFC reader, it didn't do extended length either.
              – Maarten Bodewes
              Nov 9 at 13:12















            up vote
            2
            down vote










            up vote
            2
            down vote










            My understanding is ExtendedLength only works on T=1, is this true?




            That is not true. No such limitation is specified in ISO/IEC 7816-4 anyway. However, the card should indicate support for extended length in the ATR / the EF.ATR. Readers may not just assume that extended length is present (but you could ignore this if you're the only one handling the application anyway).




            If so, is there best practice on sending long response on T=0?




            There are many issues with extended length, not all readers support it, Global Platform doesn't support it (the latest version might, I haven't checked) and Java Card only supports up to 32Ki - 1 bytes. Android only has enabled extended length support by default in the latest versions, but you'd better expect NFC enabled phones not to handle it correctly. ISO/IEC 7816-4 made a mess out of the extended length specification, especially in the later versions (2015 onwards).



            Unfortunately you are often constrained to using command chaining or simply by executing multiple READ BINARY commands. The latter is definitely the least error prone - but it is slow and end-of-file handling can be tricky.




            One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard.




            This is the command chaining solution, correct.



            Yes, it is rather idiotic that you cannot indicate warnings without throwing an exception. Well found. But you can just send data and generate the status word by throwing the exception. Probably best to save the status word and generate the exception at the end of your process method.






            share|improve this answer













            My understanding is ExtendedLength only works on T=1, is this true?




            That is not true. No such limitation is specified in ISO/IEC 7816-4 anyway. However, the card should indicate support for extended length in the ATR / the EF.ATR. Readers may not just assume that extended length is present (but you could ignore this if you're the only one handling the application anyway).




            If so, is there best practice on sending long response on T=0?




            There are many issues with extended length, not all readers support it, Global Platform doesn't support it (the latest version might, I haven't checked) and Java Card only supports up to 32Ki - 1 bytes. Android only has enabled extended length support by default in the latest versions, but you'd better expect NFC enabled phones not to handle it correctly. ISO/IEC 7816-4 made a mess out of the extended length specification, especially in the later versions (2015 onwards).



            Unfortunately you are often constrained to using command chaining or simply by executing multiple READ BINARY commands. The latter is definitely the least error prone - but it is slow and end-of-file handling can be tricky.




            One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard.




            This is the command chaining solution, correct.



            Yes, it is rather idiotic that you cannot indicate warnings without throwing an exception. Well found. But you can just send data and generate the status word by throwing the exception. Probably best to save the status word and generate the exception at the end of your process method.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 9 at 12:10









            Maarten Bodewes

            60.6k973169




            60.6k973169












            • Reader support of extended length is quite good according to our experience (we have a non-Javacard in our product portfolio, but use T=1 or T=CL). Getting a digital signature with 4096 bit can't be easily partitioned using Read Binary, so this would become a major obstacle. All ICAO-compliant cards would also encounter severe performance problems for reading of photos and fingerprints otherwise due to the command processing overhead.
              – guidot
              Nov 9 at 13:10






            • 1




              NFC reader support sucks. And I specified the extended length for ICAO - or at least I proposed it to be used instead of command chaining. ICAO is a relatively closed eco-system though. I had a Dell laptop with build in NFC reader, it didn't do extended length either.
              – Maarten Bodewes
              Nov 9 at 13:12




















            • Reader support of extended length is quite good according to our experience (we have a non-Javacard in our product portfolio, but use T=1 or T=CL). Getting a digital signature with 4096 bit can't be easily partitioned using Read Binary, so this would become a major obstacle. All ICAO-compliant cards would also encounter severe performance problems for reading of photos and fingerprints otherwise due to the command processing overhead.
              – guidot
              Nov 9 at 13:10






            • 1




              NFC reader support sucks. And I specified the extended length for ICAO - or at least I proposed it to be used instead of command chaining. ICAO is a relatively closed eco-system though. I had a Dell laptop with build in NFC reader, it didn't do extended length either.
              – Maarten Bodewes
              Nov 9 at 13:12


















            Reader support of extended length is quite good according to our experience (we have a non-Javacard in our product portfolio, but use T=1 or T=CL). Getting a digital signature with 4096 bit can't be easily partitioned using Read Binary, so this would become a major obstacle. All ICAO-compliant cards would also encounter severe performance problems for reading of photos and fingerprints otherwise due to the command processing overhead.
            – guidot
            Nov 9 at 13:10




            Reader support of extended length is quite good according to our experience (we have a non-Javacard in our product portfolio, but use T=1 or T=CL). Getting a digital signature with 4096 bit can't be easily partitioned using Read Binary, so this would become a major obstacle. All ICAO-compliant cards would also encounter severe performance problems for reading of photos and fingerprints otherwise due to the command processing overhead.
            – guidot
            Nov 9 at 13:10




            1




            1




            NFC reader support sucks. And I specified the extended length for ICAO - or at least I proposed it to be used instead of command chaining. ICAO is a relatively closed eco-system though. I had a Dell laptop with build in NFC reader, it didn't do extended length either.
            – Maarten Bodewes
            Nov 9 at 13:12






            NFC reader support sucks. And I specified the extended length for ICAO - or at least I proposed it to be used instead of command chaining. ICAO is a relatively closed eco-system though. I had a Dell laptop with build in NFC reader, it didn't do extended length either.
            – Maarten Bodewes
            Nov 9 at 13:12














            up vote
            2
            down vote













            1 - extended length works in T=0 as explained by @Maarten in his answer.



            2 - I am not aware of any best practice. But you can try to implement as described in my next answer.



            3 - I partially agree with this, you can use response chaining to get all the response data. Good news is, depending on circumstances, you don't need to implement different protocol handling on applet level. My suggestion is just to do the same processing as you did in T=1, which I imagine is that you just call APDU.sendBytesLong. Then let the platform do the rest like magic.



            In javacard platforms that I have worked before, doing so will lead to the following behavior:



            Suppose you want to send a get Data command to retrieve 1000 bytes of data:




            • Send Get Data which will return 256 bytes of data followed by 61xx

            • Send Get Response APDU (00 C0 00 00 plus desired Le) as much as needed until the returned status word is 9000 which means that all data are returned.


            Take note that the 61xx and processing of Get Response command are handled on platform level and you don't need to do anything in the applet.



            You can give it a try and let me know if it works.






            share|improve this answer

























              up vote
              2
              down vote













              1 - extended length works in T=0 as explained by @Maarten in his answer.



              2 - I am not aware of any best practice. But you can try to implement as described in my next answer.



              3 - I partially agree with this, you can use response chaining to get all the response data. Good news is, depending on circumstances, you don't need to implement different protocol handling on applet level. My suggestion is just to do the same processing as you did in T=1, which I imagine is that you just call APDU.sendBytesLong. Then let the platform do the rest like magic.



              In javacard platforms that I have worked before, doing so will lead to the following behavior:



              Suppose you want to send a get Data command to retrieve 1000 bytes of data:




              • Send Get Data which will return 256 bytes of data followed by 61xx

              • Send Get Response APDU (00 C0 00 00 plus desired Le) as much as needed until the returned status word is 9000 which means that all data are returned.


              Take note that the 61xx and processing of Get Response command are handled on platform level and you don't need to do anything in the applet.



              You can give it a try and let me know if it works.






              share|improve this answer























                up vote
                2
                down vote










                up vote
                2
                down vote









                1 - extended length works in T=0 as explained by @Maarten in his answer.



                2 - I am not aware of any best practice. But you can try to implement as described in my next answer.



                3 - I partially agree with this, you can use response chaining to get all the response data. Good news is, depending on circumstances, you don't need to implement different protocol handling on applet level. My suggestion is just to do the same processing as you did in T=1, which I imagine is that you just call APDU.sendBytesLong. Then let the platform do the rest like magic.



                In javacard platforms that I have worked before, doing so will lead to the following behavior:



                Suppose you want to send a get Data command to retrieve 1000 bytes of data:




                • Send Get Data which will return 256 bytes of data followed by 61xx

                • Send Get Response APDU (00 C0 00 00 plus desired Le) as much as needed until the returned status word is 9000 which means that all data are returned.


                Take note that the 61xx and processing of Get Response command are handled on platform level and you don't need to do anything in the applet.



                You can give it a try and let me know if it works.






                share|improve this answer












                1 - extended length works in T=0 as explained by @Maarten in his answer.



                2 - I am not aware of any best practice. But you can try to implement as described in my next answer.



                3 - I partially agree with this, you can use response chaining to get all the response data. Good news is, depending on circumstances, you don't need to implement different protocol handling on applet level. My suggestion is just to do the same processing as you did in T=1, which I imagine is that you just call APDU.sendBytesLong. Then let the platform do the rest like magic.



                In javacard platforms that I have worked before, doing so will lead to the following behavior:



                Suppose you want to send a get Data command to retrieve 1000 bytes of data:




                • Send Get Data which will return 256 bytes of data followed by 61xx

                • Send Get Response APDU (00 C0 00 00 plus desired Le) as much as needed until the returned status word is 9000 which means that all data are returned.


                Take note that the 61xx and processing of Get Response command are handled on platform level and you don't need to do anything in the applet.



                You can give it a try and let me know if it works.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Nov 12 at 6:48









                Chooch

                483311




                483311






























                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53201747%2fjava-card-send-long-response-with-t-0%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Guess what letter conforming each word

                    Port of Spain

                    Run scheduled task as local user group (not BUILTIN)