Java Card applets, secure data transmission and Secure Channel

Question

I want to write my applet in a way that its APDU commands and status words wasn't be clear in the transmission channel between my card and my reader. I mean I don't want to send APDU commands and responses to be plain text for third parties.

I think I have two option :

1. After selecting my applet on the card, for all the other commands, do an encryption function on the data section of APDU commands and decrypt them on the card and after that analyze them. Note that I can't encrypt whole the command using this methodology because the result may have conflict with another SELECT APDU command and the SD of card recognize it as a SELECT command wrongly. is that right?

Its Diagram :

2. Using SD Secure Channel : As far as I know secure channel means : Whole of the APDU commands and responses transmit in an encrypted form (i.e. they encrypt in the source(Security Domain/Card reader) and decrypt in the destination(Secutity Domain/Card Reader). is that right? As far as I know the SD perform the cryptography method role in this mechanism and the communication between my applet and the SD is in plain (Below diagram), right?

Its Diagram :

Is there any other way?

It seems that the first solution is not good enough, because :

1. I must implement it myself! :)
2. We can't hide all parts of the command and response from third-parties.(We can hide data only)

Am I right?

Now, let assume that I want to be sure that my applet works only with APDU commands that transmitted using secure channel . I think I have two option again :

1. Put the card in SECURED state. As the user can't communicate with the card with plain text APDU commands in this state (right?) therefore he must send the commands to my applet using secure channel. right? if it is not correct, is there any way to force the SD to work with Secure Channel only?

2. Keep the card in any life cycle that it is (for example OP_READY), But instead, on reception of any APDU command, check the CLA section to see if it is a secure transmitted or not! (Is it possible? Is there any difference between CLA part of APDU commands that come from secure channel and the other ones? Am I right?)

Is there any other way?

And finally the main question :

How can I use SD to have a secure communication with my applet? As I thought I must use GlobalPlatform classes(Am I?), I took a look at its API-s. I found a method named getSecureChannel in a package named org.globalplatform.GPSystem. Am I in a right way? Am I must use this method?

I know that this may be too long to answer, but I'm sure that it clarify a lot of questions not only for me, but also for other future viewers.

I appreciate any body shed any light in this issue for me.

And a sample applet is more appreciable.

Retrorocket

1. This is too many questions. 2. Some questions don't belong to SO 3. These questions are standard problems and have been solved many times 4. Why don't you try to solve your problems instead of asking everything on SO? – Option

@PaulBastian 1- You are right, but I think all of these questions is for one problem. 2- Those are related to my SO question. 3- May I ask you refer me to those questions and answers please? 4- Definitely I tried to solve them myself, but I couldn't. Moreover, I think this question help future viewers also, doesn't it? – Retrorocket

@Abraham Do you know how I can import org.globalplatform to my project? I think it is not installed on my system. From where I can find and download it? – Inconsistency

@M.Jalali You can download JAVA COS IDE. It is free and it contains these libraries by default. Download Link – Retrorocket

@M.Jalali You can also download your appropriate version from Global Platform card specification page – Retrorocket

Answer 1

I'll answer in order:

1. Yes, for ISO/IEC 7816-4 only the data section is encrypted. The header is just protected by the authentication tag.
2. No, the Global Platform secure channel also just (optionally) encrypts the data. The integrity is over header and command data though.
3. No, the secured state is for Global Platform only, you'll have to program this for yourself using the on card GP API. The GP API has access methods to perform authentication, request the secure channel and to retrieve the current state.
4. Correct, the CLA byte determines if the APDU is encrypted (not how it is encrypted though). If the first bit of the CLA is zero then your secure channel must however be compliant to ISO/IEC 7816-4.

Mallis

I'm not 100% sure if 3 is correct if the Applet is a security domain (SD). I've arguably done to little with SD's. – Mallis

I Highly appreciate your time,Thanks. The header is just protected by the authentication tag. : What is this authentication tag? If the header is not encrypted in the secure channel protocols, the third-party can obtain them by sniffing the channel.right? – Retrorocket

@Abraham Right. Authentication tag = result of MAC mechanism. Yes, the header is usually visible. This is required because the ISO/IEC 7816 is not layered as it should be (the application protocol and transport protocol are mixed together). Normally the header doesn't contain any confidential data, but you should remember that using P1/P2 for confidential information is not a good idea. – Mallis

Answer 2

Don't worry for secure channel communication via applet. It's very simple if you use Global Platform APIs in your applet.

You don't need to think about lot's of questions, just try to write an secure channel applet and it will process your applet as per defined security level in the command data.

Refer GP secure channel APIs: http://www.win.tue.nl/pinpasjc/docs/apis/gp22/

And you should keep the card in SECURED state.

And this is the sample applet for secure channel scp02:

package secureChannel;

import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISO7816;
import javacard.framework.ISOException;

import org.globalplatform.GPSystem;
import org.globalplatform.SecureChannel;

public class Scp02 extends Applet
{
    final static byte INIT_UPDATE       = (byte) 0x50;

    final static byte EXT_AUTHENTICATE  = (byte) 0x82;

    final static byte STORE_DATA        = (byte) 0xE2;

    public static void install(byte[] bArray, short sOffset, byte bLength)
    {
        new Scp02().register(bArray, sOffset, bLength);
    }

    public void process(APDU apdu) throws ISOException
    { 
        SecureChannel sc = GPSystem.getSecureChannel();

        byte[] buffer = apdu.getBuffer();

        short inlength = 0;

        switch (ISO7816.OFFSET_INS)
        {
            case INIT_UPDATE:
            case EXT_AUTHENTICATE:
                inlength = apdu.setIncomingAndReceive();
                sc.processSecurity(apdu);
            break;

            case STORE_DATA:
                //Receive command data
                inlength = apdu.setIncomingAndReceive();
                inlength = sc.unwrap(buffer, (short) 0, inlength);

                apdu.setOutgoingAndSend((short)0, inlength);

                //Process data
                break;
        }
    }
}

Sordello

How does this actually get the SecureChannel with an actual USB Card Reader? – Shingly

This is just 1/2 of the answer. The other half is how to do it in the laptop. – Damon

Answer 3

For the sake of Google search, the code from Anurag Bajpai doesn't work without a slight modification since, as stated in GP secure channel APIs, the applet should output eventual response data:

If response data is present, this data will be placed in the APDU buffer at offset ISO7816.OFFSET_CDATA. The return value indicates the length and the applet is responsible for outputting this data if necessary.

Hence, the corrected code is:

package secureChannel;

import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISO7816;
import javacard.framework.ISOException;
import org.globalplatform.GPSystem;
import org.globalplatform.SecureChannel;


public class Scp02 extends Applet
{
    final static byte INIT_UPDATE       = (byte) 0x50;

    final static byte EXT_AUTHENTICATE  = (byte) 0x82;

    final static byte STORE_DATA        = (byte) 0xE2;

    public static void install(byte[] bArray, short sOffset, byte bLength)
    {
        new Scp02().register(bArray, sOffset, bLength);
    }

    public void process(APDU apdu) throws ISOException
    { 
        SecureChannel sc = GPSystem.getSecureChannel();

        byte[] buffer = apdu.getBuffer();

        short inlength = 0;

        switch (ISO7816.OFFSET_INS)
        {
            case INIT_UPDATE:
            case EXT_AUTHENTICATE:
                inlength = apdu.setIncomingAndReceive();
                short respLen = sc.processSecurity(apdu);
                apdu.setOutgoingAndSend(ISO7816.OFFSET_CDATA, respLen);
            break;

            case STORE_DATA:
                //Receive command data
                inlength = apdu.setIncomingAndReceive();
                inlength = sc.unwrap(buffer, (short) 0, inlength);

                apdu.setOutgoingAndSend((short)0, inlength);

                //Process data
            break;
    }
}

}

Sletten

Answer 4

Please note that it is incorrect to call apdu.setIncomingAndReceive() before calling sc.processSecurity(apdu), as processSecurity() "is responsible for receiving the data field of commands that are recognized".

Vaughnvaught