Table of Contents
A KeyStore is a protected database of cryptographic keys - private, public, secret. Private keys in a KeyStore have a certificate chain associated with them, which authenticates the corresponding public key - together they form a Key Pair entry - you cannot have just a private key by its own. On the other hand a KeyStore can contain just the certificates from trusted entities.
A Certificate embeds a public key belonging to an entity. It certifies the public key and all the information via digitally signature of another entity (the issuer, e.g. - a person, company, etc.), saying that the embedded public key (and some other information) belongs to the declared entity (the subject) and has some specific value. That is why it is also called a Public Key Certificate. The certificate is usually signed by a trusted Certification Authority (CA) or it can be self signed.
CERTivity can handle X.509 certificates types, both version 1 and 3.
Besides Key Pair and Certificate entries (asymmetric keys) some types of KeyStores can store Secret Keys (symmetric keys) as well.
Hence a KeyStore is a protected collection of Key Pair, Certificate and Secret Keys entries and each such entry is addressable via an unique alias or entry name. KeyStores are stored according to their standards and they are protected by a general password while the Private Keys and Secret Keys are protected by different individual passwords.
CERTivity asks for these passwords when operations are requiring access to the keys. Once a Private key or Secret Key is unlocked it will stay unlocked while the KeyStore is loaded.
CERTivity can manage the following KeyStore types - their main capabilities according to their standard are described below.
Table 5.1. KeyStores capabilities
| Keystore type | Keystore password protection | Supports Secret Key | Aliases Case Sensitive | Provider |
|---|---|---|---|---|
| jks - Java KeyStore (Oracle's KeyStore format) | Yes | No | No - use lower case | Default JCE |
| pkcs12 - Public-Key Cryptography Standards #12 KeyStore (RSA's Personal Information Exchange Syntax Standard) | Yes (for password that is greater than 7 characters, you may need to download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files) | No | Half - Case aware | Bouncy Castle |
| jceks - Java Cryptography Extension KeyStore (More secure version of JKS) | Yes | Yes | No - use lower case | Default JCE |
| bks/bks-v1 - Bouncy Castle KeyStore (Bouncy Castle's version of JKS); | Yes. Note the empty string ("") universal password. If the KeyStore is unlocked using the universal password, and if the password is not changed until saving the KeyStore, the empty string will be set as the KeyStore password when saving. | Yes | Yes | Bouncy Castle |
| uber - Bouncy Castle UBER KeyStore (More secure version of BKS) | Yes | Yes | Yes | Bouncy Castle |
| Windows Root CA | Yes | No | Yes | Default JCE (on Oracle - SunMSCAPI ) |
| Windows User | Yes | Yes | Yes | Default JCE (on Oracle - SunMSCAPI ) |
Please note that PKCS12 KeyStores have no password protection
for their key pair entries.
"Case aware" means that an alias can be defined both with low case and upper case, will be saved as this, but there cannot be two aliases which differ just by the case of their letters.
Working with Windows Root CA KeyStore and Windows User KeyStore are available only on Windows platform and additional confirmation and warning panels will be displayed by the Windows system when installing, deleting, renaming a KeyStore entry. Hence, the second confirmation dialogs are not under the control of CERTivity application.
The BKS/BKS-V1 type of KeyStore allows for being accessed both with the KeyStore password, as well as with the empty string password - this is not under the control of the CERTivity application .
You can use KeyStore examples provided in the distribution kit in
the folder doc/samples/keystore, to test the KeyStore
features.