Java Card^TM technology provides a secure environment for applications that run on smart cards and allow the deployment of multiple applications on a single card. New applications can be added also after issuance to the end user.

Gemalto (U)SIM cards use the Java Card^TM technology to deploy STK (SIM Toolkit) applications or independent non telecom Java Card applets (e.g. for contact-less applications).

STK applets implement multiple services that are offered by the MNO (Mobile Network Operator). These applications are either developed by the operator itself, by Gemalto or by external Gemalto partners. These STK applets may be part of a complete end to end solution that involves OTA (secure over the air communication with a remote server).

Resources for Java Card can be found in the Sun Developer Network.

Developers who wish to integrate their applets in the Gemalto (U)SIM cards must implement the Gemalto Java Card^TM & STK Applet development guidelines.

Why using JAVA™ development environment?

Java™ is an object oriented programming language developed by Sun Microsystems. This language is designed to be platform independent.
The Java™ language offers the following core advantages:

• A standard programming language – anyone who knows how to write a Java™ program can write a smart program and load it onto a card.

• Secure environment – Java™ is well known as a secure programming language.  

• Multiple programs, or applets, on a card – the card architecture and the security features of Java™ language make it possible for multiple applets to reside safely on a card. The number of applets is only limited by the amount of space on the card.

• Full integration with mainstream Java™ IDEs – the card software integrates most Java™ integration development environments.

• All the benefits of object-oriented programming – programmers have the benefits of code reuse, design patterns, and superior structure.

• Platform independence – since Java™ smart card programs are portable across different chip architectures, applets cost less to develop and maintain.

Dynamic updates – you can develop and deploy applets incrementally, adding features as you go along. You can add or delete the applets on a card at any point of its life cycle.

Java Card™ security

The integrity and security of Java™ are widely recognized. The security management developed for smart cards is implemented by the JCVM. The following features provide program and data integrity and security from malicious programs:

• The Java Card™ language is provided by the class file verifier, which is made off-card, before code is downloaded into the card.

• JCRE security enforces firewalls to isolate applets, which prevents unauthorized access of objects created by one applet from being used by another.

• Java Card™ compilers provide extensive stringent error checking when the program is compiled.

For example: all references to methods and variables are checked to make sure that the objects are of the same type. The compiler also ensures that a program does not access any non-initialized variables.

•  All accesses to methods and instance variables in a Java Card™ class file are through access modifiers. These modifiers define a level of access control for each method. You can declare a method to be public (no limitations) protected (accessible by methods in the same subclass or package) or private (no access by other classes).  If no declaration is made, the default allows the method to be accessed by any class in the same package.

• Basic Java Card™ types and operations are well defined. All primitive types have a specific size and all operations are performed in a designated order.  

• Malicious programs cannot forge pointers to memory because there are no pointers that can be accessed by programmers or users.

• Additionally Java Card™ accesses variables only through references to them from the Java™ stack. Malicious programs are prevented from “snooping” around in the Java Card™ variable heap because the values of the local variables are unavailable after every method invocation. A method cannot access resources it shouldn’t.

Applet runtime environment

The Java Card™ technology defines a Java Card™ Runtime Environment (JCRE) that contains the full runtime environment to support the execution of Java Card™ program. The JCRE contains the Java Card Virtual Machine (JCVM) and provides classes and methods (API) to help developers create applets.
Java Card™ Virtual Machine
The Java Card™ Virtual Machine (JCVM) is a version of the Java™ Virtual Machine (JVM) adapted for smart cards. It controls access to all smart card resources, such as memory and I/O and allows applications to be securely loaded to the card post-issuance.
The JCVM executes the Java™ byte code subset on the smart card, ultimately providing the functions accessible from outside, such as signature, log-in and applications.

Java Card™ API

The available Application Programming Interface (API) classes allow developing applications and provide system services to those applications. These classes define the conventions by which a Java Card™ applet accesses the JCRE and native functions, including operating system functionality, memory access, and I/O operations. The APIs used by the card contains four packages:

• javacard.framework - this package contains the basics features needed to work with the Java Card™ card.
• java.lang - this package contains all the exceptions corresponding to a misusage of arrays, casts, and security. It is automatically imported by the compiler itself.

• javacard.security - this package contains a framework for the cryptography functions supported on the card.

• javacardx.crypto - this package contains a cipher class with encryption and decryption capabilities.

JCRE support services

The Java Card™ applets do not directly receive the incoming messages. These are first processed by the JCRE, which calls upon a method of the applet to process the APDU commands. The JCRE supports services dedicated to smart cards.

• It allows applet isolation thanks to applet firewall ensuring that no other applet may use, access or modify the contents of an object owned by another applet, except as defined by the applet itself.

• It includes a way to share objects between applet object sharing. An applet may permit restricted or unrestricted sharing of any of its objects. In another terms, any applet cannot access the fields of or objects of another applets implemented. There is an exception when the other applet explicitly provides interface for access.

• It includes a way to manage atomic transactions. A transaction is a logical set of updates of a persistent object. The transaction is atomic when all the fields are updated or none are. The mechanism of an atomic transaction allows protection against events such as power loss in the middle of the transaction, and against program errors that may cause data corruption. If the transaction cannot complete, the card data are restored to their pre-transaction states, at the exception of the content of the transient objects.