Different types of keystore in Java -- Overview
Keystore is a storage facility to store cryptographic keys and certificates. They are most frequently used in SSL communications to prove the identity of servers and clients. A keystore can be a file or a hardware device. Three are three kinds of entries can be stored in a keystore depending on the types of keystores.
The three types of entries are:
PrivateKey : This is a type of keys which are used in asymmetric cryptography. It is usually protected with password because of its sensitivity. It can also be used to sign a digital signature.
Certificate : A certificate contains a public key which can identify the subject claimed in the certificate. It is usually used to verify the identity of a server. Sometimes it is also used to identify a client when requested.
SecretKey : A key entry which is sued in symmetric cryptography.
Depending on what entries the keystore can store and how the keystore can store the entries, there are a few different types of keystores in Java: JKS, JCEKS, PKCS12, PKCS11 and DKS. You can find the introduction of these keystore on Oracle's Java Cryptography Architecture description.
Next, we will have an overview of these keystore types.
JKS, Java Key Store. You can find this file at sun.security.provider.JavaKeyStore. This keystore is Java specific, it usually has an extension of jks. This type of keystore can contain private keys and certificates, but it cannot be used to store secret keys. Since it's a Java specific keystore, so it cannot be used in other programming languages. The private keys stored in JKS cannot be extracted in Java.
JCEKS, JCE key store(Java Cryptography Extension KeyStore). It is a super set of JKS with more algorithms supported. It is an enhanced standard added later by Sun. You can find this file at com.sun.crypto.provider.JceKeyStore. This keystore has an extension of jceks. The entries which can be put in the JCEKS keystore are private keys, secret keys and certificates. This keystore provides much stronger protection for stored private keys by using Triple DES encryption.
The provider of JCEKS is SunJCE, it was introduced in Java 1.4. Hence prior to Java 1.4, only JKS can be used.
PKCS12, this is a standard keystore type which can be used in Java and other languages. You can find this keystore implementation at sun.security.pkcs12.PKCS12KeyStore. It usually has an extension of p12 or pfx. You can store private keys, secret keys and certificates on this type. Unlike JKS, the private keys on PKCS12 keystore can be extracted in Java. This type is portable and can be operated with other libraries written in other languages such as C, C++ or C#.
Currently the default keystore type in Java is JKS, i.e the keystore format will be JKS if you don't specify the -storetype while creating keystore with keytool. However, the default keystore type will be changed to PKCS12 in Java 9 because its enhanced compatibility compared to JKS. You can check the default keystore type at $JRE/lib/security/java.security file:
PKCS11, this is a hardware keystore type. It provides an interface for the Java library to connect with hardware keystore devices such as SafeNet's Luna, nCipher or Smart cards. You can find this implementation at sun.security.pkcs11.P11KeyStore. When you load the keystore, you no need to create a specific provider with specific configuration. This keystore can store private keys, secret keys and certificates. When loading the keystore, the entries will be retrieved from the keystore and then converted into software entries.
DKS, Domain KeyStore is a keystore of keystore. It abstracts a collection of keystores that are presented as a single logical keystore. Itself is actually not a keystore. This new keystore type is introduced in Java 8. There is a new class DomainLoadStoreParameter which closely relates to DKS.
This keystore is located at sun.security.provider.DomainKeyStore.java.
Windows-MY, this is a type of keystore on Windows which is managed by the Windows operating system. It stores the user private keys and certificates which can be used to perform cryptographic operations such as signature verification, data encryption etc. Since it's a kind of native keystore, Java doesn't have a general API to access it. Oracle provides a separate API to access the Windows-MY keystore -- SunMSCAPI. The provider class for this API is sun.security.mscapi.SunMSCAPI.
BKS, BoucyCastle keystore, is a keystore format provided the popular third party Java cryptographic library provider -- BouncyCastle. It is a keystore similar to the JKS provided by Oracle JDK. But it supports storing secret key, private key and certificate. It is frequently used in mobile application developments.
In Java, there are a few choices on how a keystore can be processed. Writing the Java code is apparently a choice. Apart from this, a tool comes along with the JDK can also be used, it is called keytool.
keytool is a command line tool. It can be used to create keystore, generate keys, import and export certificates etc. For a full list of commands keytool supports, you can refer to Oracle keytool guideline.
If you are using IBM JDK, there is one more tool which can be used, it is ikeyman. ikeyman is a GUI tool which can provide a straightforward view of the keystore. The entries in the keystore. Keys and certificates can be created using ikeyman as well. It is a tool used frequently by system administrators.
Below are the details of each keystore supported in Java.
- Different types of keystore in Java -- JKS
- Different types of keystore in Java -- JCEKS
- Different types of keystore in Java -- PKCS12
- Different types of keystore in Java -- PKCS11
- Different types of keystore in Java -- DKS
- Different types of keystore in Java -- Windows-MY
- Different types of keystore in Java -- BKS
"Sorry, your password has been in use for 30 days and has expired - you must register a new one." roses "Sorry, too few characters." pretty roses "Sorry, you must use at least one numerical character." 1 pretty rose "Sorry, you cannot use blank spaces." 1prettyrose "Sorry, you must use at least