How Should You Select a Java Card Chip for a Government ID Card With Multiple Applets?

When selecting a Java Card chip to support multiple mini-programs for government-issued ID cards, start with the complete application architecture rather than focusing solely on storage capacity or chip brand. First, identify all the mini-programs the card must support, estimate the required persistent storage and working memory (RAM), determine the necessary encryption algorithms, plan how the application will load and be managed, and finally decide whether the credential will operate via contact, contactless, or dual-interface (hybrid) modes.

Our current NXP JCOP series options include the J2A040, J3H081, J3R110, J3R150, and J3R180; among these, the J3R150 and J3R180 offer 150 KB and 180 KB of user storage, respectively, making them ideal choices for large-scale security applications.

Therefore, from a smart card manufacturer’s perspective, the correct selection process can be outlined as follows:

Government application requirements → Application architecture design → Storage capacity calculation → Security and encryption mechanisms → GlobalPlatform management specifications → Interface requirements → Chip validation

Government ID cards typically serve multiple functions. A single card may integrate an authentication applet, a PKI certification application, digital signature capabilities, health or social security credentials, physical access control applications, and other government service modules.

Java Card technology is specifically designed to run multiple applications on resource-constrained secure elements. Oracle documentation distinguishes between persistent and transient memory: persistent objects are retained after a power cycle, while transient objects store temporary working data that does not need to be retained after a reset or deselection. Quote: Oracle

This distinction can help you select a Java Card chip.

Determining Java Card Chip Specifications Based on Applet Code, Persistent Data, and Runtime Requirements

The EEPROM or Flash capacity required for government ID cards depends on the specific content each applet stores and processes, not just the number of applets.

When estimating actual storage capacity, the following factors should be considered:

• Applet code and application data;
• Certificates, encryption keys, and security parameters;
• Identity- or service-related records;
• GlobalPlatform management data;
• Capacity reserved for future updates.

For example, a basic authentication mini-program requires relatively limited storage space, whereas a PKI mini-program may involve certificates, private keys, and digital signature functions. If the same card also supports social services or physical access control functions, the total storage requirements will increase further.

For this reason, when evaluating multiple microprograms, consider them as part of a complete card configuration. In addition to the installation package itself, microprograms may create persistent objects, keys, counters, and temporary working data during operation. Therefore, we recommend checking the actual memory usage on a Java Card after loading and personalization, rather than selecting a chip based solely on the nominal size of a single microprogram installation package.

Comprehensive Evaluation of the Cryptographic and Security Features of All Applets

Government ID applications typically combine multiple cryptographic functions. For example, one applet might use RSA for PKI authentication, another might rely on ECC, while card management operations might employ an AES-based secure channel.

Therefore, when evaluating a chip, consider the combination of algorithms used across all applets.
Take the J3R150 and J3R180 Java smart cards as examples; they support AES, RSA, ECC, and SHA algorithms, making them ideal for multifunctional secure identity applications.

Before selecting chips for production, we conduct the following verifications:

• Compatibility between the Java Card version and each applet;
• Required RSA, ECC, AES, and hash mechanisms;
• Key lengths and certificate requirements;
• Remaining persistent and transient memory space after installing all applets;
• Security certifications required by the issuing authority;
• Actual transaction performance on the final card.

This approach aims to avoid a common procurement mistake:
namely, selecting a chip that meets requirements on paper but fails to satisfy actual needs once all government applications are loaded because of resource constraints.

Lifecycle and Interface Planning When Selecting Java Card Chips

Storage capacity determines whether applications can load onto the card, while lifecycle management determines whether they can operate securely throughout the card’s service life. This distinction is what separates Java Card chips used for government ID cards from simple single-application smart cards.

Viewing GlobalPlatform as an Application Management Decision, Not Just a Technical Specification

Not all cards using Java Card technology must use GlobalPlatform. However, GlobalPlatform becomes essential when government card-issuing authorities need to securely install, personalize, update, isolate, or remove multiple applications.

GlobalPlatform defines card components, application management directives, transaction sequences, and interfaces, and specifically supports dynamic post-issuance application management. Its secure channel mechanism also secures communications between the card and authorized off-card entities.

For multi-application government ID cards, it supports the following architecture:
Issuer Security Domain

• Identity Application
• PKI Application
• Social Services Application
• Other Government Applications

If all applications are permanently installed during the manufacturing phase and do not require post-issuance management, GlobalPlatform may not be a technical requirement. However, for most complex government ID projects, we typically evaluate GlobalPlatform compatibility early, as application lifecycle management, security domains, key management, and secure loading are architectural requirements—not features to add after the chip has been selected.

Selecting the Interface Type Based on the Government Service Environment

The final key decision is to determine whether government ID cards should use contact, contactless, or dual-interface Java Card chips.

Our existing custom platform supports these three interface configurations:

1. Contact configuration for ISO 7816 environments
2. Contactless configuration for ISO 14443/NFC interactions
3. Dual-interface configuration.

Base the decision on the ID card’s actual usage scenarios.

When the ID card is primarily used for insertion into government terminals, desktop PKI card readers, or controlled administrative devices, the contact solution is more appropriate;
when the primary requirements involve rapid “swipe-based” identity verification, access control, or on-site verification, the contactless solution is more suitable;
if the same national ID card needs to be used in both of the above environments—for example, to perform contact-based digital signatures at government workstations and contactless identity verification at service counters—then the dual-interface solution offers significant advantages;

Selecting a Java Card Chip for Multi-Application Government ID Cards

When selecting a Java Card chip for government ID cards, work backward from the complete application environment.

First, list all applications and assess their requirements for code, persistent data, certificates, keys, and working memory. Next, calculate total resource consumption after installation and personalization, rather than selecting EEPROM or Flash capacity based solely on the number of applications.

Next, verify that the chip supports all necessary cryptographic algorithms, Java Card versions, security certifications, and lifecycle management features.

Finally, select a contact, contactless, or dual-interface option based on the government’s existing card reader infrastructure and citizens’ usage scenarios.

Therefore, from our perspective, the final Java Card chip selection process should be as follows:

Mini-program requirements → Actual memory usage → Encryption technology → GlobalPlatform lifecycle → Interface → Certification → Prototype loading and testing → Production chips

The right choice is not the chip with the largest EEPROM capacity, but the one that can securely support the government’s current application architecture while retaining enough technical flexibility for the ID card’s expected lifespan.