2 May 1999


Date: Sat, 01 May 1999 17:19:37 -0700
From: "J. Orlin Grabbe" <kalliste@aci.net>
To: "cryptography@c2.net" <cryptography@c2.net>
Subject: Triple-DES in the Schlumberger java card

A javacard created by Schlumberger (the "Cyberflex
Access Card") both implements cryptographic functions
(RSA, triple-DES) and allows you to download your
own programs to the card.  Moreover, you can reuse
the EEPROM space by deleting a program and
downloading a different one into the same space.

Here I will comment on Schlumberger's implementation
of the javacard specification with respect to triple-DES
(3DES). Schlumberger has a sample java program showing
how to do 3DES on the card posted at their Austin web site
for anyone to download (http://www.cyberflex.slb.com).

(This program will not run without the encryption engine
on the Access Card.  Schlumberger will only send
encryption-enabled smart cards to U.S. addresses.)

There are some problems with the 3DES implementation.

I will begin by explaining some of the differences
between ordinary java and javacard java, as this will
also highlight some features that are specific to
Schlumberger's  implementation of the javacard
specification.

Programs for the javacard are simply written in java.
But because of the resource constraints on a smart card
(memory and processing power), some of the features
of java cannot be used, however.  These include
32 and 64-bit integers, floats and doubles, unicode
characters, threads.  There is no dynamic class loading
and no garbage collection.

Since there is no dynamic class loading, the java virtual
machine can be (and is) split up into two parts.  The
first of these is used as a preprocessor to further process
the java byte code before downloading onto the card.

Schlumberger's preprocessor is call "mksolo32.exe".
So suppose you write a java program des3.java.  You
then compile this with the java compiler in the ordinary
fashion to des3.class.  Next, you compile des3.class with
mksolo32.exe to create a file called des3.bin.

Note that in the javacard documentation the extention of
compiled class programs is ".cap" (for compiled applet)
not ".bin".  But Schlumberger calls its compiled class
programs "cardlets" instead of "applets", and the
change in name seems justified, because in the
Access Card you can write java programs that use the
main() method, as well as those that extend the
Applet class.

After compiling des3.class to des3.bin, you are ready
to download des3.bin onto the card.  Schlumberger
provides a software development kit for downloading
and managing cardlets.  The kit also comes with a
cardreader-the Lintronic 210, which does not need
a separate power supply, because it draws power
from the keyboard port. (The kit also contains an
APDU manager, for sending byte instructions to
the card, and receiving and displaying byte output.
Alternatively, you can use your own card terminal
implementation.)

To download the des3.bin cardlet, you only need to
assign it a filename and sign it with a verification
key corresponding to the cardlet verification key
which is already stored on the Access Card.
The Access Card will authenticate the cardlet before
allowing it to be download into EEPROM. (This is
in addition to the requirement to authenticate yourself
to the card through one of the card's authentication
keys, which shows you have permission to perform
this type of activity.)

Once the program (des3.bin) has been downloaded
on the smart card, you create an "instance" of the
program, which includes an allotment of memory
space for the data container needed by the program.
You can create multiple instances of the same
program

The program is accessed by sending it bytes (APDUs)
in five-byte instruction sets, along with any data.
These are usually labeled {CLA, INS, P1, P2, P3,
data}.  P3 is the length of the data.  CLA is the
"class" byte, while INS is the "instruction" byte.
P1 and P2 are there to be used as switches (much
like CLA and INS, except that CLA and INS must be
specifically declared).

The 3DES program listed at Schlumberger's site is
called CryptoTest.java.  The following group of
APDUs does a triple-DES ECB encryption on the hex
string "0102030405060708": {03,50,00,00,08,
0102030405060708}.  The output from the card should
be "01B45F3A1C9C703E".  Cross-checking with other
3DES programs shows this is the correct sequence
of encrypted bytes.

However, the CryptoTest program simply locks on
the card that came with my development kit.

Inspection of the code shows that the following
line under the RunTest5() class must the changed
from

des3key.setKey(key3, (short)0);

to

des3key.setKey(key3, (short)0, (short)0, (short)16);

This part of the program then runs fine.  Similar
changes must be made in RunTest1 (a DES encryption),
RunTest2 (another DES ECB encryption-decryption),
RunTest6 (a MAC with 3DES), RunTest7 (a MAC with
DES), and RunTest8 (3DES on a 24-byte message to
illustrate cipher-block chaining).

With this change, Tests 1-5 will run correctly.
However, Tests 6-8 still will not work.  These
three latter tests use cipher-block chaining, so
as you might expect, there is a problem with
the initialization vector (ICV()).

To get these three tests to work, you must
comment out the following lines which call
the procedure setICV():

des3key.setICV(ICV3, (short)0);

and

deskey.setICV(ICV, (short)0);

Add your own lines to set the initialization
vectors, and these three tests will *encrypt*
properly.  However, the *decryption* does not
work properly because the 3DES program
implemented on the card does not correctly
keep track of the ICV (or ICV3). What is going
on in Schlumberger's internal 3DES program is
unclear, but what is clear is that parts are
incorrectly implemented, and hence all
CBC implementations are suspect.

There are ways to get around this.  In particular,
since their 3DES program simply relies on their
DES program, you can write an download your own
3DES program.

Schlumberger says they have now fixed their
3DES program and it works properly on
Cyberflex Access Cards shipped after the
end of March 1999.  Maybe.  Maybe not.  I
will be checking this out.

Orlin Grabbe

http://www.aci.net/kalliste/homepage.html