Java Card applets, secure data transmission and Secure Channel - javacard

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 :
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 :
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 :
I must implement it myself! :)
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 :
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?
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.

Answer 1

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;
}
}
}

Answer 2

I'll answer in order:
Yes, for ISO/IEC 7816-4 only the data section is encrypted. The header is just protected by the authentication tag.
No, the Global Platform secure channel also just (optionally) encrypts the data. The integrity is over header and command data though.
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.
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.

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;
}
}
}

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".