Java Keystore Generate Aes Key

Overview

1. Java Keystore Tutorial
2. Generate Jks Keystore
3. Java Keystore Certificate Examples
4. Java Keystore Generate Aes Key Bank

Security has become a great topic of discussion in the last few years due to the recent releasing of documents from Edward Snowden and the explosion of hacking against online commerce stores like JC Penny, Sony and Target. While this post will not give you all of the tools to help prevent the use of illegally sourced data, this post will provide a starting point for building a set of tools and tactics that will help prevent the use of data by other parties.

This post will show how to adopt AES encryption for strings in a Java environment. It will talk about creating AES keys and storing AES keys in a JCEKS keystore format. A working example of the code in this blog is located at https://github.com/mike-ensor/aes-256-encryption-utility

Generate a new secret key. To generate the key, follow the same process as the one for generating a new private key. You use the Security library in each case. Import encrypted keys more securely. Android 9 (API level 28) and higher allow you to import encrypted keys securely into the Keystore using an ASN.1‑encoded key format. Keystores must be created with a link to a new key or during an import of an existing keystore. In order to create a new key and keystore simply type: keytool -genseckey -keystore aes-keystore.jck -storetype jceks -storepass mystorepass -keyalg AES -keysize 256 -alias jceksaes.

In the following example, the command generates a keystore that uses the supported Java format (jceks). The encryption key uses an AES encryption algorithm with a key size of 192. In the following example, the command generates a keystore that uses the supported Java format (jceks).

It is recommended to read each section in order because each section builds off of the previous section, however, this you might want to just jump quickly jump to a particular section.

• Setup - Setup and create keys with keytool
• Encrypt - Encrypt messages using byte[] keys
• Decrypt - Decrypt messages using same IV and key from encryption
• Obtain Keys from Keystore - Obtain keys from keystore via an alias

What is JCEKS?

JCEKS stands for Java Cryptography Extension KeyStore and it is an alternative keystore format for the Java platform. Storing keys in a KeyStore can be a measure to prevent your encryption keys from being exposed. Java KeyStores securely contain individual certificates and keys that can be referenced by an alias for use in a Java program. Java KeyStores are often created using the 'keytool' provided with the Java JDK.

NOTE: It is strongly recommended to create a complex passcode for KeyStores to keep the contents secure. The KeyStore is a file that is considered to be public, but it is advisable to not give easy access to the file.

Setup

All encryption is governed by laws of each country and often have restrictions on the strength of the encryption. One example is that in the United States, all encryption over 128-bit is restricted if the data is traveling outside of the boarder. By default, the Java JCE implements a strength policy to comply with these rules. If a stronger encryption is preferred, and adheres to the laws of the country, then the JCE needs to have access to the stronger encryption policy. Very plainly put, if you are planning on using AES 256-bit encryption, you must install the Unlimited Strength Jurisdiction Policy Files. Without the policies in place, 256-bit encryption is not possible.

Java Keystore Tutorial

Installation of JCE Unlimited Strength Policy

This post is focusing on the keys rather than the installation and setup of the JCE. The installation is rather simple with explicit instructions found here (NOTE: this is for JDK7, if using a different JDK, search for the appropriate JCE policy files).

Keystore Setup

When using the KeyTool manipulating a keystore is simple. Keystores must be created with a link to a new key or during an import of an existing keystore. In order to create a new key and keystore simply type:

Important Flags

In the example above here are the explanations for the keytool's parameters:

Keystore Parameters

genseckey

Generate SecretKey. This is the flag indicating the creation of a synchronous key which will become our AES key

keystore

Location of the keystore. If the keystore does not exist, the tool will create a new store. Paths can be relative or absolute but must be local

storetype

this is the type of store (JCE, PK12, JCEKS, etc). JCEKS is used to store symmetric keys (AES) not contained within a certificate.

storepass

password related to the keystore. Highly recommended to create a strong passphrase for the keystore

Key Parameters

keyalg

algorithm used to create the key (AES/DES/etc)

keysize

size of the key (128, 192, 256, etc)

alias

alias given to the newly created key in which to reference when using the key

keypass

password protecting the use of the key

Encrypt

As it pertains to data in Java and at the most basic level, encryption is an algorithmic process used to programmatically obfuscate data through a reversible process where both parties have information pertaining to the data and how the algorithm is used. In Java encryption, this involves the use of a Cipher. A Cipher object in the JCE is a generic entry point into the encryption provider typically selected by the algorithm. This example uses the default Java provider but would also work with Bouncy Castle.

Generating a Cipher object

Obtaining an instance of Cipher is rather easy and the same process is required for both encryption and decryption. (NOTE: Encryption and Decryption require the same algorithm but do not require the same object instance)Once we have an instance of the Cipher, we can encrypt and decrypt data according to the algorithm. Often the algorithm will require additional pieces of information in order to encrypt/decrypt data. In this example, we will need to pass the algorithm the bytes containing the key and an initial vector (explained below).

Initialization

In order to use the Cipher, we must first initialize the cipher. This step is necessary so we can provide additional information to the algorithm like the AES key and the Initial Vector (aka IV).

Parameters

The SecretKeySpecification is an object containing a reference to the bytes forming the AES key. The AES key is nothing more than a specific sized byte array (256-bit for AES 256 or 32 bytes) that is generated by the keytool (see above).

Alternative Parameteters

There are multiple methods to create keys such as a hash including a salt, username and password (or similar). This method would utilize a SHA1 hash of the concatenated strings, convert to bytes and then truncate result to the desired size. This post will not show the generation of a key using this method or the use of a PBE key method using a password and salt. The password and/or salt usage for the keys is handled by the keytool using the inputs during the creation of new keys.

Initialization Vector

The AES algorithm also requires a second parameter called the Initialiation Vector. The IV is used in the process to randomize the encrypted message and prevent the key from easy guessing. The IV is considered a publicly shared piece of information, but again, it is not recommended to openly share the information (for example, it wouldn't be wise to post it on your company's website). When encrypting a message, it is not uncommon to prepend the message with the IV since the IV will be a set/known size based on the algorithm. NOTE: the AES algorithm will output the same result if using the same IV, key and message. It is recommended that the IV be randomly created each time an encryption takes place.

With the newly initialized Cipher, encrypting a message is simple. Simply call:

Encoding Results

Byte arrays are difficult to visualize since they often do not form characters in any charset. The best recommendation to solve this is to represent the bytes in HEX (base-16), Double HEX (base-32) or Base64 format. If the message will be passed via a URL or POST parameter, be sure to use a web-safe Base64 encoding. Google Guava library provides a excellent BaseEncoding utility. NOTE: Remember to decode the encoded message before decrypting.

Decrypt

Decrypting a message is almost a reverse of the encryption process with a few exceptions. Decryption requires a known initialization vector as a parameter unlike the encryption process generating a random IV.

Decryption

When decrypting, obtain a cipher object with the same process as the encryption method. The Cipher object will need to utilize the exact same algorithm including the method and padding selections. Once the code has obtained a reference to a Cipher object, the next step is to initialize the cipher for decryption and pass in a reference to a key and the initialization vector.NOTE: The key is stored in the keystore and obtained by the use of an alias. See below for details on obtaining keys from a keystore

Generate Jks Keystore

Once the cipher has been provided the key, IV and initialized for decryption, the cipher is ready to perform the decryption.

Strategies to keep IV

The IV used to encrypt the message is important to decrypting the message therefore the question is raised, how do they stay together. One solution is to Base Encode (see above) the IV and prepend it to the encrypted and encoded message: Base64UrlSafe(myIv) + delimiter + Base64UrlSafe(encryptedMessage). Other possible solutions might be contextual such as including an attribute in an XML file with the IV and one for the alias to the key used.

Obtain Key from Keystore

The beginning of this post has shown how easy it is to create new AES-256 keys that reference an alias inside of a keystore database. The post then continues on how to encrypt and decrypt a message given a key, but has yet shown how to obtain a reference to the key in a keystore.

Solution

Parameters

keystoreLocation

String - Location to local keystore file location

keypass

String - Password used when creating or modifying the keystore file with keytool (see above)

alias

String - Alias used when creating new key with keytool (see above)

Conclusion

This post has shown how to encrypt and decrypt string based messages using the AES-256 encryption algorithm. The keys to encrypt and decrypt these messages are held inside of a JCEKS formatted KeyStore database created using the JDK provided 'keytool' utility. The examples in this post should be considered a solid start to encrypting/decrypting symmetric keys such as AES. This should not be considered the only line of defense when encrypting messages, for example key rotation. Key rotation is a method to mitigate risks in the event of a data breach. If an intruder obtains data and manages to hack a single key, the data contained in multiple files should have used several keys to encrypt the data thus bringing down risk of a total exposure loss.

All of the examples in this blog post have been condensed into a simple tool allowing for the viewing of keys inside of a keystore, an operation that is not supported out of the box by the JDK keytool. Each aspect of the steps and topics outlined in this post are available at: https://github.com/mike-ensor/aes-256-encryption-utility. NOTE: The examples, sample code and any reference is to be used at the sole implementers risk and there is no implied warranty or liability, you assume all risks.

Creating a KeyStore in JKS Format

This section explains how to create a KeyStore using theJKS format as the database format for both the private key, and theassociated certificate or certificate chain. By default, as specifiedin the java.security file, keytool usesJKS as the format of the key and certificate databases (KeyStore andTrustStores). A CA must sign the certificate signing request (CSR).The CA is therefore trusted by the server-side application to whichthe Adapter is connected.

Itis recommended to use the default KeyStore

Java Keystore Certificate Examples

where <c:JavaCAPS> isthe directory where Java CAPS is installed and <MyDomain> isthe name of your domain.

To Generate a KeyStore

Java Keystore Generate Aes Key Bank

1. Perform the following command.

2. Once prompted, enter the information required to generatea CSR. A sample key generation section follows.

   If the KeyStore password is specified, then the password mustbe provided for the adapter.

3. Press RETURN when prompted for the key password (thisaction makes the key password the same as the KeyStore password).

   This operation creates a KeyStore file clientkeystore in the current working directory. You must specify a fullyqualified domain for the “first and last name” question.The reason for this use is that some CAs such as VeriSign expect thisproperties to be a fully qualified domain name.

   Thereare CAs that do not require the fully qualified domain, but it isrecommended to use the fully qualified domain name for the sake ofportability. All the other information given must be valid. If theinformation cannot be validated, a CA such as VeriSign does not signa generated CSR for this entry.

   This KeyStore containsan entry with an alias of client.This entry consists of the generated private key and information neededfor generating a CSR as follows:

   This command generates a certificate signing request which canbe provided to a CA for a certificate request. The file client.csr contains the CSR in PEM format.

   Some CA (one trusted by the web server to which the adapteris connecting) must sign the CSR. The CA generates a certificate forthe corresponding CSR and signs the certificate with its private key.For more information, visit the following web sites:

   or

   If the certificate is chained with the CA’scertificate, perform step 4; otherwise, perform step 5 in the followinglist:

4. Perform the following command.

   The command imports the certificate and assumes the client certificateis in the file client.cer and theCA’s certificate is in the file CARoot.cer.

5. Perform the following command to import the CA’scertificate into the KeyStore for chaining with the client’scertificate.

6. Perform the following command to import the client’scertificate signed by the CA whose certificate was imported in thepreceding step.

   The generated file clientkeystore containsthe client’s private key and the associated certificate chainused for client authentication and signing. The KeyStore and/or clientkeystore, can then be used as the adapter’sKeyStore.