SecureRMIPurse Sample

This sample is only included in bundles with cryptography extensions.

The SecureRMIPurse sample is a version of RMIPurse with an added security service. SecureRMIPurse uses the card applet SecurePurseApplet, the Purse interface and its implementation SecurePurseImpl, and a definition of the security service MySecurityService. These classes reside in the package com.sun.javacard.samples.SecureRMIDemo. The sample also uses the client-side program SecurePurseClient and the specialized card accessor CustomCardAccessor. These classes reside in the package com.sun.javacard.clientsamples.SecurePurseClient.

The Purse interface is similar to the interface used in the non-secure case, however, there is an extra constant: REQUEST_DENIED. This constant is used to report situations where the client tries to invoke a method that it is not allowed to access.

The MySecurityService class is a security service that is responsible for ensuring data integrity by verifying checksums on incoming commands and attaching checksums to outgoing commands. The program also requires the client to authenticate itself as the principal application provider or principal cardholder by sending a two-byte PIN.

The implementation of Purse, SecurePurseImpl, is similar to the non-secure case, however, at the beginning of each method call, a call is made to the security service that ensures that the business rules are satisfied and that the data is not corrupted.

The applet, SecurePurseApplet, is similar to the non-secure case, except that it creates and registers an instance of MySecurityService.

The client-side program, SecurePurseClient, is similar to the non-secure case, except that instead of a generic card accessor, it uses its own implementation, CustomCardAccessor, to perform additional preprocessing and postprocessing of data and to support the additional command, authenticateUser.

SecurePurseClient also requires verification of the user. After the applet is inserted, a PIN must be given to the card-side applet by calling authenticateUser on CustomCardAccessor.

When authenticateUser is called, CustomCardAccessor prepares and sends the command described in Table 4-2.

Table 4-2 Authenticate User Command

CLA_AUTH INS_AUTH P1 field P2 field LC field PIN (byte 1) PIN (byte 2)

0x80

0x39

0

0

2

xx

xx

On the card side, MySecurityService processes the command. If the PIN is correct, then the appropriate flags are set in the security service and a confirmation response is returned to the client. Once authentication is passed, the client program receives the balance, credits the account, and again receives the balance. The program demonstrates error handling when the client attempts to debit a number of units from the account. This causes the program to throw a UserException with the code REQUEST_DENIED.

As with RMIDemo, the client part of the SecureRMIDemo can be run without parameters or with the -i parameter:

  • If the sample is run without parameters, remote references are identified using the class name of the remote object.

  • If the sample is run with the -i parameter, remote references are identified using the list of remote interfaces implemented by the remote object.

Follow one of these sets of instructions to run this sample: