GT.M database encryption comes with a source reference implementation that should compile "out of the box" with selected encryption packages. You can use this for your initial development and testing with GT.M database encryption. There are many encryption packages. As discussed earlier, FIS neither endorses nor supports any specific cipher or package. For your production use, you take responsibility for choosing, implementing and procuring support for your preferred package. Please remember that a malfunction in your chosen encryption package may result in unrecoverable data and FIS will be unable to help you.
The Plugin Architecture and Interface section below details the reference implementation, which is provided with full source code that you can freely modify for your own use.
For each platform on which GT.M supports encryption, the following table lists the encryption packages and versions against which FIS tested GT.M. Note that FIS tested GT.M for operation against these packages; FIS did not test the robustness of the encryption packages themselves.
|
OS (HW) |
libgpgme |
libgpg-error |
libgcrypt / libcrypto |
GPG |
|---|---|---|---|---|
Ubuntu 18.04 LTS |
1.10.0 |
1.27-unknown |
libgcrypt 1.8.1 |
2.2.4 |
Ubuntu 20.04 LTS |
1.13.1-unknown |
1.37 |
libgcrypt 1.8.5 |
2.2.19 |
Ubuntu 22.04 LTS |
1.16.0-unknown |
1.43 |
libgcrypt 1.9.4 |
2.2.27 |
RHEL 7 |
1.3.2 |
1.12 |
libgcrypt 1.5.3 |
2.0.22 |
RHEL 8 |
1.13.1 |
1.31 |
libgcrypt 1.8.5 |
2.2.20 |
AIX 7.1 |
1.4.0 |
1.11 |
libgcrypt 1.5.1 libcrypto from OpenSSL - (version >= 1.5) AES256CFB as implemented by OpenSSL - (version >= 0.9.8) |
1.4.11 |
Where the table lists a package version number followed by "+ fix" it means that in the process of testing, we identified issues with the package that we fixed. We have provided the source code for our fixes to the upstream package maintainers. If you have a support agreement with FIS, we will share that source code with you, upon request.
The reference implementation uses:
The key ring on disk implemented by GPG.
For public key encryption including the generation of public/private key pairs: RSA as implemented by GPG.
For the cryptographic hash: SHA-512.
For a programmatic interface to GPG: libgpgme.
To provide error messages for GPG: libgpg-error.
For symmetric encryption: AES256CFB implemented by libgcrypt on all platforms.
When a GT.M process first opens a shared library providing an encryption plugin, it ensures that the library resides in $gtm_dist/plugin or a subdirectory thereof. This ensures that any library implementing an encryption plugin requires the same permissions to install, and is protected by the same access controls, as the GT.M installation itself.
On all platforms on which GT.M supports encryption, compiling the source reference implementation produces the shared library plugins, libgtmcrypt_gcrypt_AES256CFB.so and libgtmcrypt_openssl_AES256CFB.so. On installation, platforms other than AIX, libgtmcrypt.so is a symbolic link to libgtmcrypt_gcrypt_AES256CFB.so; on AIX symbolic link is to libgtmcrypt_openssl_AESCFB.so.
![[Note]](images/note.jpg) |
Note |
|---|---|
|
![[Caution]](images/caution.jpg) |
Caution |
|---|---|
During development, in a core dump, FIS noticed a decrypted symmetric database key in buffer released by libgpgme despite the fact that GT.M made an appropriate call to the library to destroy the key. We have communicated this to the upstream developers. This emphasizes again the desirability of strong random numbers as database keys as well as the disabling of core dumps except when required. These strong keys can be created using the gen_sym_key.sh script described in the “Key Management ” section. |
While GT.M dropped support for Blowfish in V6.3-001 and FIS no longer tests it, you may continue to use Blowfish CFB from V6.0-001 through V6.3-000A using the following information. When GT.M database encryption was first released with V5.3-004, the reference implementation for AIX was Blowfish CFB. At that time, there were certain limitations in libgcrypt as a consequence of the port of libgcrypt to the 64-bit environment being less mature than its port to the 32-bit environment (GT.M on AIX is a 64-bit application). Also, Blowfish was used because the implementation of AES on libcrypto from OpenSSL at that time required data to be in chunks that are multiples of 16 bytes. In order to use Blowfish CFB after V6.0-001 via the reference implementation of the plugin, you need to change a symbolic link post-installation, or define the environment variable gtm_crypt_plugin as follows:
If the environment variable gtm_crypt_plugin is defined and provides the path to a shared library relative to $gtm_dist/plugin, GT.M uses $gtm_dist/plugin/$gtm_crypt_plugin as the shared library providing the plugin. For scripts intended to be portable between V6.0-000 and V6.0-001, you can safely set a value for gtm_crypt_plugin, which V6.0-000 ignores.
If $gtm_crypt_plugin is not defined, GT.M expects $gtm_dist/plugin/libgtmcrypt.so to be a symbolic link to a shared library providing the plugin. The expected name of the actual shared library is libgtmcrypt_cryptlib_CIPHER.so (depending on your platform, the actual extension may differ from .so), for example, libgtmcrypt_openssl_AESCFB. GT.M cannot and does not ensure that the cipher is actually AES CFB as implemented by OpenSSL - GT.M uses CIPHER as salt for the hashed key in the database file header, and cryptlib is for your convenience, for example, for troubleshooting. Installing the GT.M distribution creates a default symbolic link.
|
Note |
|---|---|
|
GT.M V6.3-001 dropped support for the Blowfish encryption plugin. To migrate databases from Blowfish CFB to AES CFB requires that the data be extracted and loaded into newly created database files. To minimize the time your application is unavailable, you can deploy your application in a Logical Multi-Site (LMS) configuration, and migrate using a rolling upgrade technique Refer to the Chapter 7: “Database Replication” for more complete documentation. |