Java Card 3.1 explored

The new release tunes the popular Java platform for IoT applications as well as the cloud.

Download a PDF of this article

Java Card 3.1 is a major update of the Java Card specifications and the Java Card Development Kit. A key goal of this release is to ensure the availability of security services on a large range of heterogeneous secure hardware, including smartcards, embedded chips, secure enclaves within microprocessor units and microcontroller units, and removable subscriber identification module (SIM) chips such as those in your mobile phone.

In “Java Card 3.1 Unveiled,” Java Magazine covered extensions and services mirroring the extensive role that a Java Card–based secure element plays in IoT: A new I/O model and a range of APIs (Certificate, Key Derivation, Monotonic Counter, and System Time) enable the design of new applications that

• Establish a direct channel between the secure element and device peripherals to bring security at the very edge of a device
• Secure communications with IoT cloud services
• Perform various device attestation mechanisms to prove a device is genuine to a third party

This article digs deeper into Java Card 3.1’s deployment model, core features, and cryptography extensions, all of which bring more flexibility to design, develop, deploy, and upgrade security services.

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

New cryptographic extensions

A security product is not necessarily a cryptographic product. However, since security products often involve the protection and processing of sensitive data, they typically imply the use and management of cryptographic materials. Thus, Java Card provides wide and complete coverage of cryptographic primitives and algorithms. Version 3.1 offers updated cryptographic packages to handle keys as trusted objects and to support state-of-the-art algorithms and related operations. These packages are additions to the existing javacard.security and javacardx.crypto packages.

Configurable asymmetric key-pair generation support. A new method KeyPair.genKeyPair(AlgorithmParameterSpec) is added for an application (implementing AlgorithmParameterSpec) to configure some parameters of key-pair generation. In the case of the RSA algorithm, for instance, it is possible to configure the primality test as well as the seed and algorithms used to generate random numbers. Thus, an application can even generate a key pair in a deterministic way.

Asymmetric cryptography is critical to mutual authentication. It generally implies a client and a server that are equipped with key pairs and certificates. Because of the nature and scale of the IoT market, provisioning IoT devices with such cryptographic material takes time and implies costs during manufacture.

To avoid such inconvenience, some solutions rely on the injection of a secret within the device at manufacturing time or later. This secret (or a secret derived from it) is shared with a cloud service. Once the device is deployed, a key pair can be generated in a deterministic way on both sides using the shared secret as a common seed. This offers a more flexible way to equip a device with the key material needed to perform authentication once it is in the field.

Named elliptic curves support. Asymmetric encryption based on elliptic curve cryptography (ECC) is widely used because of its reduced processing time and low power consumption for computing encryption or signature operations. These characteristics make ECC a critical requirement for low-end IoT devices.

In most current cryptographic APIs—including the Java Card API—an ECC key is associated with a curve and its domain parameters. This offers a flexible way to match any variant of domain parameters, but it implies additional management (to pass domain parameters to a key object) and increases memory consumption. Besides, for interoperability and security reasons, standards bodies such as National Institute of Standards and Technology (NIST) generate and publish domain parameters for common field sizes. Such domain parameters are known as named curves and can be directly referenced by name, allowing for more-efficient memory management and consumption. That’s critical for IoT devices, where cryptography already consumes a lot of processor horsepower.

In Java Card 3.1, the ECC API (javacard.security package) supports ECC named curves. An application can create and use ECC keys without the need to configure corresponding key parameters, for example:

• The buildXECKey method is added to the class KeyBuilder to create ECC keys for named curves.
• The XECKey, XECPublicKey, and XECPrivateKey interfaces permit handling related keys.
• The NamedParameterSpec class provides a list of named curves:
  • Legacy curves that already had a counterpart in the original ECC API (with explicit domain parameters) are Brainpool and Secp curves for performing signature operations.
  • New curves such as the Edwards 25519 and Edwards 448 named curves perform key agreement and signature operations. Also, Java Card 3.1 can use the SM2 Chinese named curve, which can be used for signature, key agreement, and public key encryption operations in China.

Additional AES modes (CFB and XTS). The Java Card 3.1 API for encryption (javacardx.crypto.Cipher class) includes additional AES modes:

• Cipher feedback (CFB) mode, which is typically used for stream ciphering
• XEX tweakable block cipher with ciphertext stealing mode, which is typically used for secure storage in external memory

Chinese algorithms (SM2, SM3, and SM4). In addition to the SM2 Chinese named curve described above, the Java Card 3.1 API supports two other important Chinese algorithms:

• The SM3 hashing algorithm, which is an extension of the existing MessageDigest class
• The SM4 block cipher algorithm, which is an extension of the Cipher class

Conclusion

This article and the previous one covered the major new features of Java Card 3.1, such as its enhanced model for the design, deployment, and upgrades of applications; a new I/O interface; cryptographic extensions; and several security APIs (Certificate, Key Derivation, Monotonic Counter, and System Time).

These new features unlock security use cases in IoT devices and bring more value in the payment, identity, and cellular connectivity markets. For IoT, in addition to trusted peripheral access from a secure device, there are cloud security scenarios where Java Card hosts different authentication schemes from multiple IoT cloud providers on a single chip. Java Card 3.1 also enables the creation of a virtualized SIM chip where Java Card facilitates the porting of SIM applications (from the latest ETSI, 3GPP, and GMSA standards) and operator services onto a wide range of communications chip architectures for different networks.

With Java Card–based secure elements, equipment makers and service providers can build IoT products and IoT solutions that unify heterogeneous secure hardware and come with flexible, future-proof, and updated capabilities. These attributes are essential for markets where cybersecurity is a top concern and where developers are reluctant to embrace nonstandard security solutions.