Java Card Memory Footprint Optimization via Personalization Code Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Java Card applications face significant memory constraints due to the limited memory resources in smart cards, and existing optimization methods, such as modifying application code or using proprietary byte code, are inefficient in reducing memory footprint.
Innovation Solution
The method involves separating the personalization code from the main application code and loading it into a dedicated Card Personalization Specifications (CPS) package, allowing the personalization code to execute without being blocked by the Java Card firewall, and then removing it once personalization is complete, thereby reducing the memory footprint.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If personalization code is included in the main application package, then the application can be personalized, but the memory footprint increases and cannot be reduced after personalization
Solution Approach 1:
The application package is segmented into two separate packages: the main application package and the Card Personalization Specification (CPS) package. The CPS package contains the personalization code as a separate applet, allowing it to be independently managed and removed after personalization is complete, thus reducing the memory footprint of the main application.
Solution Approach 2:
The personalization code is prepared in advance in the CPS package, which is loaded alongside the main application. The CPS applet executes the personalization process before the main application becomes fully operational, ensuring that personalization is completed before the temporary code is removed.
2Quantity of substance
If personalization code is removed after personalization, then memory footprint is reduced, but the code may be blocked by the Java Card firewall
Solution Approach 1:
The CPS package acts as an intermediary that bridges the main application and the personalization process. The CPS applet within this package serves as a mediator that can access and modify the main application's data structures despite the Java Card firewall restrictions, enabling successful personalization before the CPS package is removed.
3Productivity
If more applications are stored on a single smart card, then productivity increases, but memory resources are limited
Solution Approach 1:
The CPS package containing the personalization code is discarded after it has served its purpose of personalizing the main application. This temporary use and subsequent removal of the personalization code allows the memory space to be recovered and made available for storing additional applications, thereby increasing the total number of applications that can be deployed on the smart card.
Data Source
Figure 1~2
Figure 3
AI summary
There is described a method for Java Card application memory footprint optimization which relies on the separation in advance of the code related to the personalization from the rest of the code. It allows this code to perform the personalization of an application installed from a main package while being itself included and installed from a separated package dedicated to the personalization, namely the Card Personalization Specifications (CPS) package. This way, the CPS package and all the code inherent to the personalization can be removed once all the personalization steps have been completed.