Java Card 3.1: 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. Java Card offers cryptographic packages to handle keys as trusted objects, and to support state-of-the art algorithms and related operations.

The features described in this blog entry are new cryptographic extensions to the Java Card framework. In Java Card 3.1, they have been added to the following two packages:

1. javacard.security defines the core security and cryptography framework. It includes KeyBuilder and KeyPair classes to generate and build various types of keys and algorithms for symmetric (e.g. AES) and asymmetric (e.g. RSA, ECC, DH,…) algorithms. Operations such as random number generation, message digests calculation, signature generation and verification and key agreement are covered by dedicated classes in this package.

2. javacardx.crypto is an extension package that contains optional functionality for implementing a security and cryptography framework on the Java Card platform. This optional package is supported when cryptographic encryption and decryption functionality is included in the implementation. It contains the Cipher class and KeyEncryption interface. Cipher provides methods for encrypting and decrypting messages. KeyEncryption provides functionality that allows keys to be updated in a secure end-to-end fashion.

The Java Card 3.1 release offers the following extensions to the javacard.security and javacardx.crypto packages:

Configurable Key Pair generation Support

The API Class javacard.security.KeyPair is extended to provide means for an application to control some parameters of the asymmetric key pair generation. This helps algorithms requiring prime numbers to set up the primality test, for example Fermat or Miller-Rabin. In particular, it permits the configuration of a random number generator algorithm including the seed to be used. This last point is critical to be able to generate a key pair in a deterministic way from a known secret.

Asymmetric cryptography is critical to mutual authentication. It generally implies a client and a server, 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 at manufacture. It usually binds the device to a single IoT cloud service (to which the device will be attached).

To avoid such inconvenience, some solutions and protocols rely on the injection of a secret within the device at manufacture 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 in the field.

In Java Card 3.1, a new method KeyPair.genKeyPair(AlgorithmParameterSpec) is provided generate such keys is added,  supporting a configuration parameter object (implementing AlgorithmParameterSpec) provided by the application. In the case of the RSA algorithm for instance, it permits to configure:

◉ the parameters for primality test (like the type of test, or the number of rounds)

◉ the random number generation algorithm,  for example to deterministically generate the key from a secret

Named Elliptic Curves Support

Asymmetric cryptography based on Elliptic Curves Cryptography (ECC) is widely used. One reason of this success is the reduced processing time and low power consumption to compute encryption or signature operations - compared to RSA or DSA algorithms for instance. These characteristics make Elliptic Curves a critical requirement for low-end IoT devices.

In most of current cryptographic APIs - including the Java Card API - an ECC key is associated with a curve and its domain parameters. It offers a flexible way to match any variant of domain parameters, but implies additional management (to pass domain parameters to a key object) and memory consumption mechanisms. Furthermore, for interoperability and security reasons, standard bodies like NIST generate and publish domain parameters for common field sizes. Such domain parameters are known as "named curves" and can be directly referenced by their name. This mechanism allows a more efficient memory management, critical for IoT needs.

In Java Card 3.1, the ECC API in the javacard.security package is extended to support a set of named parameters, allowing an application to refer to these pre-defined parameters both to create and use keys, without the need to configure corresponding key parameters:

◉ a new buildXECKey method is added to the class KeyBuilder to create EC keys for named curves

◉ XECKey, XECPublicKey and XECPrivateKey interfaces permits to handle related keys

◉ NamedParameterSpec class provides a list of named curves. It includes new curves such as Edward 25519 & 448 named curves (see below for the complete list) for instance.

New Algorithms and Operations Support

Additional Elliptic Curves

Java Card 3.1 adds support to several named curves and related key agreement, signature and encryption operations:

• X25519 and X448 named curves and key agreement operation as specified in RFC 7748. It defines a key agreement scheme that is more efficient and secure than the existing ECDH scheme, and that is also used in TLS1.3
• The Named Curves mechanism is extended with X25519 and X448 which both allow to create the corresponding EC keys to be used with a KeyAgreement object instance.
• The KeyAgreement class is also extended to support this key agreement scheme.
• ED25519 and ED448 named curves and related signature operation, the Edwards-Curve Digital Signature Algorithm (EdDSA),  as specified in RFC 8032
• The Named Curves mechanism is extended with ED25519 and ED448 which both allow to create the corresponding EC keys to be used with a Signature object instance.
• The Signature class is also extended to support EdDSA in pure mode or pre-hash mode.
• FRP256v1 named curve which can be used for signature and key agreement operations
• The Named Curves mechanism is extended with FRP256v1 which allows to create the corresponding EC key.
• Signature class and KeyAgreement class are extended to support related operations.
• SM2 Chinese named curve which can be used for signature, key agreement and public key encryption operations
• The Named Curves mechanism is extended with SM2 which allows to create the corresponding EC key.
• Signature class, Cipher class and KeyAgreement class are extended to support related operations.
• For curves that already had a counter part on the original EC API (with domain parameters), a named curve variant (without domain parameters) is now available for common field sizes. It concerns Brainpool and Secp curves: 
• brainpoolp192r1, brainpoolp224r1, brainpoolp256r1, brainpoolp320r1, brainpoolp384r1, brainpoolp512r1
• brainpoolp192t1, brainpoolp224t1, brainpoolp256t1, brainpoolp320t1, brainpoolp384t1, brainpoolp512t1
• secp192r1, secp224r1, secp256r1, secp384r1, secp521r1

Additional AES modes (CFB & XTS)

Java Card 3.1 API for ciphering (javacardx.crypto.Cipher class) includes additional support to the following AES encryption modes:    

• Cipher Feedback mode - AES-CFB mode, typically used for stream ciphering. 
• XEX Tweakable Block Cipher with Ciphertext Stealing mode - AES-XTS mode, typically used for secure storage in external memory.

Chinese Algorithms (SM2 - SM3 - SM4)

In addition to the support of the Chinese SM2 named curve described above, Java Card 3.1 API includes also support to the following Chinese algorithms:

• SM3 hashing algorithm: extension of the existing MessageDigest class
• SM4 block cipher algorithm: extension of the Cipher class and new SM4 key type with corresponding interface

In Summary

Each release of the Java Card Platform brings updates to its cryptographic functionality. Inclusion of the latest algorithms and operations ensures that Java Card products and applications can offer interoperable state-of-the-art cryptography features. With the support of configurable Key Pair generation, Elliptic named curves keys and operations (e.g X25519, X448, ...), Chinese Algorithms (SM2, SM3, SM4) and two additional AES modes (CFB, XTS) the Java Card 3.1 release brings major enhancements to meet the security requirements of both existing secure chips and emerging IoT technologies.

Source: oracle.com