Sven Ruppert

The Java Cryptography Architecture (JCA) is an essential framework within the Java platform that provides developers with a flexible and extensible interface for cryptographic operations. It is a central component of the Java Security API and enables platform-independent implementation of security-critical functions.

At its core, the JCA provides mechanisms for various cryptographic applications, including the calculation of hashes to ensure data integrity, the generation and verification of digital signatures, and methods for encrypting and decrypting sensitive information. Supporting both symmetrical and asymmetrical encryption methods, it ensures a high level of security when processing data. Cryptographic key management is another key aspect that includes secure storage and exchange of keys.

A significant feature of the JCA is the ability to integrate different security providers (so-called providers) that implement different cryptographic algorithms. In addition to the providers that come standard with Java, such as SunJCE, there are alternative implementations, including open source libraries such as Bouncy Castle and hardware-based solutions, that can be integrated via PKCS#11 interfaces.

The JCA’s architecture is characterised by a modular design that allows a separation between the API and the concrete implementations. New cryptographic algorithms can be added via the so-called Service Provider Interface (SPI) without having to adapt existing application code, contributing to the long-term maintainability and security of Java applications.

In addition to classic cryptography, the JCA also supports mechanisms for the secure generation of random numbers, the calculation of Message Authentication Codes (MACs) to ensure data integrity, and the management of certificates and trust stores. In particular, integration with the Java KeyStore API offers a comprehensive basis for the secure handling of X.509 certificates and cryptographic keys.

How is the JCA integrated into the Security API?

The Java Security API is a comprehensive framework for implementing security-related mechanisms in Java applications. It provides various functions that cover various aspects of IT security, including cryptography, authentication, authorization, network security, and cryptographic key management. A central component of this framework is the Java Cryptography Architecture (JCA).

While JCA is primarily responsible for the cryptographic functions, it extends the Java Cryptography Extension (JCE). This concept includes algorithms for symmetric encryption, key agreement and block cipher modes. In addition to cryptography, the Java Security API includes other security-relevant modules. The Java Secure Socket Extension (JSSE) API enables secure communication via network protocols such as TLS and SSL, enabling encrypted connections for web applications and other network services to be realised. This provides authentication and authorisation Java Authentication and Authorization Service (JAAS) API mechanisms available to verify user identities and control access rights. This architecture allows integration with various authentication sources such as user-password combinations, Kerberos or biometric methods.

Another essential component of the framework is the Java Public Key Infrastructure (PKI) API, which deals with the management of digital certificates and public keys. This API plays a central role in the realization of TLS encryption and the implementation of digital signatures. Certificate management is carried out via so-called KeyStores, which enable secure storage of cryptographic keys. In addition, the framework supports digital signatures for XML documents through the Java XML Digital Signature API (XMLSig), which is particularly used in web services and SAML authentication scenarios.

The distinction between the Java Security API and the JCA lies in their respective focus. While the Java Security API provides a comprehensive collection of security-related mechanisms and covers both cryptographic and non-cryptographic security aspects such as authentication, permission management and network security, the JCA focuses exclusively on providing cryptographic operations. In this context, JCA offers basic mechanisms for encryption and digital signatures, but JCE is required for modern symmetric encryption methods. Likewise, although JCA includes basic functions for managing cryptographic keys, more comprehensive management of certificates and public key infrastructure requires the use of the PKI API.

In practice, this means that developers access the JCA and JCE directly to implement cryptographic security mechanisms, while specific modules such as JAAS or JSSE are used for higher security-related functions such as authentication, authorisation or the management of secure network connections. The Java Security API thus forms a coherent but modular security architecture that can be used specifically depending on the application.

In this article we will only deal with the JCA. The other functional units will be gradually added in later articles.

Symmetric encryption

The symmetric encryption within the Java Cryptography Architecture (JCA) offers a powerful and flexible interface for the secure processing of confidential data. It is based on the use of a single secret key for encryption and decryption, which makes it more efficient and faster than asymmetric methods. The JCA provides the Cipher-Class that acts as a central mechanism for symmetric cryptography and enables the implementation of various block and stream ciphers.

A key feature of symmetric encryption in the JCA is its support for modern block ciphers such as AES (Advanced Encryption Standard), which is considered the current industry standard, as well as older methods such as DES (Data Encryption Standard) and its improved version, Triple DES (3DES). The API allows the use of various operating modes, including ECB (Electronic Codebook), which is considered unsafe, as well as safer modes such as CBC (Cipher Block Chaining), CFB (Cipher Feedback Mode) and GCM (Galois/Counter Mode). GCM in particular is preferred because, in addition to confidentiality, it also offers integrity protection through Authenticated Encryption (AEAD).

A central concept of the JCA is the separation between the abstract API and the concrete implementations provided by various cryptography providers. This keeps the actual implementation interchangeable without tying the application to a specific algorithm or library. The initialization of a Cipher-Object is done by specifying the algorithm as well as the desired operating mode and an optional padding method that ensures block-by-block processing of the data. Common padding schemes are PKCS5Padding and NoPadding, the latter requiring manual adjustment of the input data.

The JCA also provides mechanisms for the secure generation and management of keys. About the KeyGenerator-Class, symmetrical keys can be generated based on a defined key length, with key lengths of 128, 192 and 256 bits being particularly common for AES. To ensure the security of the keys, they can be passed through the Java KeyStore (JKS) or external hardware security modules (HSMs). Additionally, the API allows keys to be imported and exported in standardised formats to ensure interoperability with other cryptographic systems.

Another central element of symmetric encryption in the JCA is the treatment of initialisation vectors (IVs), which are crucial for the security of the encryption, especially in modes such as CBC or GCM. IVs must be unique for each encryption operation to prevent attacks such as replay or chosen plaintext attacks. In practice, IVs are often over SecureRandom generated to ensure high entropy and stored or transmitted along with the encrypted data.

The architecture of the JCA allows developers to use symmetric encryption not only for straightforward file and message encryption, but also in more complex scenarios such as Transport Layer Security (TLS), Database encryption and Hardware-assisted encryption. By combining it with other JCA components, such as the Mac class for Message Authentication Codes (e.g. HMAC-SHA256) or Key Derivation Functions (e.g. PBKDF2), additional security features such as authentication and key derivation can be implemented.

The first practical steps

Let’s now move on to a simple example of using symmetric encryption within the Java Cryptography Architecture (JCA) and use the AES algorithm family in combination with a secure operating mode and padding. The implementation relies on the Cipher-Class, a central interface in Java for processing cryptographic operations. Choosing secure key management is crucial, which is why the key is stored using the KeyGenerator class, which is created. SecureRandom is used to ensure high entropy and encryption security for the initialisation data.

Within the method, a character array (char[]) is used instead of a string to ensure that sensitive data does not remain in the string pool and can be specifically overwritten after processing. (Here, I refer to the previous article, in which I described this in more detail.) After the key and IV initialisation, encryption is carried out using a Cypher object in AES-CBC mode with PKCS5Padding. The encrypted string is then stored in a byte array. Decryption is done in reverse order by reinitialising the Cipherobject with the same key and IV, which allows the original characters to be restored from the encrypted data stream.

The following source code demonstrates the implementation of this concept:

import javax.crypto.Cipher;
import javax.crypto.KeyGenerator;
import javax.crypto.SecretKey;
import javax.crypto.spec.IvParameterSpec;
import java.security.SecureRandom;
import java.util.Arrays;

public class SymmetricEncryptionExample {

    public static void main(String[] args) throws Exception {
        KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
        keyGenerator.init(256);
        SecretKey secretKey = keyGenerator.generateKey();

        SecureRandom secureRandom = new SecureRandom();
        byte[] iv = new byte[16];
        secureRandom.nextBytes(iv);
        IvParameterSpec ivSpec = new IvParameterSpec(iv);

        char[] originalText = {'H', 'e', ​​'l', 'l', 'o', ' ', 'J', 'C', 'A'};
        byte[] encryptedText = encrypt(originalText, secretKey, ivSpec);
        char[] decryptedText = decrypt(encryptedText, secretKey, ivSpec);

        System.out.println(decryptedText);
        Arrays.fill(decryptedText, '\0'); 
    }

    private static byte[] encrypt(char[] input, SecretKey key, IvParameterSpec ivSpec) throws Exception {
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        cipher.init(Cipher.ENCRYPT_MODE, key, ivSpec);
        return cipher.doFinal(new String(input).getBytes());
    }

    private static char[] decrypt(byte[] input, SecretKey key, IvParameterSpec ivSpec) throws Exception {
        Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
        cipher.init(Cipher.DECRYPT_MODE, key, ivSpec);
        byte[] decryptedBytes = cipher.doFinal(input);
        char[] decryptedChars = new char[decryptedBytes.length];

        for (int i = 0; i < decryptedBytes.length; i++) {
            decryptedChars[i] = (char) decryptedBytes[i];
        }
        return decryptedChars;
    }
}

Asymmetric encryption

The asymmetric encryption within the Java Cryptography Architecture (JCA) provides a flexible and secure way to encrypt and decrypt data using two different keys: a public key for encryption and a private key for decryption. This method is based on one-way mathematical functions, which make it practically impossible to calculate the private key from the public key. This makes asymmetric cryptography particularly suitable for applications that require secure key distribution and digital signatures, including Transport Layer Security (TLS), Public Key Infrastructure (PKI), and various authentication mechanisms.

The JCA provides with the Cipherclass provides a central API that enables the implementation of asymmetric encryption methods. The algorithms are particularly widespread RSA (Rivest-Shamir-Adleman), Elliptic Curve Cryptography (ECC) as well as  Diffie-Hellman for key exchange. RSA is based on the factorization of large prime numbers and is widely used as a classic public key method. In contrast, ECC uses elliptic curves over finite fields and offers comparable security with a smaller key length, making it particularly preferred for resource-constrained environments such as mobile devices or smart cards.

The key is generated via the KeyPairGenerator-Class that allows to generate asymmetric key pairs with different key lengths. The choice of key length affects security and computing power, with RSA typically operating at 2048 or 4096 bits, while elliptic curves use more efficient 256 or 384 bit keys. The public key generated can be freely distributed, while the private key must be kept secure, for example by storing it in a Java KeyStore (JKS) or a hardware security solution such as a Hardware Security Module (HSM).

A Cipher object is initialised with the desired algorithm and mode for the encryption. The JCA supports various padding mechanisms necessary to adapt input data to the block size of the encryption function used. At RSA, PKCS1Padding and OAEP (Optimal Asymmetric Encryption Padding) are standard methods, with OAEP being preferred due to its increased security, as it protects against adaptive chosen ciphertext attacks. Due to its high computational complexity, asymmetric encryption is primarily suitable for encrypting small amounts of data, such as key material or hash values, rather than large files or streaming data.

Another central application area of ​​asymmetric cryptography in the JCA is the digital signature, which is carried out via the Signature class. The private key creates a signature for a message or file, which can later be verified using the public key. Digital signatures ensure both the authenticity and integrity of the transmitted data by ensuring that the message comes from the specified sender and has not been subsequently altered. In particular, algorithms like RSA with SHA-256, ECDSA (Elliptic Curve Digital Signature Algorithm) or EdDSA (Edwards-Curve Digital Signature Algorithm) are used in modern applications to ensure authenticity and data integrity.

In addition to classic asymmetric encryption, the JCA also supports hybrid methods in which asymmetric cryptography is used to securely transmit a symmetric key, which is then used for data encryption. This procedure is used, for example, TLS (Transport Layer Security) or PGP (Pretty Good Privacy), to combine the advantages of both types of cryptography: the security of asymmetric key distribution and the efficiency of symmetric encryption.

The JCA’s architecture allows developers to flexibly use asymmetric encryption schemes by supporting a variety of security vendors that provide different implementations. By default, the Java platform offers support for RSA, DSA and elliptic curves, while alternative providers such as Bouncy Castle enable additional algorithms and optimisations. 

A practical example

This example uses the RSA algorithm to implement asymmetric encryption, encrypting data with a public key and decrypting it with the corresponding private key. The implementation is done using the Cipher class. The KeyPairGenerator class is used to generate the key pair, which makes it possible to generate an RSA key with a length of 2048 bits. The resulting key pair consists of a public key used for encryption and a private key required for decryption.

The encryption method takes char[] as input to ensure that no sensitive data is included as String remains in memory. The characters are explicitly converted to a byte array before encryption to enable direct storage operations. Afterwards, Cipherobject is put into encryption mode with the public key, and the conversion is performed. Once encryption is complete, the original byte array is securely overwritten to prevent potential reconstruction in memory.

Decryption is carried out using an analogous procedure. The Cipher object is initialised with the private key to return the previously encrypted byte array to its original state. After decryption, the byte array turns back into a char[] converted without doing a String conversion. To protect the decrypted data, the original and decrypted byte arrays are overwritten with null values ​​after processing.

import javax.crypto.Cipher;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.util.Arrays;

public class AsymmetricEncryptionExample {

    public static void main(String[] args) throws Exception {
        KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
        keyPairGenerator.initialize(2048);
        KeyPair keyPair = keyPairGenerator.generateKeyPair();
        PublicKey publicKey = keyPair.getPublic();
        PrivateKey privateKey = keyPair.getPrivate();

        char[] originalText = {'H', 'e', ​​'l', 'l', 'o', ' ', 'J', 'C', 'A'};
        byte[] encryptedText = encrypt(originalText, publicKey);
        char[] decryptedText = decrypt(encryptedText, privateKey);

        System.out.println(decryptedText);
        Arrays.fill(decryptedText, '\0'); 
        Arrays.fill(originalText, '\0');  
    }

    private static byte[] encrypt(char[] input, PublicKey key) throws Exception {
        Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
        cipher.init(Cipher.ENCRYPT_MODE, key);

        byte[] inputBytes = new byte[input.length];
        for (int i = 0; i < input.length; i++) {
            inputBytes[i] = (byte) input[i]; 
        }

        byte[] encryptedBytes = cipher.doFinal(inputBytes);
        Arrays.fill(inputBytes, (byte) 0); 
        return encryptedBytes;
    }

    private static char[] decrypt(byte[] input, PrivateKey key) throws Exception {
        Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding");
        cipher.init(Cipher.DECRYPT_MODE, key);

        byte[] decryptedBytes = cipher.doFinal(input);
        char[] decryptedChars = new char[decryptedBytes.length];

        for (int i = 0; i < decryptedBytes.length; i++) {
            decryptedChars[i] = (char) decryptedBytes[i]; 
        }

        Arrays.fill(decryptedBytes, (byte) 0); 
        return decryptedChars;
    }
}

Digital signatures

Digital signatures are cryptographic mechanisms that ensure digital messages or documents’ authenticity, integrity and non-repudiation. They are based on asymmetric cryptography and use a key pair consisting of a private key used to generate the signature and a public key used for verification. The central idea behind digital signatures is to confirm the sender’s identity and ensure that the transmitted data has not been tampered with during transmission or storage.

Creating a digital signature begins with calculating a hash value of the message to be signed using a cryptographic hash function. This hash value represents a unique, compact representation of the original message, with even a minimal change to the message resulting in a completely different hash. This hash value is then encrypted with the sender’s private key, creating the digital signature. This signature is transmitted or stored along with the original message to ensure its authenticity later.

The recipient verifies the digital signature using the sender’s public key. To do this, the received message is first hashed again to calculate a new hash value. In parallel, the digital signature is decrypted using the public key, restoring the original hash value generated by the sender. If both hash values ​​match, the recipient can assume with a high degree of certainty that the message is authentic and has not been changed. If the hash values ​​are different, it means either that the message has been tampered with or that the signature was created with a different key, indicating an unauthorised modification or a forged identity.

The security of digital signatures depends largely on the strength of the underlying mathematical procedures and the secure handling of the private keys. Classic signature algorithms like RSA or DSA (Digital Signature Algorithm) are increasingly being used by more modern processes such as ECDSA (Elliptic Curve Digital Signature Algorithm) or EdDSA (Edwards-Curve Digital Signature Algorithm), as they offer comparable security with shorter keys and higher efficiency. The continuous development of cryptographic standards is essential to keep digital signatures secure in the long term against future threats, such as those from quantum computers.

A practical example 

This digital signature implementation example demonstrates the creation and verification of a signature using the RSA signature algorithm with SHA-256. The Signature-Class carries out the implementation. To generate a valid key pair, the KeyPairGenerator class makes it possible to generate an RSA key pair with a length of 2048 bits. The resulting key pair consists of a private key, which is used to create the signature, and a public key, which is used for later verification.

Signature generation begins by processing an input known as char[] that is present. Before signing, the characters are converted directly into a byte array without creating strings. The Signature instance is initialised with the private key, after which the data is processed and the signature is generated. This is stored in a separate byte array, while the original input array is overwritten with null values ​​after processing to minimise security risks.

The signature is verified by initialising the Signature instance again, this time with the public key. The received data is passed to signature verification in byte form, ensuring that it matches the originally signed data. If the verification is successful, it means that the data has remained unchanged and comes from the specified source. On the other hand, a failure of verification indicates that either the data or the signature was manipulated or that an incorrect public key was used for verification.

The following source code shows an example usage:

import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.security.Signature;
import java.util.Arrays;

public class DigitalSignatureExample {

    public static void main(String[] args) throws Exception {
        KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
        keyPairGenerator.initialize(2048);
        KeyPair keyPair = keyPairGenerator.generateKeyPair();
        PublicKey publicKey = keyPair.getPublic();
        PrivateKey privateKey = keyPair.getPrivate();

        char[] message = {'H', 'e', 'l', 'l', 'o', ' ', 'J', 'C', 'A'};
        byte[] signature = signData(message, privateKey);
        boolean isValid = verifyData(message, signature, publicKey);

        System.out.println("Signature valid: " + isValid);
        Arrays.fill(message, '\0'); 
    }

    private static byte[] signData(char[] input, PrivateKey key) throws Exception {
        Signature signature = Signature.getInstance("SHA256withRSA");
        signature.initSign(key);

        byte[] inputBytes = new byte[input.length];
        for (int i = 0; i < input.length; i++) {
            inputBytes[i] = (byte) input[i]; 
        }

        signature.update(inputBytes);
        byte[] signedBytes = signature.sign();
        Arrays.fill(inputBytes, (byte) 0); 
        return signedBytes;
    }

    private static boolean verifyData(char[] input, byte[] signatureBytes, PublicKey key) throws Exception {
        Signature signature = Signature.getInstance("SHA256withRSA");
        signature.initVerify(key);

        byte[] inputBytes = new byte[input.length];
        for (int i = 0; i < input.length; i++) {
            inputBytes[i] = (byte) input[i]; 
        }

        signature.update(inputBytes);
        boolean isValid = signature.verify(signatureBytes);
        Arrays.fill(inputBytes, (byte) 0); 
        return isValid;
    }
}

Now let’s combine symmetric and asymmetric encryption

Secure communication between a client and a server can be achieved by combining asymmetric cryptography for key exchange and symmetrical encryption for the actual message transmission. In this simulation, a hybrid encryption system is implemented that initially uses RSA to enable secure transmission of a session key, which is then used for encrypted communication using AES. This architecture is comparable to the handshake process in TLS (Transport Layer Security), whereby asymmetric cryptography is only used for the initial key exchange. At the same time, the more efficient symmetric encryption secures the messages.

First, the server generates an RSA key pair, which is used to encrypt and decrypt the session key. The client provides the public key while the private key remains on the server. The client then creates one random AES session key, which is encrypted with and sent to the server’s RSA public key. Once received, the server decrypts the session key using its private key. Both parties now have the same symmetrical key used for subsequent encrypted communication.

The message transmission takes place using the AES algorithm in Galois/Counter Mode (GCM), which, in addition to confidentiality, also ensures integrity protection through integrated authentication. Each message packet sent is given a random initialisation vector (IV) before encryption to ensure that identical messages do not result in identical ciphertexts.

If you remember the login process, you can use this procedure to secure the components transmitted over the network, such as hash values ​​and salt values. At this point, I must, of course, point out again that this is a presentation of the basic principles. For productive use, it is recommended to use existing implementations and protocols. 

Happy Coding

Sven