0% found this document useful (0 votes)
29 views3 pages

Overview of Java Card Technology

Java Card allows Java applications to run securely on smart cards and similar small devices. It aims for portability and security - an applet can run on different cards, and security features isolate apps and encrypt data. Java Card uses a subset of Java tailored for resource-constrained devices, with optimizations like smaller bytecode and persistence by default.

Uploaded by

deepu
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views3 pages

Overview of Java Card Technology

Java Card allows Java applications to run securely on smart cards and similar small devices. It aims for portability and security - an applet can run on different cards, and security features isolate apps and encrypt data. Java Card uses a subset of Java tailored for resource-constrained devices, with optimizations like smaller bytecode and persistence by default.

Uploaded by

deepu
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd

JAVA CARD

Java Card refers to a technology that allows Java-based applications (applets) to be run securely


on smart cards and similar small memory footprint devices. Java Card is the tiniest of Java
targeted for embedded devices. Java Card gives the user ability to program the device and make
them application specific. It is widely used in SIM cards (used in GSM mobile phones)
and ATM cards.  The first Java Card was introduced in 1996 by Schlumberger's card division
which later merged with Gem plus to form Gem alto. Java Card products are based on the Java
Card Platform specifications developed by Sun Microsystems, a subsidiary of Oracle Corporation.
Many Java card products also rely on the Global Platform specifications for the secure
management of applications on the card (download, installation, personalization, deletion).

The main design goals of the Java Card technology are portability and security.

Portability
Java Card aims at defining a standard smart card computing environment allowing the same Java
Card applet to run on different smart cards, much like a Java applet runs on different computers.
As in Java, this is accomplished using the combination of a virtual machine (the Java Card Virtual
Machine), and a well-defined runtime library, which largely abstracts the applet from differences
between smart cards. Portability remains mitigated by issues of memory size, performance, and
runtime support (e.g. for communication protocols or cryptographic algorithm)

Security
Java Card technology was originally developed for the purpose of securing sensitive information
stored on smart cards. Security is determined by various aspects of this technology:

 Data encapsulation. Data is stored within the application, and Java Card applications
are executed in an isolated environment (the Java Card VM), separate from the
underlyingoperating system and hardware.
 Applet Firewall. Unlike other Java VMs, a Java Card VM usually manages several
applications, each one controlling sensitive data. Different applications are therefore
separated from each other by an applet firewall which restricts and checks access of data
elements of one applet to another.
 Cryptography. Commonly used encryption algorithms like DES, Triple
DES, AES, RSA (including elliptic curve cryptography) are supported. Other cryptographic
services like signing, key generation and key exchange are also supported.
 [Link] applet is a state machine which processes only incoming command
requests and responds by sending data or response status words back to the interface
device.

Java Card vs. Java


Language

At the language level, Java Card is a precise subset of Java: all language constructs of Java
Card exist in Java and behave identically. This goes to the point that as part of a standard build
cycle, a Java Card card program is compiled into a Java class file by a Java compiler, without any
special option (the class file is post-processed by tools specific to the Java Card platform).
However, many Java language features are not supported by Java Card (in particular types char,
double, float and long; the transient qualifier; enums; arrays of more than one dimension;
finalization; object cloning; threads); and some common features are a runtime option missing in
many actual smart cards (in particular type int, which is the default type of a Java expression;
and garbage collection of objects).

Bytecode

Java Card bytecode run by the Java Card Virtual Machine is a functional subset of Java [Java 2 -
Standard Edition] bytecode run by a Java Virtual Machine, but uses a different encoding
optimized for size. A Java Card applet thus typically uses less bytecode than the hypothetical
Java applet obtained by compiling the same Java source code. This conserves memory, a
necessity in resource constrained devices like smart cards. As a design tradeoff, there is no
support for some Java language features (as mentioned above), and size limitations. Techniques
exist for overcoming the size limitations, such as dividing the application's code into packages
below the 64 KiB limit.

Library and runtime

Standard Java Card class library and runtime support differs a lot from that in Java, and the
common subset is minimal. For example, the Java Security Manager class is not supported in
Java Card, where security policies are implemented by the Java Card Virtual Machine; and
transients (non-persistent, fast RAM variables that can be class members) are supported via a
Java Card class library, while they have native language support in Java.

Specific features

The Java Card runtime and virtual machine also support features that are specific to the Java
Card platform:
 Persistence. With Java Card, objects are by default stored in persistent memory (RAM is
very scarce on smart cards, and it is only used for temporary or security-sensitive objects).
The runtime environment as well as the bytecode has therefore been adapted to manage
persistent objects.
 Atomicity. As smart cards are externally powered and rely on persistent memory,
persistent updates must be atomic. The individual write operations performed by individual
bytecode instructions and API methods are therefore guaranteed atomic, and the Java Card
Runtime includes a limited transaction mechanism.
 Applet isolation. The Java Card firewall is a mechanism that isolates the different
applets present on a card from each other. It also includes a sharing mechanism that allows
an applet to explicitly make an object available to other applets.

Development

Coding techniques used in a practical Java Card program differ significantly from that used in a
Java program. Still, that Java Card uses a precise subset of the Java language speeds up the
learning curve, and enables using a Java environment to develop and debug a Java Card
program (caveat: even if debugging occurs with Java bytecode, make sure that the class file fits
the limitation of Java Card language by converting it to Java Card bytecode; and test in a real
Java Card smart card early on to get an idea of the performance); further, one can run and debug
both the Java Card code for the application to be embedded in a smart card, and a Java
application that will be in the host using the smart card, all working jointly in the same
environment

Java Card 3.0


The version 3.0 of the JavaCard specification (draft released in March 2008) is separated in two
editions: the Classic Edition and the Connected Edition.

 The Classic Edition is an evolution of the Java Card Platform Version 2.2.2 and supports
traditional card applets on more resource-constrained devices.
 The Connected Edition provides a new virtual machine and an enhanced execution
environment with network-oriented features. Applications can be developed as classic card
applets requested by APDU commands or as servlets using HTTP to support web-based
schemes of communication (HTML, REST, SOAP ...) with the card. The runtime supports
volatile objects (garbage collection), multithreading, inter-application communications
facilities, persistence, transactions, card management facilities ...)

Common questions

Powered by AI

The Java Card firewall mechanism functions to protect data integrity and privacy by controlling interactions between applets. Each applet runs in its own isolated environment, and the firewall checks and restricts accesses that applets can make to each other's data. This prevents one applet from improperly accessing or modifying another applet's sensitive data, thus maintaining data privacy and integrity. Only explicitly shared objects can be accessed across applets, adding another layer of access control .

The GlobalPlatform specifications in Java Card products address challenges related to the secure management of applications on smart cards. They provide standardized procedures for downloading, installing, personalizing, and deleting applets, ensuring secure transactions and integrity of operations during the life cycle of the applets on smart cards. These standards are critical to maintaining the security and interoperability of Java Card-based applications across different implementations .

Java Card 3.0 improves on previous versions through its Connected Edition, which introduces a new virtual machine and enhanced execution environment supporting network-oriented features. It allows applications to be developed as servlets using HTTP, facilitating web-based communications using HTML, REST, and SOAP. This enhances the ability to perform inter-application communications and manage transactions, providing more robust support for modern networked applications compared to the more resource-constrained Classic Edition .

In the Java Card platform, bytecode serves as the machine instructions run by the Java Card Virtual Machine. It is a functional subset of Java 2 Standard Edition bytecode, with a different encoding scheme optimized for size, which is vital for resource-constrained environments like smart cards. This optimization allows Java Card applets to use minimal memory, a crucial requirement given the limited resources of smart cards. The trade-off includes fewer language features and size limitations, which developers must navigate through careful application design and structuring .

Java Card's Virtual Machine (VM) and runtime library contribute to application portability by providing a uniform platform for executing applets across different smart cards. They abstract underlying hardware differences, allowing applets to run on various cards without modification. This is akin to Java applets running on different computer platforms, where the environment mediates hardware-specific differences. However, this portability is challenged by constraints like memory size, performance differences, and protocol support .

Java Card uses a subset of Java features, optimized for memory and processing constraints of smart cards, such as using a smaller and different bytecode encoding. This results in trade-offs like the absence of some Java language features (e.g., char, double, float, long types, enums, and garbage collection) and the need for careful application design to fit within size limits. While this enhances portability and security, it limits the richness of expression and functionality available in full Java, impacting the complexity of programs that can be efficiently developed .

The Classic Edition in Java Card 3.0 is an evolution from Version 2.2.2 and is designed for resource-constrained devices, supporting traditional card applets executed via APDU commands. Conversely, the Connected Edition introduces a new VM and supports servlets using HTTP for web-based interactions, which suits applications needing active network connections and complex communications like those based on HTML, REST, and SOAP . The Classic Edition is suitable for environments prioritizing low resource usage and straightforward applications, while the Connected Edition is tailored for advanced applications requiring constant connectivity and interactive network capabilities.

Java Card ensures application security through its architecture by using an isolated execution environment where applications run in a separate Java Card VM, providing data encapsulation. An applet firewall separates different applications, checking and restricting data access between them to prevent unauthorized access. Additionally, it supports standard cryptographic algorithms and services, such as encryption, signing, and key management, further securing interactions and data stored on smart cards .

The main design goals of Java Card technology are portability and security. Portability is achieved by defining a standard smart card computing environment that allows the same Java Card applet to run on different smart cards, achieved through the Java Card Virtual Machine and a well-defined runtime library, which abstracts differences between smart cards . Security is accomplished through data encapsulation, executing applications in an isolated environment, using an applet firewall to separate applications, and supporting cryptography for secure operations .

Java Card manages memory differently by defaulting to persistent memory for object storage due to RAM scarcity on smart cards. This requires the runtime environment and bytecode to be adapted for managing persistent objects. Implications include the need for atomic updates to persistent memory, as Java Card systems rely on external power. Java Card supports atomicity at the bytecode instruction and API method level, and it employs a transaction mechanism to ensure data integrity during updates .

You might also like