18.1 Card Slots in the Emulator

Real SATSA devices are likely to have one or more slots that house smart cards. Applications that use SATSA to communicate with smart cards must specify a slot and a card application.

The Oracle Java ME SDK emulator is not an external device and, therefore, does not have physical slots for smart cards. Instead, it communicates with a smart card application using a socket protocol. The other end of the socket might be a smart card simulator or it might be a proxy that talks with real smart card hardware.

The Oracle Java ME SDK emulator includes two simulated smart card slots. Each slot has an associated socket that represents one end of the protocol that is used to communicate with smart card applications.

The default card emulator host name is localhost, and the default ports are 9025 for slot 0 and 9026 for slot 1. These port defaults are a property of the device. To change the defaults in the user interface, right click on the device in the Device Selector, and select Properties. By default the Properties window is docked on the upper right of the Java ME SDK interface.

You can also change the port values in the device's property file found at:

18.2 Adjusting Access Control

Access control permissions and PIN properties can be specified in text files. When the first APDU or Java Card RMI connection is established, the implementation reads the ACL and PIN data from the acl_slot-number in the workdir\devicename\appdb directory. For example, an access control file for slot 0 might be:

username\javame-sdk\3.3\work\devicename\appdb\acl_0

If the file is absent or contains errors, the access control verification for this slot is disabled.

The file can contain information about PIN properties and application permissions.

18.2.1 Specifying PIN Properties

PIN properties are represented by a pin_data record in the access control file.

The acf record is an Access Control File. The AID after acf identifies the application. A missing AID indicates that the entry applies to all applications. The acf record can contain ace records. If there are no ace records, access to an application is restricted by this acf.

The ace record is an Access Control Entry. It can contain root, apdu, jcrmi, pin_apdu, and pin_jcrmi records.

The root record contains one CA name. If the MIDlet suite was authorized using a certificate issued by this CA, this ace grants access to this MIDlet. A missing root field indicates that the ace applies to all identified parties. One principal is described by one line. This line must contain only the word root and the principal name, for example:

root CN=thehost;OU=JCT;O=dummy CA;L=Santa Clara;ST=CA;C=US

The apdu or jcrmi record describes an APDU or Java Card RMI permission. A missing permission record indicates that all operations are allowed.

An APDU permission contains one or more sequences of eight hexadecimal values, separated by blanks. The first four bytes describe the APDU command and the other four bytes are the mask, for example:

apdu {
0 20 0 82 0 20 0 82
80 20 0 0 ff ff 0 0
}

The Java Card RMI permission contains information about the hash modifier (optional), class list, and method list (optional). If the list of methods is empty, an application is allowed to invoke all the remote methods of interfaces in the list of classes, for example:

Right-click on the project, click Run As > Run Configurations. The Run Configurations window opens. Select the project JAD file on the left. On the right, switch to the Emulation tab where you can set the SDK/Device/Security domain.

Start the instance(s) of cref from the command line.

Run the project.

Right-click the project, click Properties and then click the Running category. Enable Regular execution and check Specify the Security Domain. Select maximum from the list.

Start up two instances of cref, one for each simulated card slot (assuming the current directory is the SDK installation directory):