Questions about the JavaCard kit 2.2.2

The current version of tools I have installed is 3.1.2.

However, I might have reached the conclusion of AES not being supported prematurely. I assumed that was the problem when the line

key = (AESKey) KeyBuilder.buildKey(KeyBuilder.TYPE_AES, (short) 128, false);

returns "Unexpected error; aborting execution", but does not when replaced with the line

key = (DESKey) KeyBuilder.buildKey(KeyBuilder.TYPE_DES, (short) 64, false);

Can I set the version of JCOP being used in the simulator myself? I've been looking for a way to do that, but haven't been able to find anything yet.

Message edit:

Turns out you are right, I am using the latest version which should be supporting AES and ECC. Then the problem probably is that I have some unknown programming error. If anyone is able to shed some light on what that might be, it would be greatly appreciated.

Lillesanda at 2007-7-12 19:48:49 >

Okay, as mentioned I have JCOP21 and JCOP41, so that should be fine.

I'm currently using the embedded simulator in eclipse, and I get it during the installation. The relevant source code is

import javacard.framework.APDU;

import javacard.framework.Applet;

import javacard.framework.ISO7816;

import javacard.framework.ISOException;

import javacardx.crypto.Cipher;

import javacard.framework.OwnerPIN;

import javacard.security.KeyBuilder;

import javacard.framework.Util;

import javacard.security.AESKey;

public class AESApplet extends Applet {

/* Variable Definitions */

//CLAss definition

private final static byte AESApplet_CLA = (byte)0xB0;

//INStructions

// Encrypt data

private final static byte ENCRYPT_DATA = 0x01;

// Decrypt data

private final static byte DECRYPT_DATA = 0x02;

// Set PIN for administrator access

private final static byte SET_PIN = 0x03;

// Set key

private final static byte SET_KEY = 0x05;

//Custom Exceptions

// Unauthorized user attempts to perform operation that requires authorization

private final static short USER_NOT_AUTHORIZED = 0x6601;

// Wrong PIN given

private final static short ERRORNEOUS_PIN = 0x6301;

// Maximum number of PIN attempts performed. Should result in a locking of the card or the admin privileges.

private final static short MAX_PIN_ATTEMPTS_REACHED = 0x6302;

// Function disabled

private final static short FUNCTION_DISABLED = 0x6303;

// Key submitted has wrong length

private final static short INVALID_KEY_LENGTH = 0x6304;

//Constants

// Maximum number of guesses at the PIN (should be relatively low for this key, as all security is compromised if the key is)

private final static byte MAX_PIN_ATTEMPTS = 0x01;

// Maximum length of the PIN

private final static byte MAX_PIN_LENGTH = 0x06;

// Offset to PIN in install message. TODO: Depending on the format of the INSTALL APDU used, this might very well be a source of errors.

private final static short INIT_PIN_OFFSET = 9;

// Set default key to use untill a new one is set.

//private final static byte[] tempKey = {(byte) 0xAB, (byte) 0xCD, (byte) 0xEE, (byte) 0x0E, (byte) 0x12, (byte) 0x35,

//(byte) 0x87, (byte) 0xFA };

//Instance variable declaration

// Administrator PIN

OwnerPIN adminPIN;

// Cipher to be used

Cipher cipher;

// Reference to the key in use

AESKey key;

/*

* Class constructor. Should only be called from install()

*/

private AESApplet(byte[] bArray, short bOffset, byte bLength){

// Instanciate PIN

adminPIN = new OwnerPIN(MAX_PIN_ATTEMPTS, MAX_PIN_LENGTH);

// Set PIN from installation parameters

adminPIN.update(bArray, (byte)(bOffset+INIT_PIN_OFFSET), (byte)(bLength-INIT_PIN_OFFSET));

// Instanciate the cipher. For now, assume AES.

cipher = Cipher.getInstance(javacardx.crypto.Cipher.ALG_AES_BLOCK_128_CBC_NOPAD, false);

// Generate key

key = (AESKey) KeyBuilder.buildKey(KeyBuilder.TYPE_AES, KeyBuilder.LENGTH_AES_128, false);

// Set key value.

//key.setKey(tempKey,(short)0);

// Register the applet in the JCRE.

register();

}

public static void install(byte[] bArray, short bOffset, byte bLength) {

// Create the object, which will later do the registration

new AESApplet(bArray, bOffset, bLength);

}

The applet is really alot bigger, but this is the relevant part. Using the JCOP debug functionality I know the error occurs on the key building line:

key = (AESKey) KeyBuilder.buildKey(KeyBuilder.TYPE_AES, KeyBuilder.LENGTH_AES_128, false);

And the trace:

Load report:

875 bytes loaded in 0.0 seconds

effective code size on card:

+ package AID5

+ applet AIDs20

+ classes29

+ methods480

+ statics0

+ exports0

overall534 bytes

cm> install -i a1a1a1a1a1 -q C9#(ff01ff) f2f2f2f2f2 a1a1a1a1a1

=> 80 E6 0C 00 1B 05 F2 F2 F2 F2 F2 05 A1 A1 A1 A1................

A1 05 A1 A1 A1 A1 A1 01 00 05 C9 03 FF 01 FF 00................

00 .

(5441 usec)

<= 6A 80 j.

Status: Wrong data

jcshell: Error code: 6a80 (Wrong data)

jcshell: Wrong response APDU: 6A80

Unexpected error; aborting execution

Note that I omitted some irrelevant code and trace data, but if this is needed as well, please let me know.

Thanks for being so helpful :).

Lillesanda at 2007-7-12 19:48:49 >

All right, thank you very much!

At the moment I'm still using the JCOP simulator in Eclipse, so I don't know if the identify actually gives any real information:

cm> /identify

=> 00 A4 04 00 09 A0 00 00 01 67 41 30 00 FF .........gA0..

(10997 usec)

<= 00 00 01 00 00 00 00 00 74 6F 6F 6C 73 20 00 00........tools ..

6A 82 j.

Status: File not found

FABKEY ID:0x00

PATCH ID:0x00

TARGET ID:0x01 (generic)

MASK ID:0x00 (0)

CUSTOM MASK: 00000000

MASK NAME:tools

FUSE STATE: not fused

ROM INFO:-

COMBO NAME: generic-m00-tool

The cards I currently have available is JCOP21/18K and a JCOP41/72K, but I haven't tried to download CAPs to them yet (I have some problems making the card reader work in Eclipse).

Lillesanda at 2007-7-12 19:48:49 >

Okay, that's interesting! I'll do some more testing both in the simulator and on the card once I get the cards up and running (have to get my hands on the keys first) and then report it.

Just a quick question - I need to get the keys to the card from the manufacturer, right?

Thanks alot for your help, it is greatly appreciated!

Lillesanda at 2007-7-12 19:48:49 >

Ok, I have engineering samples so that sounds great!

The first card (JCOP41/72K V2.2):

cm> /identify

=> 00 A4 04 00 09 A0 00 00 01 67 41 30 00 FF .........gA0..

(28637 usec)

<= 19 13 01 27 00 00 00 00 50 48 36 32 30 42 01 03...'....PH620B..

02 6B 93 6A 82 .k.j.

Status: File not found

FABKEY ID:0x19

PATCH ID:0x13

TARGET ID:0x01 (smartmx)

MASK ID:0x27 (39)

CUSTOM MASK: 00000000

MASK NAME:PH620B

FUSE STATE: fused

ROM INFO:026B93

COMBO NAME: smartmx-m27.19.13-PH620B

The other (PHILIPS JCOP21/18K):

cm> /identify

=> 00 A4 04 00 09 A0 00 00 01 67 41 30 00 FF .........gA0..

(61166 usec)

<= F2 04 01 24 4B 4C 38 33 50 48 35 32 32 44 01 03...$KL83PH522D..

FE 90 F2 6A 82 ...j.

Status: File not found

FABKEY ID:0xF2

PATCH ID:0x04

TARGET ID:0x01 (smartmx)

MASK ID:0x24 (36)

CUSTOM MASK: 4B4C3833

MASK NAME:PH522D

FUSE STATE: fused

ROM INFO:FE90F2

COMBO NAME: smartmx-m24.F2.04.4B4C3833-PH522D

Lillesanda at 2007-7-12 19:48:49 >

The fact that the IDENTIFY command works is not an indication that you have a JCOP engineering sample. All JCOP products support it (>= v2.2).

Try to authenticate with the default CM keys (0x404142..4F). To do this, open in JCOP Tools the JCOP Debug perspective, connect to a reader (JCOP Shell view, on top the button 'Connect to terminal' --> choose the connected reader), and press in the JCOP Shell view the 'Reset, select, and authenticate to the CardManager' button. If this works, you have the default CM keys.

lexdabeara at 2007-7-12 19:48:49 >

I have a mask39 card here. You're right, AES is switched off, but ECC works. Now with the mask36 card I have a different fabkey, but a CD036 (dual interface, 36k EEPROM) and AES is switched off as well.

So we can summarize that only JCOP41/72 v2.2 (mask36) and JCOP21/72 v2.2 (mask36) have AES enabled.

lexdabeara at 2007-7-12 19:48:49 >

I just checked, and one of my cards (the Philips JCOP21 18K) is supposed to support AES (according to http://www.usasmartcard.com/component/page,shop.browse/category_id,20/option,com_virtuemart/Itemid,26/index.php?page=shop.browse&category_id=20&option=com_virtuemart&Itemid=26&vmcchk=1).

However, using the following code I get a 0x6A80 (Wrong data) when installing the applet. Is this an error on the Smart Card USA webpage or is there some bug in my code? I've tried debugging it, but I can't see that the error is anything else than the line building the key.

import javacard.framework.APDU;

import javacard.framework.Applet;

import javacard.framework.ISO7816;

import javacard.framework.ISOException;

import javacardx.crypto.Cipher;

import javacard.framework.OwnerPIN;

import javacard.security.KeyBuilder;

import javacard.framework.Util;

import javacard.security.AESKey;

import javacard.security.CryptoException;

import javacard.framework.JCSystem;

public class AESApplet extends Applet {

/* Constant and variable definitions */

//CLAss definition

private final static byte AESApplet_CLA = (byte)0xB0;

//INStructions

// Encrypt data

private final static byte ENCRYPT_DATA = 0x01;

// Decrypt data

private final static byte DECRYPT_DATA = 0x02;

// Set PIN for administrator access

private final static byte CHK_PIN = 0x03;

// Return key in use (should be very protected indeed - preferrably even removed before final version :-))

private final static byte GET_KEY = 0x04;

// Set key

private final static byte SET_KEY = 0x05;

//Custom Exceptions

// Unauthorized user attempts to perform operation that requires authorization

private final static short USER_NOT_AUTHORIZED = 0x6601;

// Wrong PIN given

private final static short ERRORNOUS_PIN = 0x6602;

// Maximum number of PIN attempts performed. Should result in a locking of the card or the admin privileges.

private final static short MAX_PIN_ATTEMPTS_REACHED = 0x6603;

// Function disabled

private final static short FUNCTION_DISABLED = 0x6303;

// Key submitted has wrong length

private final static short INVALID_KEY_LENGTH = 0x6701;

// Unsupported algorithm

private final static short ALGORITHM_NOT_SUPPORTED = 0x6604;

//Constants

// Maximum number of guesses at the PIN (should be relatively low for this key, as all security is compromized if the key is)

private final static byte MAX_PIN_ATTEMPTS = 0x01;

// Maxmimum length of the PIN

private final static byte MAX_PIN_LENGTH = 0x06;

// Offset to PIN in install message. TODO: Depending on the format of the INSTALL APDU used, this might very well be a source of errors.

private final static short INIT_PIN_OFFSET = 9;

//Set default key to use untill a new one is set.

private final static byte[] tempKey = {(byte) 0xAB, (byte) 0xCD, (byte) 0xEE, (byte) 0x0E, (byte) 0x12, (byte) 0x35, (byte) 0x87, (byte) 0xFA,

(byte) 0xCC, (byte) 0xA1, (byte) 0x6F, (byte) 0xE7, (byte) 0xAB, (byte) 0xCD, (byte) 0xEE, (byte) 0x0E };

//Instance variable declaration

// Administrator PIN

OwnerPIN adminPIN;

// Cipher to be used

Cipher cipher;

// Reference to the key in use

AESKey key;

/*

* Class constructor. Should only be called from install()

*/

private AESApplet(byte[] bArray, short bOffset, byte bLength){

// Instanciate PIN

adminPIN = new OwnerPIN(MAX_PIN_ATTEMPTS, MAX_PIN_LENGTH);

// Set PIN from installation parameters

adminPIN.update(bArray, (byte)(bOffset+INIT_PIN_OFFSET), (byte)(bLength-INIT_PIN_OFFSET));

// Instanciate the cipher. For now, assume AES.

cipher = Cipher.getInstance(javacardx.crypto.Cipher.ALG_AES_BLOCK_128_CBC_NOPAD, false);

// Generate key

key = (AESKey) KeyBuilder.buildKey(KeyBuilder.TYPE_AES, KeyBuilder.LENGTH_AES_128, false);

// Set key value.

//key.setKey(tempKey,(short)0);

// Register the applet in the JCRE.

register();

}

public static void install(byte[] bArray, short bOffset, byte bLength) {

// Create the object, which will later do the registration

new AESApplet(bArray, bOffset, bLength);

}

}

PS: There is more code in the applet, but for convenience reasons I omitted the processing (as the crash occurs during install, thus either in install or in the constructor.

Message was edited by:

Lillesand

Forgot to include the URL reference

Lillesanda at 2007-7-21 22:30:11 >

As of now I do not, except for the very simple description at http://www.usasmartcard.com/component/page,shop.browse/category_id,20/option,com_virtuemart/Itemid,26/index.php?page=shop.browse&category_id=20&option=com_virtuemart&Itemid=26&vmcchk=1. Of course, that page states that these cards does NOT support AES. Is this a JCOP thing or a card vendor/manufacturer implementation thing? Are the cards you are using engineering samples? If so, could you tell me where you ordered them? I'm very interested in getting a card with AES, ECC and 3DES-support for my current project :-).

I must admit, at the current point I am confused as to how to check and make sure that a given card supports some given functionality (as the JCOP 21 V2.2/18K cards I have according to the vendor are supposed to support AES, but seemingly doesn't). Also, when I try to use unsupported algorithms, shouldn't the implementation ideally throw some ALGORITHM_NOT_SUPPORTED error or something instead of just WRONG_DATA?

Lastly, is ECC encryption/decryption really not implemented in JavaCard? As far as I have been able to figure out, only signature is supported. I am considering (though doubtful about) implementing it manually in software. I have serious concerns over both the practicality of this in terms of security and performance - and as to whether or not I will actually be able to do this. Does anyone have any input on this?

Lillesanda at 2007-7-21 22:30:11 >

Once again, thank you so much for your response, lexdabear.

Unfortunately I'm working on a relatively small project, where the anticipated order will only be in the magnitude of some hundred cards, so I assume tailor made cards will be too expensive.

My cards supports ECC, but only for signatures. And, as far as I am able to figure out, this is the case with every card following the Java Card specification, as even the JavaCard 2.2.2 API does not specify ECC as an algorithm in it's Cipher-class. To me this seems very strange as ECC would easily be preferable over RSA for smart cards (because of key length and performance)...

Lillesanda at 2007-7-21 22:30:11 >

Sorry for kicking this dead horse once more, but I've been thinking about one thing for some time. About the (lack of) AES support on my cards, I wish to implement it as optional functionality in case we get cards with the support in place later. With that in mind, I choose between 3DES and AES as an installation parameter and try to catch CryptoException.ALGORITHM_NOT_SUPPORTED upon getting the Cipher instance:

try{

symmetricCipher = Cipher.getInstance(Cipher.ALG_DES_ECB_NOPAD, false);

}catch(CryptoException e){

parseCryptoException(e);

}

But strangely, the exception is not thrown untill I try to set the key:

try{

keys[buf[ISO7816.OFFSET_P1]] = (AESKey) KeyBuilder.buildKey(KeyBuilder.TYPE_AES, (short) ((buf[ISO7816.OFFSET_P2] & 0x00ff)*8), false);

}catch(CryptoException e){

// Algorithm or key size not supported, throw general cryptoexception

ISOException.throwIt(StatusWords.SW_CRYPTO_ERROR);

}

(buf[ISO7816.OFFSET_P2] contains the key length in bytes, 16 bytes = 128 bits).

Lillesanda at 2007-7-21 22:30:11 >

The applet is actually part of a bigger system which also includes an XML file describing the contents of the card. In addition, one set of cards (meaning cards with similar or identical config) will usually be used in one context and the algorithm in use will be implicit for that context.

The JavaCard API states the following for Cipher.getInstance():

Throws:

CryptoException - with the following reason codes:

* CryptoException.NO_SUCH_ALGORITHM if the requested algorithm is not supported or shared access mode is not supported.

This leads me to think that there MIGHT be something wrong with the key I try to input, but I find it highly unlikely that any card would support AES with 192/256 bit key, but not 128...

Hopefully I will get my hands on a card with definite AES support sometime soon so I can test this fully (if Oberthur-sc could just check their mail...).

Lillesanda at 2007-7-21 22:30:11 >

I don't know what I'm doing wrong, but I'm getting the silent treatment from most SC manufacturers upon contacting them... I should probably just give them a call instead of mailing. Will have to get a phone installed in my office, then!

How are your experiences with getting answers from NXP and other manufacturers/vendors?

Lillesanda at 2007-7-21 22:30:11 >