Español 
English 
A custom Java Card project treats the smart card as a controlled application platform, rather than simply loading multiple applets onto the same chip, thereby supporting the execution of multiple applications. Each applet should have its own independent security context, data, credentials, and access rules; shared services should be explicitly designed rather than assumed by default.
Furthermore, throughout the entire customized Java Card project, it is essential to allocate sufficient persistent storage and working memory for each application, clearly define ownership and management responsibilities for application keys, and determine whether new applets need to be loaded after the card is issued.
For a smart card manufacturer undertaking a customized Java Card project, the core principle is clear: the relationships between applications must be designed before the final chip is selected.
Custom Java Card Project Should Begin with a Multi-Application Architecture
A multi-application Java Card can integrate functions such as authentication, payment, access control, PKI certification, digital wallet signatures, and membership loyalty program management. Although these applications may coexist within the same secure element, this does not mean they should share the same data or cryptographic keys.
The architectural design should first address the following three key questions:
- Which resources belong to each application?
- Which resources (if any) need to be shared?
- Which management entity has the authority to manage each application?
These decisions establish the card’s security boundaries before applet development begins.
Maintain Applet Data Isolation; Share Only What Is Absolutely Necessary
Java Card technology uses an “Applet firewall” to isolate different application contexts. According to Oracle’s specifications, unless an explicit sharing mechanism is provided, one Applet generally cannot access objects belonging to another Applet. When applications do need to collaborate, Java Card supports “Shareable Interface Objects” (SIOs) to enable controlled inter-Applet communication.
For example, consider a custom Java smart card that integrates multiple functions:
| Application | Sensitive Data That Should Normally Remain Separate |
|---|---|
| Employee ID | Identity and personnel credentials |
| Building Access | Access keys and permission records |
| PKI Authentication | Private keys and certificates |
| Payment | Payment keys and transaction data |
Even when a card hosts both an access control applet and a PKI application, the access control applet should not be able to access the PKI application’s private key. If two applications need to use a common function, the development team should define a streamlined and dedicated interface rather than granting broad access to another applet’s data. This approach also simplifies subsequent testing, as the security boundaries of each application remain clear and well-defined.
Do Not Treat Key Management as a Single Shared Key Pool
Multiple mini-programs can share the same card management infrastructure without having to share the same application key.
GlobalPlatform security domains are designed to support independent application management permissions. The specification stipulates that security domains can store cryptographic keys used for secure channels and application management; different application providers can manage their applications through their own independent security domains and keys.
Therefore, a practical architectural layout might look as follows:
Card Issuer
1. Identity Application + Identity Keys
2. Payment Application + Payment Keys
3. Access Control Application + Access Control Credentials
In simple enterprise projects, a single organization may be responsible for managing all of the above applications; however, in government, banking, or multi-business projects, different application owners may require independent administrative privileges.
The key principle is:
Share the card management infrastructure where appropriate, but never automatically share application credentials.
Allocating Memory and Platform Resources Before Finalizing the Applet
Security isolation addresses only part of the challenges in a multi-application environment. The smart card must also have sufficient resources to host all applications simultaneously.
A common misconception is to select a Java smart card based solely on the size of the first CAP file, with the intention of adding more applications later. This approach can lead to problems once applets begin storing certificates, keys, personalization records, counters, or temporary working data.
Calculate the Full Memory Footprint for a Custom Java Card Project
When planning memory for a multi-application Java Card, the assessment should be based on the complete card configuration, rather than simply the number of applets.
A reasonable estimate should include the following:
Applet code + application data + keys and certificates + personalization data + capacity reserved for future updates
Memory consumption varies greatly among different applications. Basic access control applets may require only minimal storage space, whereas PKI, payment, or e-wallet applications may involve certificates, encryption keys, transaction data, and additional security features. In addition, the project must consider runtime memory requirements. Even if a card has sufficient persistent storage space to install multiple applets, it may still run out of memory during actual operation if an application requires temporary buffers or encryption resources.
Therefore, we recommend assessing memory only after loading, initializing, and personalizing all required applets. Never choose a chip based solely on the nominal size of a single CAP file.
Communication Interfaces Must Be Compatible with Each Application
Custom JavaCard projects with multiple applications may have different communication requirements.
Identity authentication or Public Key Infrastructure (PKI) applications may use the ISO/IEC 7816 contact interface, while access control or transportation functions may require ISO/IEC 14443 contactless communication. If a project includes both types of functions, a dual-interface platform may be necessary.
The customized framework provided by DCCO TECH supports contact, NFC/contactless, and dual-interface configurations.
Therefore, the interface should be determined at the application level:
Which applets can be accessed via contact?
Which applets can be accessed via contactless?
Should a particular applet support both access methods?
This decision involves not only the card substrate and antenna but also applet selection, command routing, testing, and reader compatibility.
Custom Java Card Project Supporting Multiple Applications
A custom Java Card project should support multiple applications through careful isolation and controlled management—rather than simply installing multiple CAP files on the same chip.
The overall custom architecture primarily consists of the following elements:
Implementing applet data isolation → Separating sensitive keys → Defining controlled sharing mechanisms → Coordinating the card’s memory resources → Assigning application management permissions → Reserving space for applets that may be deployed in the future.
The most important design consideration is not “How many applets can this chip accommodate?”
but rather:
“Can each application run independently? Can they interact only within the scope of intentional sharing? And can a secure and controllable management state be maintained throughout the card’s entire lifecycle?”
By building these considerations into the design from the start, a customized Java smart card can serve as a well-managed multi-application platform, rather than simply grouping unrelated functions that compete for resources within the same secure element.