Applying a Sharing Interface Object

In order for the server to return values of any types of sharing interfaces using a single interface, both methods have JCSystem.getAppletShareableInterfaceObject and an Applet.getShareableInterfaceObject- the type Shared is used to return the value – the base type for all objects of the sharing interface. Client

the applet must cast the returned SIO object to the appropriate type and store a reference to it in a variable of this type. For example, if in the “electronic wallet” applet it is necessary to bring SIO to the type of airmiles interface:

AirMilesInterface sio = (AirMilesInterface) JCSystem.getAppletShareableInterfaceObject(server_aid, parameter);

After the applet client has accepted the zy, it calls the methods of the sharing interface to access the services provided by the server. However, only the methods defined in the sharing interface are available to the client applet.
For example, in the above code snippet, even if the Spi variable actually points to the “aviamily” applet (the AirMilesInterface interface is implemented in the class of this applet), all instance fields and non-separable interface methods (such as process, selection and deselection methods) are protected by a firewall.
Let’s consider a possible implementation of the request of the “electronic wallet” applet to the “aviamily” applet to perform an operation to replenish the number of aviamiles.
com.smartbank package.wallet; import javacard.framework.*;
import com.fasttravel.airmiles.AirMilesInterface; the public class WalletApp extends the applet {
private short balance;
// this value is explicitly set in the applet or assigned
// when configuring the applet for a specific user
, the private byte[] air_miles_aid_bytes = SERVER_AID_BYTES;

// calling the processing method after receipt
// of the DEBIT APDU command
private invalid debit (short amount) {

if (balance < amount) ISOException.throwIt(SW_EXCEED_BALANCE);

balance update balance = (short) (balance amount);

// request to the server to update the airmail

private invalid request files (short sum) {

// getting help from a server object

HELP air_miles_aid = JCSystem.lookupAID(air_miles_aid_bytes,
(short)0, (byte)air_miles_aid_bytes.length);
if (air_miles_aid == null) Exception ISOException.throwIt(SW_AIR_MILES_APP_NOT_EXIST);
// sio request from the server
AirMilesInterface sio = (AirMilesInterface) (JCSystem.getAppletShareableInterfaceObject(air_miles_aid,
if ( sio == null ) ISOException.throwIt(SW_FAILED_TO_OBTAIN_SIO);
// request to the server to update the airmail
sio.Grant miles(amount);

If an error occurs, the applet can raise an ISOException exception by calling the static throwIt method (see the example of using the requestMiles method). The throwIt method raises an ISOException exception object owned by JCRE.”JCRE”.

Switching contexts in the process of sharing objects

JCRE, applet client and applet server are executed in different contexts. To ensure the possibility of sharing objects, it is necessary to organize context switching. To request access to SIO, the client applet calls the JCSystem.getAppletShareableInterfaceObject method. In this case , the internal mechanism of the method switches the context from client to JCRE . JCRE then calls the getShareableInterfaceObject server applet method. As a result of this call, the context switches again. The applet server context becomes the current one. During the return process, the context of the client applet is restored from both methods.
The client applet can make a request to execute the server applet service by calling one of the available interface methods of the requested SIO object. “Java card”. The current active context becomes the context of the applet server.
At this moment, the context of the server applet is active, so all its protected resources are available – instance fields, other methods, and even objects belonging to the context of the server applet. After returning from both methods, the context of the client applet is restored. The sequence of switching contexts in the process of sharing objects is shown in Figure 9.5.

Types of parameters and results of methods of the sharing interface

In the Java programming language, both method parameters and return values can have any primitive or reference type. But for the Java platform, passing a card of objects (including arrays) as parameters or return values of methods of the sharing interface is allowed only with some restrictions. For example, if the e-wallet applet passes one of its objects as a parameter when calling the grantMiles method, the firewall will not allow the aviamiles applet to access this object. Similarly, if the aviamily applet returns one of its objects, the firewall will prohibit the access of the electronic wallet applet to this object. Despite the fact that this behavior of the firewall can cause irritation, it provides reliable protection. After all, this is the main task of the firewall.
To avoid access conflicts, you need to use the following types of parameters and return values of the methods of the sharing interface:
· Primitive types – these data types are passed through the stack. Primitive-
The types supported by the Java Card platform are boolean, byte, short and int (optional).
· Static fields – Open static fields are accessible from any con-
text. However, if such static fields contain references to objects, access to them is protected by a firewall.
· Objects are entry points to JCRE – the public methods of these objects are accessible
from any context.
· Global arrays – accessible from any context. For example, an APDU buffer can be used for these purposes.

· SPI objects – methods of the sharing interface are accessible from any context. If the client returns the SIO object, the server can make a callback from its context to go to the client context and access certain services or data. However, the applet developer should avoid
unnecessary context switches (this may reduce performance), as well as nested switches (this may cause excessive stack usage).
In the next section, we will give examples of code for transferring objects or arrays that conforms to the principles of the firewall.

Client Applet authentication

In order to prevent unauthorized access of the client applet to the protected data, the server must identify the client before granting him access to the SPI and allowing the call of SPI methods.
To make a decision about allowing access to SIO, the server can check the HELP of the client applet that requests this access. For example, the aviamily applet can perform such a check in the getShareableInterfaceObject method.

the public class AirMilesApp extends the applet
implementing AirMilesInterface {

public shared getShareableInterfaceObject(AID client_aid,
byte parameter) {

// It is assumed that the length of the HELP in bytes is known
if (client_aid.equal to(wallet_app_aid_bytes, (short)0, (byte)(wallet_app_aid_bytes.length)) == false) returns null;
// verification of the access token for identification
// of the “electronic wallet” applet
if (parameter != SECRET) returns null;
// return SIO return (this);

The next time the sharing interface method is called, the server can check the rights of the client applet again. This precaution is necessary because the client applet that the Sio requested may violate the agreement and transfer the Sio to another applet that does not have the necessary authority. The server applet should provide such a scenario to prevent unauthorized access to confidential information. To determine the HELP of the calling applet, the server can call the JCSystem.getPreviousContextAID method.

You can add the following code to the Grant Miles method to authenticate the calling applet:

publicly available invalid grant miles (short amount) {

// get the caller of the applet help
HELP client_aid = JCSystem.getPreviousContextAID();

// Check: was this method really called
// by the “electronic wallet” applet
if (client_aid.equal to(wallet_app_aid_bytes, (short)0, (byte)(wallet_app_aid_bytes.length)) == false)

// that’s right, we update the number of air
miles = (short)(miles + amount);

The above code uses an authentication scheme that provides for checking the caller of the applet to prevent unauthorized access to data. But such a scheme may not be sufficient for applets that require an increased level of security. In this case, it is necessary to use additional authentication methods, such as the exchange of encrypted messages.
Below we will give an example of code that implements the “hail – recall” scheme (a strategy for identifying a user by checking the correctness of his reaction to an unpredictable system request). After calling the Grant Miles method, the Aviamily applet generates a random message and sends it to the electronic wallet applet. The “electronic wallet” applet encrypts the message and sends a response to the “aviamily” applet. The Aviamily applet checks the response, determines the authority of the electronic wallet applet and adds the requested number of miles to its balance.
First of all, to implement this scheme, two additional parameters must be added to the grantMiles method – an object for object authentication and a buffer for data exchange.

The public AirMilesInterface interface expands the possibilities of sharing {

public void grantMiles(AuthenticationInterface authObject,
byte buffer[], short volume);

To authenticate the “electronic wallet” applet, the “aviamily” applet calls the challenge method of the corresponding object. The buffer is used to exchange identification data.

public class AirMilesApp extends Applet
implements AirMilesInterface {

public void grantMiles(AuthenticationInterface authObject,
byte[] buffer, short amount) {

// generating random code and putting it in the buffer

// the client applet
// returns a response in the buffer

// checking the response
if (checkResponse(buffer) == false) ISOException.throwIt(SW_UNAUTHORIZED_CLIENT);
miles = (short)(miles + amount);

Note that the authentication object is created by the calling applet (the “electronic wallet” applet) and belongs to it. The firewall requires that exactly such an object be a SIO object:

public interface AuthenticationInterface extends Shareable {

public void challenge(byte[] buffer);

public class WalletApp extends Applet
implements AuthenticationInterface { public void challenge(byte[] buffer) {
// getting a response.
// both the request and the response are stored
// in the buffer

public void process(APDU apdu) {

if (getCommand(apdu) == DEBIT) debit(apdu);

private void debit(APDU apdu) {

short amount = getDebitAmount(apdu);

// balance update
balance = (short)(balance amount);

// request to the “air miles” applet to update the number of miles
requestMiles(apdu.GetBuffer(), amount);

private void requestMiles(byte[] buffer, short amount) {

// getting the AID object AID air_miles_aid =
(short)0, (byte)air_miles_aid_bytes.length);
// request for the SIO object from the aviamily applet
AirMilesInterface sio = (AirMilesInterface) (JCSystem.getAppletShareableInterfaceObject(air_miles_aid,

// request to the “air miles” applet to update the number of miles
sio.grantMiles(this, buffer, amount);

In this code example, the APDU buffer is used as a buffer for exchanging authentication data. The APDU buffer is a global array that can be accessed from any context1.

getPreviousContextAID method
In the process of sharing objects, the server can find out the AID of the calling applet using the JCSystem.getPreviousContextAID method :

public AID getPreviousContextAID()

This method returns an AID object that belongs to JCRE. This object is associated with an instance of the applet that was active during the last context switch. In the example of the implementation of the grantMiles method given above, at the moment when the “electronic wallet” applet calls the method of the sharing interface, contexts are switched. The getPreviousContextAID method returns the AID of the “electronic wallet” applet that was active before switching contexts.
Let’s now consider a more complex scenario, which is shown in Figure 9.6. Suppose that two instances of applets A and B have a common group context. If applet A calls a method of object b (which belongs to applet B), group context switching does not occur. This action is allowed regardless of whether the object is b SIO or not.
Now, when object b gets access to the SIO belonging to applet C, a context switch occurs. The active applet at the last context switch was applet B, so the getPreviousContextAID method will return the AID of applet B.

Even in this case, there are restrictions on the use of the APDU buffer for transmitting structured data. For example, the transmitted data may have a length or type that does not comply with the APDU buffer usage conventions. Difficulties in using the APDU buffer may arise for both the server and the client.

Sharing objects with applets A, B and C


In conclusion, we will briefly outline the algorithm for sharing objects by server and client applets.

  1. If applet server A wants to allow other applets to access its object, it must first define the SI sharing interface. This interface is an extension of the javacard interface.framework.Shareable. The methods defined in the SI sharing interface represent the services that applet A intends to make available to other applets.
  2. Then applet A defines a service provider class C, which is an implementation of the shared SI interface. The C class provides implementation of methods that are defined in the SI interface. Other methods and fields can also be defined in C, but they are protected by the applet firewall. Other applets only have access to methods that are defined in the SI interface.
  3. Applet A creates an instance of object O of class C. O belongs to applet A, and the firewall allows applet A access to fields and methods of O.
  4. If the client applet B wants to access the object O that belongs to applet A, it calls the JCSystem.getAppletShareableInterface method
    to request access to the shared interface object from applet A.
  5. JCRE searches its internal table for applet A. If this applet is found, JCRE calls the getShareableInterfaceObject method of applet A.
  6. Applet A receives a request and decides whether it can allow applet B to access object O. If a positive decision is made, applet A returns a reference to object O to applet B.
  7. Applet B receives a reference to an object from applet A, converts it to the SI type, then stores it as a reference to the SIO object. Despite the fact that SIO
    actually refers to the object O belonging to applet A, this variable

has type SI. Applet B only has access to the sharing interface methods defined in SI. The firewall prevents Applet B from accessing the rest of the fields and methods of O. Applet B can request services provided by applet A by calling one of the sharing interface methods defined in SIO.
Before providing the service, the sharing interface method can authenticate the client (B) to determine whether he is eligible for this service.

Smart cards are not only devices for secure data storage and processing. They can be used to confirm authorization, as well as as encryption modules. In this case, cryptographic functions in smart cards play a major role.
In this chapter, we will discuss the programming of cryptographic functions in Java Card applets. The chapter consists of four sections. First, we will offer the reader a brief introduction to cryptography, in which we will talk about many important concepts and algorithms. Then we will discuss and analyze the possibilities of using cryptography in smart card applications. In the third section, we will look at the cryptographic API supported by the Java Card platform. Finally, we will give examples in which the Java Card cryptographic programming interface is used to generate random numbers, to calculate and verify a message digest or digital signature, as well as to encrypt and decrypt data in applets.

Cryptography is the art and science of cryptography. Using cryptography methods, it is possible to organize the storage of confidential information and the exchange of secret messages. The subject of cryptography is the encryption and decryption of information. Cryptanalysis is the antipode of cryptography. This is the art and science of “hacking”, i.e. obtaining information from an encrypted message without first knowing the keys of the ciphers used. The term “cryptology” refers to a branch of mathematics that includes both cryptography and cryptanalysis.
Despite the fact that encryption by itself cannot guarantee secrecy, the use of cryptography methods in various systems and programs often brings tangible benefits. With the help of cryptography methods, of course, provided they are properly applied, the following
protection and security tasks can be solved:
· Restricting access to information guarantees its confidentiality. Persons without authority will not be able to read classified information.
· The integrity of the information guarantees its accuracy. This means that no one can correct the original data or replace it without your knowledge.
· Authentication allows you to confirm authenticity. You can make sure that the people you communicate with using electronic means of communication are exactly who they say they are.

In this section we will talk about the basic concepts of cryptography. This knowledge is necessary for the correct use of cryptographic APIs that are implemented on the Java Card platform. Readers who want to better understand the theory of cryptography can recommend the book “Applied Cryptography” by Bruce Schneier.

Encryption and decryption

The generally accepted method for protecting secret information is its encryption by the sender and decryption by the recipient. Initially, the message is an unencrypted text (sometimes this text is called open). Encryption is the process of changing a message, which is aimed at hiding its content. An encrypted message is called a cipherogram or cryptogram. Decryption is the reverse of encryption. After decryption, the ciphertext becomes the original plaintext again. The mathematical algorithm that is used to convert text is called a cipher. As a rule, there are two related algorithms: one for encryption and the other for decryption.