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