Database Protection

The CORE database is protected at-rest by the system-specific Data Encryption Key (DEKData Encryption Key - the key that encrypts the database. See also - KEK.). This key is permanent. At-rest it is protected by the system-specific Key Encryption Key (KEKKey Encryption Key - Used to encrypt the data encryption key (DEK).) and re-encrypted when its KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). is rotated.

Note
It is a common database protection practice to rotate the KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). and re-encrypt the DEKData Encryption Key - the key that encrypts the database. See also - KEK.. The database itself remains encrypted by the same DEKData Encryption Key - the key that encrypts the database. See also - KEK..

The database protection infrastructure includes three files located in the following folder:

The files are:

• key.data - contains encrypted DEKData Encryption Key - the key that encrypts the database. See also - KEK..
• key.info - specifies the location of KEKKey Encryption Key - Used to encrypt the data encryption key (DEK)., its name and the protection method, and how it should decrypt the DEKData Encryption Key - the key that encrypts the database. See also - KEK..
• key.jks - the default location of KEKKey Encryption Key - Used to encrypt the data encryption key (DEK)..

DEK Metadata

The DEKData Encryption Key - the key that encrypts the database. See also - KEK. is decrypted according to the settings stored in the key.info file:

• The location of KEKKey Encryption Key - Used to encrypt the data encryption key (DEK)., its name in and protection method.
• The algorithm to be used by the obtained KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). to decrypt the DEKData Encryption Key - the key that encrypts the database. See also - KEK..

For example, the default key.info includes the following parameters:

store_file=/var/lib/ekm/data/key/key.jks
store_type=JCEKS
store_password=********************
provider_name=SunJCE
key_name=EKM
algorithm=RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING

Default KEK

By default, CORE keeps the KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). in the passphrase-protected Java keystore (JKSA Java KeyStore (JKS) is a repository of security certificates – either authorization certificates or public key certificates – plus corresponding private keys, used for instance in SSL encryption.). The key, keystore, and its protection are created during the server's bootstrap. During the EKMEnterprise Key Management - previous name of the product. Service start, the system obtains the KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). from its keystore, decrypts the DEKData Encryption Key - the key that encrypts the database. See also - KEK., and uses it to decrypt the rest of the database in the memory.

Rotating KEK in a Server

To replace the default KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). keystore and key, run java -jar <path>/ekmconfig.jar. It updates or creates a keystore with the new KEKKey Encryption Key - Used to encrypt the data encryption key (DEK)., re-encrypts the DEKData Encryption Key - the key that encrypts the database. See also - KEK., and updates the DEKData Encryption Key - the key that encrypts the database. See also - KEK. metadata.

Syntax:

java -jar <path to ekmconfig.jar> -database -protect

-n,--name <new-KEK name>
-p,--provider <new-KEK Java Security Provider name>
-t,--type <new-KEK Java security provider type>
[-a,--algorithm <cypher to be used with the DEK>] (default: RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING)
[-f,--file <new-KEK keystore file name. Applicable to the SunJCE provider>]
[-w,--password <new-KEK keystore password. Applicable to the SunJCE provider>]
[-o,--port <the port specified in the server bootstrap procedure>] (default: 443)

Note
The location of ekmconfig.jar is OS-specific. See Java Security Provider Jar.

Quickstart - Rotating KEK in JKS

In this quickstart, we rotate the KEKKey Encryption Key - Used to encrypt the data encryption key (DEK).:

• Generate a new key using Java security provider: -providername SunJCE, -storetype JCEKS.
• Declare the generated key as the new KEKKey Encryption Key - Used to encrypt the data encryption key (DEK)..
• Instruct it to use the RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING algorithm to encrypt and decrypt the DEKData Encryption Key - the key that encrypts the database. See also - KEK..

Steps:

1. Change your working directory to the location of the new keystore location.
2. Generate a new KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). (myKEK):

keytool -genkeypair -keyalg RSA -keysize 2048 -alias myKEK \
-dname "CN=myCN" keystore ./myKS.jks -storepass myKEK1! \
-providername SunJCE -storetype JCEKS


3. Run the ekmconfig tool (on RHEL platforms):

sudo java -jar /usr/lib64/ekmconfig.jar -database -protect \
-n newKEK -p SunJCE -t JCEKS -f ./newKEK.jks -w ********* \
-a RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING

Note
If the ekmconfig.jar command does not recognize the specified --provider or --type, run the command with the --verbose option. Among the other things, it lists all supported provider names and their keystore types.

Managing KEK in HSM

The default KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). may be replaced ("rotated") by a key in HSMHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. CORE Database Protection using HSM.

The database of a CORE system is:

• Spread across EP and its Partner.
• Replicated among all EPs and Partners.
• At rest, it is encrypted on each server by its DEKData Encryption Key - the key that encrypts the database. See also - KEK..

The DEKData Encryption Key - the key that encrypts the database. See also - KEK. keys are specific to each server and protected by their individual KEKs. If organization policy demands that KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). must be protected by HSMHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing, then the default KEKs of all EP and Partner servers in a cluster must be replaced by keys located in HSMHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing(s).

In such a case, all servers may share the same KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). or use individual KEKs, as shown in the following illustration.

Rotating KEK in HSM

To ensure that DEKData Encryption Key - the key that encrypts the database. See also - KEK.'s metadata is properly updated and DEKData Encryption Key - the key that encrypts the database. See also - KEK. is re-encrypted using the new version of KEKKey Encryption Key - Used to encrypt the data encryption key (DEK)., the key rotation of KEKKey Encryption Key - Used to encrypt the data encryption key (DEK). must follow the same procedure as specified in Rotating KEK in a Server. In particular

1. A new key must be created in HSMHardware Security Module - a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing
2. Each server should execute the java -jar <path to ekmconfig.jar> -database -protect procedure referring to the new key. See details in CORE Database Protection using HSM.