Java Card 3.0.5 released

Oracle released JC 3.0.5, including support for Java 7 and 8 and a new Eclipse development plugin. This is great news, but to my knowledge no card vendors currently sell smart cards that support Java Card 3.

Useful JCOP Tools site

yobi.be has a good wiki with tips and tricks how to use JCOP Tools simulator etc. in scripts.

Java Card programming: best practices

Read and remember. Very useful tips, especially about reducing memory consumption. A short summary of how the JCVM allocates memory is also given, including the amount of overhead per object.

Java Card 3 implementations

The Java Card 3 spec was released by Sun Microsystems (now Oracle) in 2008 but its adoption by vendors has been very slow. A list of currently available Java Card 3 implementations can be found here on OTN. For convenience, here is a shortlist of the vendors:

• CardLogix
• Giesecke&Devrient

Java Card simulator

jCardSim is a simulator for Java Card:

jCardSim is open-source library contains implementation of Java Card API, v.2.2.1: javacard.framework.* javacard.framework.security.* javacardx.crypto.*

Misc. STK source code

RuimTools has interesting tips about interfacing with smart cards from Java and useful STK source code.

BouncyCastle, ECC and JavaCard

Using BouncyCastle to create ECDSA-SHA1 signatures which should be verifiable on Java Card, I ran into a problem which - I would expect - is commonly encountered by developers but not documented. We don't want to use a different Java cryptoprovider or different COS, so a dirty workaround has to be found.

I would be happy to know if this helps someone or if I missed something obvious.

Background

The coefficient size for a curve is a function of bitlength:
coeffsize = (bitlen/8)+((bitlen%8>0)?1:0).
Further, an F_2m curve has bitlength non-divisible by 8, while a F_p curve has a bitlength divisible by 8 (exception is curve SECP521K1).

According IEEE X9.62, ECDSA-SHA1 signatures consist of a type byte, a header+data length byte, then 2 * (header length, coordinate length, coordinate data).
From the ECDSA algorithm and the NIST recommended curve parameters, the coordinate length is supposed to be equal to the coefficient size.

Problem

The BouncyCastle ECDSA implementation generates signatures over F_2m type curves which sometimes have coordinate length = coefficient size - 1, and F_p signatures which sometimes (usually for larger bitsizes) have coordinate length = coefficient size + 1.

For F_p this is clearly due to one byte being prefixed to the coordinate data when the first bit of the first byte is set, for indicating signedness (0x00 if positive, 0x01 if negative). See http://stackoverflow.com/questions/1571999/java-why-does-a-512-bit-rsa-keypairgenerator-return-65-byte-keys

For F_2m the cause is unclear but seems related.

Solution

Let the expected signature size be 2 + 2*(2 + 1 + coefficient size) for F_p, and 2 + 2*(2 + coefficient size) for F_2m.

Alternatively, we could use 2 + 2*(2+ coefficient size) for both F_2m and F_p, and let the coefficient size for F_p be increased by 1; then the original equation for the coefficient size for F_2m and F_p becomes coeffsize = (bitlen/8)+1 and the curve constant parameters (P/E, A, B, N) must be prefixed with one null byte.

Regardless of the choice of solution, Java Card requires fixed lengths for the signatures, so the signature co-ordinate data must be pre-padded with 0x00 to the correct coordinate length and the signature coordinate and header length must be updated.

Signature examples

1. SECT163K1 (F_2m):
   
   1. Correct:
      

      302e0215035e292715c109be43be9caec807bc66e66b2a312d0215038755036fb45b0ae8c512f1ae39257f1eb842b3fb
        ^^  ^^                                            ^^

   2. Needs padding:
      

      302d021501931b6052ba344228eb9ac8c58206d285fc4828b602141bdbd2ba860b3326e8487124acc074f41e0d7767
        ^^                                                ^^

      Padded and lengths updated:
      

      302e021501931b6052ba344228eb9ac8c58206d285fc4828b60215001bdbd2ba860b3326e8487124acc074f41e0d7767
        ^^                                                ^^^^

   Coefficient size: 21
   Coordinate size: 21
   Required signature size (Java Card): 48
2. SECP192K1 (F_p):
   
   1. Padded and lengths updated:
      

      3036021900a63c2597958e72bfcf203a26fe174e115ba0ad409c445b3d02190040ef96986e491e0aed7d03ba736cddf6fcafe0d42661563c
        ^^  ^^^^                                                  ^^^^

   Coefficient size: 24
   Coordinate size: 25
   Required signature size (Java Card): 56
   

Machine Readable Travel Documents

While hunting for info about file systems on Java Card I came across this very useful reference implementation of the ICAO MRTD standard by Radboud Uni. It demonstrates (among other things) how to wrap and unwrap SCP02 protected APDUs and how to chain object and byte arrays into a very rudimentary file system (see FileSystem.java).

Update on Java Card GDIs

For what it's worth, here are the most popular options currently available to Java Card developers:

• eclipse-jcde 0.1: Free plugin for Eclipse wrapping the Sun Java Card Development Kit. Use with Eclipse 3.5 (JDK1.5 or later) and JCDK 2.2.2 Classic , Java Card 2.2.2, GlobalPlatform 2.2 (including JC Export file 1.3). The GlobalPlatform API may also be useful for manually or programatically communicating with a smart card. If your target is Java Card 3.0, use Netbeans and JCDK3.0.1 instead.
  Note: a useful off-card interface for Java is Global Platform for Java SmartCardIO.
  
• Netbeans IDE 6.7: Free; use with Sun JCDK 3.0.1 Connected Edition.
• JCOP Tools 3.1.2: Free devkit from NXP (proprietary, requires an NDA). Use with Eclipse 3.3 (JDK1.4.2 or 1.5 only). Target OS is JCOP 2.2 (?). Includes libraries from GlobalPlatform 2.1.1, Java Card 2.2.1. Not all ECC functions (Java Card) are represented in the simulator.
  
• JCOP Tools 3.2.8: Latest version; free from NXP (proprietary, requires an NDA). Use with Eclipse 3.5 (JDK1.6). Target OS is JCOP 2.4.1 (supporting Java Card 2.2.2 and GlobalPlatform 2.1.1), and possibly JCOP 2.4.2 (Java Card 3.0, GlobalPlatform 2.2). Simulator includes most of the Java Card functionality.
• Giesecke&Devrient Sm@rtCafe Professional Toolkit 2.0: free demo. Supports Java Card 2.2.1 and GlobalPlatform 2.1.1; target OS is G&D Sm@rtCafe 3.x.

If there are more, please notify me.

Card Recognition Data

To get the GPShell open_sc command to work with an applet instance (not the Security Domain), we must ensure that the correct Secure Channel Protocol implementation number is specified.

This number can be retrieved from the Card Recognition Data TLV fields via the OpenPlatform get-data command on tag 0x66 (send APDU 80CA0066) after selecting the Card Manager. For example, with the Nokia 6131 NFC phone, the command returns:

66 4C
--73 4A
----06 07 2A864886FC6B 01
--60 0C
----06 0A 2A864886FC6B 02 02 01 01
--63 09
----06 07 2A864886FC6B 03
--64 0B
----06 09 2A864886FC6B 04 02 55
--65 0B
----06 09 2B8510864864020103
--66 0C
--06 0A 2B060104012A026E0102
9000

The response is formatted into TLV fields according to GP 2.1.1 Section F.2 or GP 2.2 Section H.2, "Structure of Card Recognition Data".

The field at tag 64 (offset 50 in the unformatted string) aka "application tag - GP OID 04" has scp=0x2 (SCP02), i=0x55=85 (scpimpl). Note that this is different from the default i=0x15!

The field at tag 60 aka "application tag - GP OID 02" specifies the GlobalPlatform version, namely GP2v2.1.1 (compare with value in given by ATR and OpenPlatform get-cplc command). This gives a clue as to the Java Card version that can be expected (2.2.1).

The GPShell command to open a secure channel (MAC and ENC) to an applet in the Secure Domain would then be (after selecting the applet):

open_sc -security 3 -keyind FF -keyver 0 -mac_key 404142434445464748494a4b4c4d4e4f -enc_key 404142434445464748494a4b4c4d4e4f -scpimpl 85 -scp 2

where "-scpimpl 85" specifies the decimal value of the SCP number.

Note: according to the GP spec. H.3, the GP select command on the Security Domain may return TLV values which - if present - override the Card Recognition Data described previously. What exactly this implies I still have to figure out ...


****
Update: I discovered that the COS on the IC in the Nokia is G&D SmartCafe Expert 3.1 which is indeed Java Card 2.2.1 compliant. See this post.

SCP02 sample applet

This thread on Sun JavaCard Forum has an excellent sample applet for anyone wanting to get started with SCP02. The nice thing about this applet is that you can encrypt and unencrypt APDUs (using the default keyset in this case), and can replay them against the applet to verify them.

Note that R-MAC and R-ENC are not supported by JCOP ...

Playing around with the PUT_KEY command in the sample applet (GP2.1.1 Specification 9.8, see also table 9-18), I can't get it work with my JCOP31 card from NXP - I always get "reference data not found" when trying to load a DES key. This happens even when using correct values for P1 on JCOP (0x01..0x6F according to this thread). Strangeness. Perhaps this only works when the APDU is sent directly to the SD (i.e. SD is selected) instead of accessing the SD via the applet.