This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Java Card" – news ·newspapers ·books ·scholar ·JSTOR(January 2016) (Learn how and when to remove this message)

Java Card is a software technology that allowsJava-based applications (applets) to be run securely onsmart cards and more generally on similar secure smallmemory footprint devices^[1] which are called "secure elements" (SE). Today, a secure element is not limited to its smart cards and other removable cryptographic tokens form factors; embedded SEs soldered onto a device board and new security designs embedded into general purpose chips are also widely used. Java Card addresses this hardware fragmentation and specificities while retaining code portability brought forward by Java.

Java Card is the tiniest of Java platforms targeted for embedded devices. Java Card gives the user the ability to program the devices and make them application specific. It is widely used in different markets: wireless telecommunications within SIM cards and embedded SIMs (eSIM), payment within banking cards^[2] and RFID (NFC) mobile payment and for identity cards, healthcare cards, and passports. Several IoT products like gateways are also using Java Card based products to secure communications with a cloud service for instance.

The first Java Card was introduced in 1996 bySchlumberger's card division which later merged withGemplus to formGemalto. Java Card products are based on the specifications bySun Microsystems (Defunct in 2010 as it was acquired byOracle Corporation). Many Java card products also rely on the GlobalPlatform 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, security and backward compatibility.^[3]

Java Card aims at defining a standardsmart 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 algorithms). Moreover, vendors often expose proprietaryAPIs specific to their ecosystem, further limiting portability for applets that rely on such calls.To address these limitations,Vasilios Mavroudis andPetr Svenda introduced JCMathLib, an open-source cryptographic wrapper library for Java Card, enabling low-level cryptographic computations not supported by the standard API.^[4][5][6]

Java Card technology was originally developed for the purpose of securing sensitive information stored onsmart 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 symmetric key algorithms likeDES,Triple DES,AES, and asymmetric key algorithms such asRSA,elliptic curve cryptography are supported as well as other cryptographic services like signing, key generation and key exchange.

Applet

The 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.

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 program is compiled into a Java class file by a Java compiler; 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 typeschar,double,float andlong; thetransient qualifier;enums;arrays of more than one dimension;finalization; object cloning;threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular typeint, which is the default type of a Java expression; andgarbage collection of objects).

Java Card bytecode run by the Java Card Virtual Machine is a functional subset ofJava 2 bytecode run by a standard Java Virtual Machine but with a different encoding to optimize 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.

Standard Java Card class library and runtime support differs a lot from that in Java, and the common subset is minimal. Mostpackages offered in the Java SEstandard library are not present. 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. For example, Java Card has noString type, onlybyte[] (similar toC, whereC strings are represented aschar[]). Most primitives are absent except forbyte,short,int andboolean.^[7]

Thejava.lang package contains fundamental classes of the Java Card technology, which include the two classesObject (the root of the class hierarchy),Throwable (which has only one known subclassException, asError is not present) and relevant exceptions. As mentioned earlier,java.lang.String does not exist in Java Card due to the limitations of the platform, instead representing strings asbyte[]. Arrays (T[]) have thelength field.

There are no wrapper classesByte,Short,Integer andBoolean for the primitive typesbyte,short,int andboolean.

All exceptions exceptjava.io.IOException andjavacard.framework.CardException are instances ofjava.lang.RuntimeException.

The packagejava.rmi features the interfaceRemote for methods which are invoked from a card acceptance device (CAD) client application.

Thejavacard.framework package contains the framework of classes for creating Java Card applets. TheApplet is an abstract class for an applet. TheUtil class contains utility methods on byte arrays (byte[]) andshorts.

Thejavacard.security package contains interfaces and classes for working with cryptographic and security functionality.

These are extension packages to supplement thejavacard.* packages.

Thejavacardx.framework.* packages contain various utilities, such as classjavacardx.framework.math.BigNumber (operations on Big Numbers),javacardx.framework.nio (a package for buffers, containers for data),javacardx.framework.string.StringUtil (a class providing methods on UTF-8 encoded strings, still represented asbyte[]), packagejavacardx.framework.time which contains classesSysTime (for system time) andTimeDuration (for representing an amount of time), andjavacardx.framework.util.intx.JCint for working withint.

Thejavacardx.security.* packages contains functionality for working with certificates, cryptographic derivation functions, and more.

Thejavacardx.biometry contains functionality for biometric frameworks on Java Card. The classjavacardx.biometry.BioBuilder is used for creating biometric reference templates, and contains various constants representing different biometric identification means.

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 have 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.

Coding techniques used in a practical Java Card program differ significantly from those 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.

This is a"Hello, World!" program example in Java Card.

packageorg.wikipedia.examples;importjavacard.framework.APDU;importjavacard.framework.Applet;importjavacard.framework.ISO7816;importjavacard.framework.ISOException;importjavacard.framework.Util;publicclassHelloWorldAppletextendsApplet{// INS (instruction) byte for "say hello"finalstaticbyteHELLO_INS=(byte)0x01;// AID (Application Identifier) for the appletprivatestaticfinalbyte[]HELLO_APPLET_AID={(byte)0xA0,(byte)0x00,(byte)0x00,(byte)0x00,(byte)0x62,(byte)0x03,(byte)0x01,(byte)0x0C,(byte)0x01};protectedHelloWorldApplet(){register();}publicstaticvoidinstall(byte[]byteArray,shortbyteOffset,bytebyteLength){// the reference does not need to be assigned// we only need to call the constructorHelloWorldAppletapp=newHelloWorldApplet();}publicvoidprocess(APDUapdu){byte[]buffer=apdu.getBuffer();if(selectingApplet()){return;}byteins=buffer[ISO7816.OFFSET_INS];if(ins==HELLO_INS){sendHello(apdu);}else{ISOException.throwIt(ISO7816.SW_INS_NOT_SUPPORTED);}}privatevoidsendHello(APDUapdu){byte[]buffer=apdu.getBuffer();byte[]hello={'H','e','l','l','o'};shortlength=(short)hello.length;Util.arrayCopyNonAtomic(hello,(short)0,buffer,(short)0,length);apdu.setOutgoingAndSend((short)0,length);}}

Oracle has released several Java Card platform specifications and is providing SDK tools for application development.Usually smart card vendors implement just a subset of algorithms specified in Java Card platform targetand the only way to discover what subset of specification is implemented is to test the card.^[8]

• Version 3.2 (30.01.2023)^[9]
  • Introduced support for (D)TLS1.3 protocols
  • Added API clarifications to help application developers and significantly increase the level of interoperability across multiple implementations
• Version 3.1 (17.12.2018)^[10]
  • Added configurable key pair generation support, named elliptic curves support, new algorithms and operations support, additional AES modes and Chinese algorithms.
• Version 3.0.5 (03.06.2015)
  • Oracle SDK: Java Card Classic Development Kit 3.0.5u1 (03.06.2015)
  • Added support for Diffie-Hellman modular exponentiation, Domain Data Conservation for Diffie-Hellman, Elliptic Curve and DSA keys, RSA-3072, SHA3, plain ECDSA, AES CMAC, AES CTR.
• Version 3.0.4 (06.08.2011)
  • Oracle SDK: Java Card Classic Development Kit 3.0.4 (06.11.2011)
  • Added support for DES MAC8 ISO9797.
• Version 3.0.1 (15.06.2009)
  • Oracle SDK: Java Card Development Kit 3.0.3 RR (11.11.2010)
  • Added support for SHA-224, SHA-2 for all signature algorithms.
• Version 2.2.2 (03.2006)
  • Oracle SDK: Java Card Development Kit 2.2.2 (03.2006)
  • Added support for SHA-256, SHA-384, SHA-512, ISO9796-2, HMAC, Korean SEED MAC NOPAD, Korean SEED NOPAD.
• Version 2.2.1 (10.2003)
  • Oracle SDK: Java Card Development Kit 2.2.1 (10.2003)
• Version 2.2 (11.2002)
  • Added support for AES cryptography key encapsulation, CRC algorithms, Elliptic Curve Cryptography key encapsulation,Diffie-Hellman key exchange using ECC, ECC keys for binary polynomial curves and for prime integer curves, AES, ECC and RSA with variable key lengths.
• Version 2.1.1 (18.05.2000)
  • Oracle SDK: Java Card Development Kit 2.1.2 (05.04.2001)
  • Added support for RSA without padding.
• Version 2.1 (07.06.1999)

The version 3.0 of the Java Card specification (draft released in March 2008) is separated in two editions: theClassic Edition and theConnected Edition.^[11]

• TheClassic Edition (currently at version 3.0.5 released in June 2015) is an evolution of the Java Card Platform version 2 (which last version 2.2.2 was released in March 2006), which supports traditional card applets on resource-constrained devices such as Smart Cards. Older applets are generally compatible with newer Classic Edition devices, and applets for these newer devices can be compatible with older devices if not referring to new library functions. Smart Cards implementing Java Card Classic Edition have been security-certified by multiple vendors, and are commercially available.
• TheConnected Edition (currently at version 3.0.2 released in December 2009) aims to provide a new virtual machine and an enhanced execution environment with network-oriented features. Applications can be developed as classic card applets requested byAPDU commands or as servlets usingHTTP to support web-based schemes of communication (HTML,REST,SOAP ...) with the card. The runtime uses a subset of the Java (1.)6 bytecode, without Floating Point; it supports volatile objects (garbage collection),multithreading, inter-application communications facilities,persistence,transactions, card management facilities ... As of 2021, there has been little adoption in commercially available Smart Cards, so much that reference to Java Card (including in the present Wikipedia page) often implicitly excludes theConnected Edition.

Java Card 3.1 was released in January 2019.

• Applet functionality can be split into multiple Java packages
• CAP file sizes can exceed 64KB

• A variety of physical layers and application protocol is supported, beyond smart card protocols defined inISO 7816
• Logical access to device peripherals by secure element applications is facilitated

• Array Views (views on a subset of an array), Static Resources embedded within a CAP file and Improved API extensibility

• Certificate API, Key Derivation API, Monotonic Counter API, System Time API

• Configurable Key Pair generation, Named Elliptic Curves likeEdwards-Curves, Additional AES modes (CFB &XTS), Chinese Algorithms (SM2 - SM3 -SM4)

• Java Card OpenPlatform
• Tiny C Compiler, a similar subset of a larger language

• Java Card overview (Oracle)
• Defcon 21: The Secret Life of SIM Cards onYouTube
• JavaCards-OpenSC

• Java device platform
• Smart cards

• Articles with short description
• Short description matches Wikidata
• Articles needing additional references from January 2016
• All articles needing additional references