Contents


I encrypted my database! How do I manage my master keys now?

A primer for managing PKCS12 keystores

Comments

What is DB2 native encryption?

With DB2 native encryption, you can encrypt user data at rest in your DB2 database server. This enhancement is easy to implement and has no impact on your existing applications or database schema. The following figure shows a DB2 server that uses DB2 native encryption for data and backup encryption.

Figure 1. The two-tier encryption model
Image shows DB2 server that uses DB2 native encryption
Image shows DB2 server that uses DB2 native encryption

The IBM Global Security Kit (GSKit) is a component used by DB2 for Linux, UNIX, and Windows; and other IBM products for its FIPS 140-2 certified cryptographic capabilities. For more information, see Location of the GSKit libraries.

Starting with GSKit 8.0.50.10, you can store master keys in a PKCS#12 keystore. Prior to this version, only certificates were supported. GSKit is included when you install a DB2 database server product. This tutorial's focus is on storing master keys in a PKCS#12-compliant keystore.

Setting up your DB2 environment for DB2 native encryption

Before you start to use DB2 native encryption, ensure that you are setting the correct path to the GSKit libraries and that you are issuing the correct version of the GSKCapiCmd tool.

Location of the GSKit libraries

The GSKit libraries are automatically installed in your DB2 server during DB2 software installation. Ensure that the path to the GSKit libraries is added to the environment variable in the operating system. The following table shows the correct settings for the appropriate environment variable by operating system.

Operating systemEnvironment variablesPath to the GSKit library
Linux and UNIX 32-bit LD_LIBRARY_PATH, LIBPATH, or SHLIB_PATH
  • $INSTHOME/sqllib/lib32/gskit
Linux and UNIX 64-bit LD_LIBRARY_PATH, LIBPATH, or SHLIB_PATH
  • $INSTHOME/sqllib/lib64/gskit
Windows 32-bit PATH
  • C:\Program Files \IBM\gsk8\lib
Windows 64-bit PATH
  • For 64-bit GSKit libraries:
    C:\Program Files\IBM\gsk8\lib64
  • For 32-bit GSKit libraries:
    C:\Program Files (x86)\IBM\gsk8\lib

Location of the GSKCapiCmd tool

You can use this GSKit command-line tool to manage master keys and keystores. This tool is automatically installed with the DB2 software. The following table lists the directories where you can find the GSKCapiCmd tool that is installed with your DB2 server.

Operating systemLocation
Linux and UNIX 32-bit
  • $INSTHOME/sqllib/gskit/bin/gsk8capicmd
Linux and UNIX 64-bit
  • $INSTHOME/sqllib/gskit/bin/gsk8capicmd_64
Windows 32-bit
  • C:\Program Files\IBM\gsk8\bin\gsk8capicmd.exe
Windows 64-bit
  • For 64-bit GSKCapiCmd tool executable:
    C:\Program Files\IBM\gsk8\bin\gsk8capicmd_64.exe
  • For 32-bit GSKCapiCmd tool executable: C:\Program Files(x86)\IBM\gsk8\bin\gsk8capicmd.exe

Checking the version of the GSKCapiCmd tool

Ensure that you are using the same version of GSKit as your DB2 server by checking the location and version of the tool. If you installed multiple IBM products in the DB2 server, you might end up with multiple copies of this tool.

To check the version of the tool, issue the following command:

gsk8capicmd_64 -version

To check the GSKit libraries version in use, issue the following command:

gsk8ver_64

In 32-bit environments, use the gsk8capicmd and the gsk8ver commands, instead.

PKCS#12 keystore

The PKCS#12 keystore is a local file that stores encryption master keys as well as certificates. In DB2 10.5 Fix Pack 5, DB2 native encryption only supports PKCS12 keystores.

The keystore is always encrypted with a password specified when the keystore is created. The keystore creator is responsible for this password. You must keep this password secret and safeguarded for future use.

All access to the keystore requires this password. You can specify the password with the –pw in the GSKCapiCmd tool. You can also specify the password when you start the DB2 instance with the open keystore option in the db2start command.

Choosing a location for the keystore

Choose a directory on a separate physical device from the device where the table space container files and backup files are stored. Following this guideline prevents access to the keystore in case the disk containing the table space container files is lost or stolen.

A directory in the instance owner's home directory is a good option. The instance directory (/sqllib) should not be used because it might be overwritten during an upgrade. In database partitioned or DB2 pureScale® environments, the keystore must be in a shared location accessible to all members.

Deciding whether to enter a password or use a stash file

In addition to manually entering the password to access the keystore, you can store an obfuscated — not encrypted — copy of the password in a stash file for easy access. You can create it when you create the keystore or generate it after the keystore is created. The file name of the stash file is the same as that of the keystore but it has a .sth extension instead of .p12. Use the -stashed option in the GSKCapiCmd tool to use the stash file instead of entering the password.

Using a password instead of a stash file is more secure. When the password is stored in a stash file, it can be susceptible to attacks. However, specifying the password for each operation places an overhead on the keystore creator to be present every time the password is needed. Consider as an example the option to provide the password with the db2start command, if the database server stops working, the keystore creator must be available to provide the password and restore the access to the encrypted database. You must weight the tradeoff between security and usability and choose the more appropriate option for your DB2 environment.

If you use a stash file, treat this file with the same level of security as the keystore. Remember that access to the stash file allows access to the keystore.

Creating a PKCS#12 keystore

The DB2 instance owner must create the keystore to own it and maintain it. After logging in as the instance owner, invoke the GSKCapiCmd tool with the following options to create the keystore:

gsk8capicmd_64 -keydb -create -db <name> [-pw <passwd>] [-type <pkcs12|p12>] [-stash][-strong]
    [-empty | -populate] [-f]

The following table shows a brief description of the options for creating a keystore.

Table 1. Command options to create a keystore

Option name

Description

-stash

Create a stash file with the password stashed in it.

-strong

Enforce the indicated password is a strong password defined as:

  • The minimum password length is 14 characters.
  • A password must have at least one lowercase character, one uppercase character, and one digit or special character (such as *$#%). A space is classified as a special character.
  • Each character must not occur more than three times in a password.
  • No more than two consecutive characters of the password can be identical.
  • All characters are in the standard ASCII printable character set within the range from 0x20 to 0x7E inclusive.

-empty

Create an empty keystore. This option is the default, and it is sufficient for the purposes of DB2 native encryption.

-populate

Create the keystore with an initial set of predefined trusted certificate authority (CA) certificates.

-f

Force overwriting any existing keystore with the same name.

The following example shows how to create a PKCS#12 keystore with a stash file specifying a strong password:

gsk8capicmd_64 -keydb -create -db keystore.p12 -type pkcs12 -pw TheLong73#Pass$word8 -stash –strong

Throughout this tutorial, the PKCS#12 keystore type and the .p12 as file name extension are always used. In DB2 10.5 Fix Pack 5, DB2 native encryption supports only this type of keystore.

Setting file permissions

One way to enforce security of the keystore and the stash file is by using file system permissions in the operating system. Only the keystore creator must have access to the keystore and the stash file. In DB2 environments, the instance owner must be the keystore creator.

On Linux and UNIX operating systems, you should create the keystore with read and write (rw) permissions only for the instance owner (0600). The rest of the users must have no access.

On the Windows operating system, the keystore is created with the file permissions inherited from the folder where it was created. These permissions are likely to be inappropriate for the keystore, so you should change them. If you are using extended Windows security, then only the DB2ADMNS group should have full control over the file. No one else should have any access, including read access. If you are not using extended security, only the log-on user for the DB2 service account should have full control over the file. In either case, if the local system account is the log-on user for the DB2 service account, then SYSTEM should also have full control over the keystore file.

Relaxing the permissions on the keystore and the stash file might expose the keystore to unauthorized users. Access to the master keys implicitly grants access to the data that was encrypted with these keys.

Generating a master key

The first step of managing a master key is generating the master key itself. A cryptographically secure pseudo-random number generator is usually employed for this task. DB2 database servers support master keys with lengths of 128, 192, and 256 bits for use with AES.

Using the /dev/random special file

The /dev/random special file provides an interface to a built-in random number generator in Linux and UNIX. It is a popular choice for cryptography.

The semantics of this special file vary depending on the operating system, and it's important to consult the related operating system documentation before using it.

The following example shows how to use /dev/random to generate n bytes of random data into the random-data file:

head -c <n> /dev/random > random-data

Where n can be 16, 24, or 32 to generate a master key of length 128, 192, or 256 bits, respectively.

Using the rand command (OpenSSL)

OpenSSL is an open source implementation of the SSL and TLS protocols that is very popular in cryptography.

In Linux, UNIX, and Windows, you can use the rand command for OpenSSL to generate the master key value. This command generates pseudo-random bytes.

The following example shows how to generate n bytes of random data into the random-data file:

openssl rand -out random-data <n>

Where n is 16, 24, 32 and generates a master key of length 128, 192, and 256 bits, respectively. For more information, see the rand command documentation.

Adding a master key to a keystore

You can add a master key to the keystore by inserting a master key or by importing a master key from another keystore.

Choosing effective names for master key labels

When adding a master key, choose an appropriate name for the master label. If a keystore contains many master keys from different databases that are rotated over time, an appropriate master label name allows you to choose the right master key and avoid any confusion. DB2-generated label names have the following format:

DB2_SYSGEN_<instancename>_<databasename>_<timestamp>

As a best practice, use a label name that includes information to identify where the master key is used and when it was first used as shown in this example:

<Business_name>_<instancename>_<databasename>_<timestamp>

With this information, you can easily determine when you should rotate the master key and which database is associated with this master key.

Inserting a master key

To insert a master key into a keystore, invoke the GSKCapiCmd tool with the -secretkey and -add options as follows:

gsk8capicmd_64 -secretkey -add -db <name> [-pw <passwd> | -stashed] [–type <pkcs12|p12>]
    –file <filename> -label <label> [-format <ascii | binary>]

The following example uses the value in the random-data file to insert a master key into the keystore.p12 keystore. The command also specifies a master label name and indicates that the password is stored in the stash file:

gsk8capicmd_64 -secretkey -add -db keystore.p12 -stashed –file random-data –format binary 
    -label mybusiness_db2inst1_db1_2015-03-03

Because the master key is stored in the random-data file, you must delete it to avoid leaving your master key unprotected. The following example removes the random-data file:

rm random-data

Importing a master key

To import a master key from another keystore, invoke the GSKCapiCmd tool with the -cert and -import options as follows:

gsk8capicmd_64 -cert -import –[db <name>|file <filename>] [-pw <passwd> | -stashed] -label <label> 
    -type <pkcs12 | p12> ] –[target <name> ] [-target_pw <passwd>] [-new_label] 
    [-target_type <pkcs12 | p12>]

You must have the temp_keystore.p12 keystore that contains the master key you want to import. For more information about how to create this temporary keystore, see Extracting and exporting master keys.

The following example shows how to import the mybusiness_db2inst1_db1_2015-03-03 master label from the temporary keystore to the target keystore:

gsk8capicmd_64 -cert -import -db temp_keystore.p12 -pw temp0RaryPassw0rd
    -label mybusiness_db2inst1_db1_2015-03-03 -target keystore.p12 
    -target_pw newsitepw

Extracting and exporting master keys

You can extract or export a master key for transfer from one keystore to another. Learn more about these methods and the recommended best practices.

Exporting a master key

To export the master key and label pairs from your current keystore to a remote site, invoke the GSKCapiCmd tool with the -cert and –export options as follows:

gsk8capicmd_64 -cert -export -db <name> [-pw <passwd> | -stashed] -label <label> [-type <pkcs12 | p12>]
    -target <name> [-target_pw <passwd>] [-target_type <pkcs12 | p12>]

The following options indicate the source keystore that contains the master label to export:

-db <name> [-pw <passwd> | -stashed] -label <label>

The following options indicate the target keystore to where the master label is being exported:

-target <name> [-target_pw <passwd>] -target_type <pkcs12 | p12>

For example, if you are setting up high-availability disaster recovery (HADR) and you want to have the same master key in the primary database and the standby database, copy the master key in a secure manner by following these steps:

  1. Export a specific master key and label pair into a temporary PKCS12 keystore.
  2. After exporting the master key to the temp_keystore.p12 PKCS12 keystore, transfer this temporary keystore to the remote site where the standby database resides.
  3. Import the master key and label pair into the remote keystore.

The following example shows how to export the master key for the mybusiness_db2inst1_db1_2015-03-03 master label from the keystore.p12keystore to the temp_keystore.p12 keystore:

gsk8capicmd_64 -cert -export -db keystore.p12 -pw Str0ngPassw0rd
    –label mybusiness_db2inst1_db1_2015-03-03
    -target temp_keystore.p12 -target_pw temp0RaryPassw0rd -target_type pkcs12

Extracting a master key

Another option to transfer the master key and label pairs between keystores is to extract the master key itself to a file in binary or ASCII format.

To extract the master key, invoke the GSKCapiCmd tool with the –secretkey and –extract options:

gsk8capicmd_64 -secretkey -extract -db <name> [-pw <passwd> | -stashed] -label <label>
    -file <name> [-format <ascii | binary>]

The following example shows how to extract the master key for the mybusiness_db2inst1_db1_2015-03-03 master label to the keymaterial file in binary format:

gsk8capicmd_64 -secretkey -extract -db keystore.p12 -label mybusiness_db2inst1_db1_2015-03-03 
    -file keymaterial -format binary

Listing all the master labels in the keystore

To list all of the master labels for certificates and master keys stored in a specific keystore, invoke the GSKCapiCmd tool with the -cert and -list options:

gsk8capicmd_64 -cert -list [<all | personal | CA>] {-db <name>} [-pw <passwd> | -stashed]
    [-type <pkcs12|p12>]

The following example shows the list of all master labels for the keystore.p12 keystore:

gsk8capicmd_64 -cert -list all -db keystore.p12 -stashed
     Certificates found
     * default, - personal, ! trusted, # secret key
     # mybusiness_db2inst1_db1_2015-03-03
     # mybusiness_db2inst1_db1_2014-12-03 
     # mybusiness_db2inst1_db1_2014-09-03

Example for transferring master keys between two DB2 servers

There are several situations where you need to transfer a master key between DB2 servers, such as restoring an encrypted database backup on a different DB2 server or setting up HADR in your DB2 environment.

Let's assume you want to have the same master key in db2serverA and db2serverB. Also, you want each DB2 server to have its own keystore. The following table shows the actions to perform on each DB2 server to securely transport a master key from db2serverA to db2serverB.

Actions to transfer a master key
db2serverA
  1. Create the keystore:
    gsk8capicmd_64 -keydb –create -db keystoreA.p12 –type pkcs12 -stash
  2. Generate the random data that will be used to create the master key:
    head -c 32 /dev/random > /tmp/randfile
  3. Insert the random data into the keystore indicating the master label name:
    gsk8capicmd_64 -secretkey -add -db keystoreA.p12 -stashed –label mybusiness_db2inst1_db1_2015-03-03
       –file /tmp/randfile
  4. Verify that the master key was inserted:
    gsk8capicmd_64 -cert -list all -db keystore.p12 –stashed
     Certificates found
     * default, - personal, ! trusted, # master key
     #mybusiness_instA_dbA_2015-03-03
  5. Delete the random data file:
    rm /tmp/randfile
  6. Securely export the master key to a temporary keystore:
    gsk8capicmd_64 -cert -export -db keystoreA.p12 -stashed -label mybusiness_instA_dbA_2015-03-03
       -file temp_keystore.p12 –target_type pkcs12 -target_pw Str0ngPassw0rd
  7. Copy the temporary keystore to db2serverB. The following example uses the scp command:
    scp temp_keystore.p12 db2serverB:/tmp/temp_keystore.p12
db2serverB
  1. Create the keystore:
    gsk8capicmd_64 -keydb –create -db keystoreB.p12 –type pkcs12 -stash
  2. Import the master key from db2serverA:
    gsk8capicmd_64 -cert -import -db /tmp/temp_keystore.p12 -pw Str0ngPassw0rd
       -label mybusiness_instA_dbA_2015-03-03 -target keystoreB.p12 -stashed
  3. Verify that the master key was inserted:
    gsk8capicmd_64 -cert -list all -db keystoreB.p12 –stashed
     Certificates found
     * default, - personal, ! trusted, # master key
     # mybusiness_instA_dbA_2015-03-03
  4. Delete the temporary keystore
    rm /tmp/temp_keystore.p12

Digging deeper into the GSKCapiCmd tool

Learning more details and additional options available for this tool gives you more choices when managing your master keys.

Common GSKit command-line utility options

The commands in the GSKCapiCmd tool have some common options. The following table describes the most important common ones.

Option nameDescription
-db <name> Indicates the file name of the keystore.
-pw <passwd> | -stashed Specifies the required password or stash file to access the keystore. If this option is omitted, the tool prompts for the password.
-label <label> Indicates the name of the master key.
-format <ascii | binary>
Specifies whether the format of the master key is in binary or Base64 encoded ASCII in commands that extracts or inserts a master key or certificate from the keystore. When inserting a new master key, the format option should match the format of the input file. When inserting a master key extracted from another keystore, you must specify the same format option used to extract the master key. Master keys generated by DB2 always use the binary format on insertion.
-type | target_type
<cms | kdb| pkcs12 | p12 | pkcs7 | pkcs11>
Specifies the type of keystore when creating a keystore and exporting or importing master keys. This option is optional. If the option is omitted the tool infers the type from the keystore file name extension. The supported file name extensions are .cms, .kdb, .pkcs12, .p12, .pkcs7, and .pkcs11. For example, the tools infers the PKCS12 keystore type from the .p12 file name extension. If you do not specify any of the supported extensions, you must specify the -type option on all commands so the correct keystore type is used.
Use only the pkcs12 type. The cms, kdb, pkcs7 and pkcs11 types are not compliant with PKCS12 and are not supported by DB2 native encryption as of DB2 10.5 Fix Pack 5.

Interoperability issues

It is important to note that when multiple installations of GSKit exist on the same DB2 server, some interoperability issues might arise because the GSKCapiCmd tool is using one version and referencing the GSKit libraries of a different version. The interoperability issues might lead to unpredictable behavior, and the tool might return error messages. The following error messages are examples of some of the runtime errors that can occur:

  • gsk8capicmd_64: relocation error: gsk8capicmd_64: symbol _ZTV9GSKBuffer, version gsk8 not defined in file libgsk8cms_64.so with link time reference
  • gsk8capicmd_64: Symbol `_ZTV15GSKASNNamedBits' has different size in shared object, consider re-linking
  • gsk8capicmd_64: Symbol `_ZTV21GSKASNGeneralizedTime' has different size in shared object, consider re-linking

To resolve these errors, ensure that the GSKCapiCmd tool is loading the correct version of GSKit libraries by setting the path environment variables to the corresponding value for the operating system.

Enabling FIPS mode

You can run the GSKCapiCmd tool in Federal Information Processing Standards (FIPS) mode. In this mode, the tool initializes the underlying cryptographic provider in FIPS mode so it uses only algorithms that are FIPS 140-2 validated.

The DB2 server runs all its cryptographic functions in FIPS mode. You should always enable FIPS mode when managing your keystore with the GSKCapiCmd tool. To enable or disable FIPS mode by force, use the –fips option as follows:

gsk8capicmd_64 -fips [<true>|<false>] …

If you specify –fips true and the provider cannot be initialized in FIPS mode, the command that you issue with the GSKCapiCmd tool fails. If you specify –fips false or you do not specify the –fips option and the provider cannot be initialized in FIPS mode, the tool tries to carry on with the command in a non-FIPS mode.

In addition to managing master keys, you can use the GSKCapiCmd tool to manage certificates and certificate requests within a keystore. For more information, see the GSKCapiCmd Users Guide

Managing keystores

Besides inserting new master keys, you might need to change the password that is encrypting the keystore or to back up the keystore and the stash file as part of managing the lifecycle of a keystore.

Changing password for a keystore

Company policies or compliance regulations might dictate changing the password used to encrypt the keystore on a regular basis. In this situation, you must change the password regardless of whether you are using a stash file.

You must be able to associate a previous backup of a keystore and the required password for that keystore. Imagine restoring a keystore that has used 23 passwords. Choose a method that allows you to identify the password and the time when it was valid.

A simple method:

  1. Change the password.
  2. Back up the keystore. Change the name of the backup file to include the date of this change.
  3. If you are using a stash file, back up the stash file as well. Change the name of the stash file to also include the same date.
  4. Add the new password and the date of this change to your records.

Generating the stash file

The stash file is automatically generated when you create the keystore. However, there are several scenarios when you want to create a stash file. For example, if you are not using a stash file and you want to start using one or if the original stash file is no longer available due to accidental delete or victim of gremlins.

Assuming that you know the password used to encrypt the keystore, you can easily create a stash file by issuing the following command:

gsk8capicmd_64 -keydb -stashpw -db <name> [-pw <passwd>]

The following example shows how to create a stash file for the keystore.p12 keystore:

gsk8capicmd_64 -keydb -stashpw -db keystore.p12 -pw TheLong73#Pass$word8

This command creates the keystore.sth stash file in the current directory. Ensure the permission of the stash file give access to only the keystore creator. For more information, see Setting file permissions.

Backing up and restoring a keystore

Maintaining backups of the keystore, the password used to encrypt the keystore, and the stash file is critical to the successful and long-term use of data encryption. Failure to maintain this information can result in all of your encrypted data becoming inaccessible.

The master key lengths used in DB2 native encryption are of sufficient strength to preclude brute-force guessing. If you encrypt your DB2 database backups, you cannot restore them without having access to the keystore.

Maintaining backups of the keystore is so critical that each backup of the keystore must be kept. The reason is that you might need the majority of the master keys in the keystore for archival purposes. For old master keys you rotated, you need them to restore an old DB2 database backup. Considering that old master keys are not used very often, any corruption might go unnoticed for some time. The solution is to have multiple backups of the keystore because a backup is the only alternative to find a valid master key.

If you change the password for the keystore, you must keep a record of the password used to access backed-up keystores. For more information, see Changing password for a keystore. Keep this record of the password to access the keystore in a separate location from the keystore backup.

If you use a stash file, you can optionally back it up. You can always create the stash file as long as you know the password — especially when you must know the value used for an old backup of the keystore. Keep the backup for the stash file in a different location from the backup of the keystore, so if either the keystore or stash file backup is compromised, only one of them is accessible and your data is still protected.

Managing master keys

Additional operations to manage your master keys require that you know how to determine the size of your keystore and deleting a master key in a keystore.

Calculating the size of a master key in your keystore

There are two ways to determine the size of a master key in the keystore. The recommended option is to extract the master key to a temporary file and then check the size of this temporary file.

The following example shows how to extract the master key with the mybusiness_db2inst1_db1_2015-03-03 label from the keystore.p12 keystore to the masterkeyfile temporary file:

gsk8capicmd_64 -secretkey -extract -db keystore.p12 -format binary
    -label mybusiness_db2inst1_db1_2015-03-03 -file masterkeyfile -stashed

The following example shows how to check the file size of the masterkeyfile temporary key file:

ls -l masterkeyfile
-rw-r--r-- 1 user group 32 2015-02-04 15:24 masterkeyfile

In the command output, the file size is 32 bytes. Therefore, the size of the master key associated with the mybusiness_db2inst1_db1_2015-03-03 label is 32 bytes or 256 bits.

Remember to remove the temporary master key file after you determine the file size:

rm masterkeyfile

Alternatively, you can calculate the size from the output of the GSKCapiCmd tool with the -cert and -details options:

gsk8capicmd_64 -cert -details [-file <name>]
    {-db <name> -type <pkcs12 | p12>} [-pw <passwd> | -stashed] -label <label>

The output of this command is an hex dump of the master key. You have to manually count the bytes in this output to calculate the master key size. The following example shows how to display the hex dump of the master key associated to the mybusiness_db2inst1_db1_2015-03-03 label in the keystore.p12 keystore:

gsk8capicmd_64 -cert -details -label mybusiness_db2inst1_db1_2015-03-03 -db keystore.p12 -stashed
 Label : mybusiness_db2inst1_db1_2015-03-03 
 master key 
  4B A7 1D FA 6A 3B 39 A0 91 84 9E 7F 3F 46 2E 49
  10 0F 0F BE F1 E3 D6 CE 06 C9 A8 0B 85 A3 61 8E

Counting the bits of the command output in this example shows that the size of the master key is 256 bits.

Deleting a master key from a keystore

Most of the time, you should keep all the master key and label pairs from the keystore. In a DB2 environment, deleting a master key can lead to future problems. If a master key is deleted, the DB2 backup images and log files that were encrypted using that master key become inaccessible. Suffice to say, extreme caution should always be exercised when deciding whether to delete a master key and label pair.

To delete a master key, invoke the GSKCapiCmd tool with the following options:

gsk8capicmd_64 -cert -delete {-db <name> -type <pkcs12 | p12>} [-pw <passwd> | -stashed]
    -label <label>

In certain scenarios, it might make sense to delete a master key and label pair. For example, if you insert a master key in the ASCII format and you want to change the master key to binary format, you need to remove the master key and then insert again in binary format.

The following command shows how to remove the master key associated with the mybusiness_db2inst1_db1_2015-03-03 master label in the keystore.p12 keystore:

gsk8capicmd_64 -cert -delete -db keystore.p12 -pw Str0ngPassw0rd -label mybusiness_db2inst1_db1_2015-03-03

Conclusion

Now that you know how to perform careful actions to generate a master key, manage your keystore, manage your master keys, maintain your keystores and stash file, and what are the best practices for all these actions, you can ensure a successful use of DB2 native encryption and keep your DB2 databases safe and protected.


Downloadable resources


Related topic


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=1002356
ArticleTitle=I encrypted my database! How do I manage my master keys now?
publish-date=04022015