Security and Trust Services APIs for Java(TM) 2, Micro Edition
Reference Implementation

Introduction

• SATSA-APDU Communication - Defines an API to support communication with smart card applications using the Application Protocol Data Unit (APDU) protocol.

• SATSA-JCRMI Communication - Defines a Java Card(TM) Remote Method Invocation (JCRMI) client API that allows a Java(TM) 2 Platform, Micro Edition (J2ME(TM)) application to invoke a method of a remote Java Card object. Also includes the JCRMI Stub Compiler.

• SATSA-PKI Signature Service - Defines an API to support application-level digital signature signing (but not verification) and basic user credential management, using the Public Key Infrastructure (PKI) protocol.

• SATSA-CRYPTO Cryptographic Interfaces - Defines a subset of the Java(TM) 2, Standard Edition (J2SE(TM)) cryptography API. It provides basic cryptographic operations to support message digest, signature verification, encryption, and decryption.

Software Platform

The SATSA 1.0 Reference Implementation is based upon the MIDP 2.0 Reference Implementation code base. The default platform for the SATSA 1.0 Reference Implementation is Windows 2000/x86.

The SATSA 1.0 Reference Implementation requires installation of the Java Card 2.2.1 Reference Implementation. For more information about downloading and installing the Java Card RI, see Chapter 2, "Installation," in the Java Card Platform, Version 2.2.1, Development Kit User's Guide, for the Binary Release with Cryptography Extensions manual. This document is available in the Java Card Platform Development Kit 2.2.1 Reference Implementation distribution.

Installing the SATSA 1.0 Reference Implementation

Instructions for installing the SATSA 1.0 Reference Implementation can be found in the Security and Trust Services APIs for Java 2 Platform, Micro Edition: Installation Guide.

Useful Information

The SATSA 1.0 Reference Implementation supports the following:

• The PKI Card Application AID is:
  0xA0 0x0 0x0 0x0 0x63 0x50 0x4B 0x43 0x53 0x2D 0x31 0x35
• The PKI Security Element ID is: WIM 1.01 SATSA RI
• Security element policy selecting a key already associated with a user certificate.
• Opaque signatures.
• Using the certificate instead of the certificate URI.
• CSR generation authorization through PIN entry (required).
• Store credential authorization through PIN entry (required).
  Card application (WIM) requires PIN-G for data modification.
• Remove credential authorization through PIN entry (required).
  Card application (WIM) requires PIN-G for data modification.
• Non-repudiation signature authorization through PIN entry (required).
• Authentication signature authorization (no PIN required).
• PIN-related functionality in SATSA-APDU and SATSA-JCRMI optional implementations.
• Two slots to attach a security element to the device.
• Three logical channels for the Reference Implementation security element.
• The int data type in the SATSA-JCRMI security element.
• TCP/IP as the transport protocol.
• The RSA algorithm in the SATSA-CRYPTO KeyFactory implementation.
• The MD2, MD5, and SHA-1 algorithms in the SATSA-CRYPTO MessageDigest implementation.
• The MD5withRSA and SHA1withRSA algorithms in the SATSA-CRYPTO Signature implementation.
• The DES (8 byte, 64 bit), the DESede (24 bytes, 192 bit), and the AES (16 bytes, 128 bit) keys in the SATSA-CRYPTO Cipher implementation. By default ECB is the mode and there is no padding. For the DES, DESede, and AES ciphers, CBC mode and PKCS5Padding are also available.
• The security element publishing its access control requirements in an Access Control File.

The WIM Application

• PIN 1 - a general purpose PIN that protects WIM data from modification and authentication keys. The value is 1234.
• Non-repudiation Key 1 PIN - protects the first non-repudiation key. The value is 2345.
• Non-repudiation Key 2 PIN - protects the second non-repudiation key. The value is 3456.

Using the JCRMI Stub Compiler

java -jar jcrmic.jar options interface_names

where options includes:

• -classpath path -- Specify where to find input classes.
• -d directory -- Specify where to place generated files.
• -compile -- Compile generated source files.
• -keep -- Do not delete generated source files after compilation.

If the -compile command line option is used, the program invokes the Java(TM) language compiler to compile generated source files. After compilation, it deletes the source files. To keep generated source files, use the -keep option. The program uses the path to the Java language compiler specified in the system property JAVAC_PATH. For example:

java.exe -DJAVAC_PATH=c:/jdk/bin/javac.exe -jar jcrmic.jar -compile
-classpath c:/midp/classes;c:/tmp/example com.sun.javacard.samples.RMIDemo.Purse

Running the Java Card C Reference Implementation (CRef)

For details on how to write, install, and initialize applets on a Java Card, see the Java Card User's Guide (included in the Java Card 2.2.1 Reference Implementation).

To run CRef with your own applets installed and initialized:

1. Run CRef setting the option to store the EEPROM image in a file on the hard disk.
   cref.exe -o EEImage

2. Run the script that contains applet information and the commands to initialize your Java Card applets in CRef. This is done using APDUTool (bundled with the Java Card 2.2.1 Development Kit). This installs the applets and initializes them in CRef's EEPROM. When this is done, CRef will terminate.

3. Run CRef and restore from the saved EEPROM image.
   cref.exe -i EEPROM

At this point, MIDlets running in the MIDP emulator should be able to communicate with Java Card applications running in CRef. To start the MIDP emulator, type:

$MIDP_HOME/bin/midp

CRef uses sockets to communicate with the APDUTool and the MIDP emulator. In order to run CRef on a port of your choice, use the following command (the default port is 9025):

cref.exe -p port_number

To get help with other CRef command line options, type:

cref.exe -h