Final touches are being made on version 3.1 of the Java Card Platform. This release brings an unprecedented level of new features, for existing markets but also to drive new IoT use cases. This post covers on one of key change in Java Card 3.1: the Applet deployment model.
The base unit in the Java Card deployment model is the Java Card Converted Applet (CAP) file. A CAP file contains all of the classes and interfaces defined in a Java Card Applet or Library. CAP files are installed on a Java Card product either at manufacturing, or once deployed in the field by using a Trusted Service Manager (TSM).
Until now, a CAP file contained only one Java package and was limited to 64Kb. In some cases this was leading to Applet design constraints, specifically for the deployment of large Applets where the remote management complexity increases. To circumvent those issues, Java Card 3.1 brings three changes to the CAP file format in order to facilitate Applet design and deployment:
CAP file can now contain multiple Java packages, which can be:
Applet packages only
Library packages only
a combination of Applet and Library packages.
This brings a reduction in the number of CAP files that needs to be deployed by a TSM. It also eliminates the constraints and costs that were induced by having one Java package per CAP file, as in previous versions.
Java packages visibility can now be declared as private, in addition to public and shared. It allows for a better design and for finer-grained access control and visibility, since a private package is private to a given Applet and therefore cannot be accessed by other Applets. Public and shared packages on the other hand can be accessed among the different Applets available on the platform.
Large CAP file sizes (>64KB) can now be deployed. This is mainly a consequence of the two previous points, and the new extended CAP file can reach up to 8Mb. This covers the vast majority of usage scenarios on the resource - constrained chips used in Java Card products. Even in traditional markets such as payment, some Applets were sometimes getting close to the limit.
If we take the example of an IoT Applet that is using two Libraries for a dedicated storage hierarchy, and a dedicated protocol to access a given IoT Cloud service: we have 3 Java packages. If we consider that those packages implementations require themselves utility packages such as asn.1 parsing and json parsing, that are generic and can be shared among different Applets on a same platform: we reach a total of 5 Java packages.
Without using the extended CAP file format, this would lead to 5 CAP files needing to be deployed. However thanks to the new format, this number can be reduced to 1 CAP file or any other combination that makes sense. In the figure below, we took a combination of 2 CAP files. Deployment complexity is greatly reduced. Besides, access control is also better addressed since the Library packages (protocol and storage) dedicated to the IoT Applet are now only accessible by the IoT Applet itself. The following figure illustrates this.
As we can see, the extended CAP file introduced in Java Card 3.1 brings much more than an increase in file size beyond 64KB of code and data. It allows for a better Applet design and deployment. Applet functionality can be split into different Java packages, making the development of a Java Card Applet a step closer to Java SE application programming. And since multiple Java packages can be part of the same CAP file, deployment logistic such are Library dependencies management are greatly simplified, with the related cost benefit. Java packages can now be deployed in an atomic manner, where the complete payload of an Applet is contained in a single CAP file avoiding versioning and deployment complexity.
Extended CAP files are one of the exciting new features in Java Card 3.1. We will continue to detail the contents of this release in future posts. Stay tuned...
|November 8, 2018||Applet Deployment Update|
|November 19, 2018||New I/O and Trusted Peripherals|
|November 27, 2018||Security Services|
|December 6, 2018||Core Platform Enhancements|
|December 14, 2018||New Cryptographic Extensions|