2 Replies Latest reply on Jul 30, 2014 9:12 AM by Sebastien_Lorquet

    [Javacard] Applet Secure channel problems


      Hi, i'm creating a java card applet that needs a secure channel

      communication using smartcafé 3.2 with java card 2.2.2.

      I created the following script that sends initiates and communicates

      with the card using a secure channel (using GPShell 1.4.4).


      APDU script:


      select -AID A000000003000000 

      open_sc -security 3 -scp 2 -scpimpl 0x15 -keyver 1 -key

      404142434445464748494a4b4c4d4e4f -keyDerivation emvcps11


      select -AID ABCDEFFEDC123456

      send_apdu -sc 1 -APDU 801500000b0102030405060708090001


      The applet:


      public void deselect() {




        public boolean select(){

        sc = GPSystem.getSecureChannel();

        return true;



      public void process(APDU apdu) throws ISOException {

        byte[] buffer = apdu.getBuffer();

        short apduSize = apdu.setIncomingAndReceive(); 

        if (selectingApplet())


        switch (buffer[ISO7816.OFFSET_INS]) {

        case INS_TEST: 

        short sec_lv = sc.getSecurityLevel();



      I've confirmed that the APDU reaches INS_TEST, and the security level is

      always 0x00. So i'm unable to unwrap the command.

      Also, if i try to use the processSecurity(APDU) command, it always

      returns Invalid instruction byte / command not supported (6D00)


      select -AID A000000003000000

      Command --> 00A4040008A000000003000000

      Wrapped command --> 00A4040008A000000003000000

      Response <-- 6F108408A000000003000000A5049F6501FF9000

      command time: 46 ms

      open_sc -security 3 -scp 2 -scpimpl 0x15 -keyver 1 -key


      4c4d4e4f -keyDerivation emvcps11

      Command --> 8050010008691DB5CA566F965100

      Wrapped command --> 8050010008691DB5CA566F965100

      Response <-- 00000139E3ABB8FC952401020401FD3A555D1EA91291B2DF836627DE9000

      Command --> 8482030010CA2B47FD8A6EDD6744EF2A787B64D0D7

      Wrapped command --> 8482030010CA2B47FD8A6EDD6744EF2A787B64D0D7

      Response <-- 9000

      command time: 219 ms

      select -AID ABCDEFFEDC123456

      Command --> 00A4040008ABCDEFFEDC123456

      Wrapped command --> 00A4040008ABCDEFFEDC123456

      Response <-- 9000

      command time: 31 ms

      send_apdu -sc 1 -APDU 801500000b0102030405060708090001

      Command --> 801500000B0102030405060708090001

      Wrapped command -->


      Response <-- 6D00

      send_APDU() returns 0x80206D00 (6D00: Invalid instruction byte / Commandnot supported or invalid.)


      Thanks for the time

        • 1. Re: [Javacard] Applet Secure channel problems



          a gp secure channel is opened with an application (aid), which means that selecting another application (aid) will break the current channel.



          you are opening a channel with the security domain (a0...03)

          then you select your app

          this breaks the previous channel

          then you send an apdu, but the security level is zero, because no security channel was opened with the selected app.


          this will definitely never work.


          there are only two ways to do something like that:


          1) open the secure channel with your app, not with the SD. To do that, you have to manage yourself the INS=50 and INS=82 instructions by forwarding the command to the security domain instance, via the GlobalPlatform API. There is a method for that, the name is processSecurity()



          this function must be called each time your app receives an init update or ext authenticate apdu. It will manage the global platform security for you by calling the proper routines in the security domain that handles your app.


          if authentication is successful, your SecureChannel instance will show an updated security level and you will be able to unwrap wrapped commands.


          the process becomes

          -select your app

          -authenticate using init update and ext auth

          -send wrapped apdus


          this should works on most cards, I have tested and used it 2 years ago, so it's a "well established" behaviour.

          Your 6D00 failure is strange, I did not know that you could disable that.


          2) use the personnalization methods from GP

          With this process

          -select the security domain

          -send INSTALL FOR PERSONALIZATION, passing the AID of the app you want to communicate with

          -send STORE DATA commands, they can contain anything.

          -these store data commands are handled by the processData() callback that belong to the Application interface (you must implement that, see Application )

          -if you want to get data in response to a STORE DATA command, you have to use the Personnalization interface in GP 2.2 admendments. This is not possible with GP 2.1.1, because the Application.processData() method returns void.


          Application should work on most cards, Personnalization requires recent (GP 2.2) cards. Moreover, the idea behind this process is intended for card personnalization, not for a deployed lifecycle.



          I know you tested method 1. I find this non-working behaviour quite strange, but it's difficult to do the same thing on every card, that would be too easy


          I only know one alternative: implement your own GP-compatible secure channel routines. I've also done that before to support R-MAC on a card that didn't support it.

          Then, you "just" have to find a way to store GP keys in your application.



          • 2. Re: [Javacard] Applet Secure channel problems

            Sometimes I feel like I just answered to a clever spam bot...