Java Card 3.1: Enhanced deployment model and core features

Java Card 3.1 introduces an extended file format, the management of static resources, binary compatibility improvements, and the support of array views. Those features evolve the deployment and upgrade of applications, and they permit better design modularity and security as well.

Extended CAP file format and deployment model

The base unit in the Java Card deployment model is the Java Card converted application (CAP) file. A CAP file contains all the classes and interfaces defined in a Java Card application or library. CAP files are installed on a Java Card product either at manufacturing time or once the product is deployed in the field by using a trusted service manager (TSM).

Until the 3.1 release, a CAP file contained only a single Java package (application or library) and was limited to 64 KB. In some cases, this caused application design constraints and remote management complexity due to the splitting of a secure service into several CAP files. To circumvent those issues, the 3.1 release introduces an extended CAP file of up to 8 MB that provides these benefits:

• The extended CAP file can contain multiple Java packages of applications and libraries. This eliminates design constraints and reduces the number of CAP files deployed by a TSM.
• A Java package can be private to a given application in contrast to public and shared packages that can be accessed by different applications available on the platform. This allows for a better design and for finer-grained access control.

Taking the example of an IoT application that uses two libraries, one for a dedicated storage hierarchy and one for a dedicated protocol to access a given IoT cloud service, there are three Java packages. If those packages’ implementations require utility packages—such as for asn.1 parsing and JSON parsing, which are generic and can be shared among different applications on the same platform—that can mean a total of five Java packages.

Without using the extended CAP file format, this would lead to five CAP files to deploy. Thanks to the new format, this can be reduced to one or any other combination that makes sense. Figure 1 shows a combination of two CAP files. Deployment complexity is greatly reduced. Access control is also better addressed because the libraries (protocol and storage) dedicated to the IoT application are now accessible only by the IoT application itself.    

Figure 1. Combining CAP files

Static resources in the CAP file

Java Card 3.1 supports static, read-only resources in CAP files. These resources are accessible only from the code included in the same CAP file via an associated identifier. CAP files offer implementation alternatives to store data out of the object heap. Examples of static resources could be a configuration used the first time an application starts, default parameters or a security policy, precomputed values or data patterns, and more.

Binary compatibility improvement

Evolving an API while ensuring backward compatibility is a challenge on any platform. The Java Card 3.1 virtual machine overcomes a limitation preventing the extension of the method set of a nonfinal class as well as a virtual machine mapping table (VMMT). As shown in Figure 2, this enhancement simplifies the upgrade of an API using either the Java Card API itself or a user library.

This enhancement is itself fully backward compatible and does not require a recompilation of existing packages. Only libraries containing classes upgraded with new methods will use this feature. Similarly, if an application code update uses the new methods in an upgraded API, the application will automatically use these code extensions.

Figure 2. Example of binary compatibility improvement

Array views

In certain scenarios, an application might need to access, process, or share a subset of an array instead of the whole array. Creating a defensive copy of the data in a separate array requires additional memory and data synchronization between the original array and the copy of its subset. Java Card 3.1 provides an alternative mechanism called array view, as shown in Figure 3. There are two big benefits of array view.

Figure 3. Example of an array view created on a subset of a parent array’s elements

The first benefit is simplified design and code modularity. An application can create an array view on a subset of the elements of a parent array and then use this array view when calling code in another module or running service. This greatly simplifies API design. Array views can be used directly as input or output parameters without the need to copy data, manage an offset, or implement any data synchronization protocol.

Array views also provide improved access control and security for sharing data between applications. An array view is a temporary array object to which are assigned read and write access control attributes. These control attributes enforce security by design and are useful, for instance, when an API returns a view from internal memory that must not be modified, such as when the field of a certificate object is accessed. In addition, as in shown in Figure 4, when an array view is created to share data between two applications (two firewall contexts), the application sharing the array view can specifically designate which application context it is sharing.

Figure 4. Example of array view sharing data

Source: oracle.com