Tested Reference Implementations

GT.M database encryption comes with a reference implementation that should work "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 12.04 LTS (x86_64)

1.2.0-1.2

1.6-1

libgcrypt 1.4.4-5

 

RHEL 6 (x86_64)

1.1.6

1.4-2

libgcrypt 1.4.4-5

 

RHEL 6 (x86)

1.1.6

1.4-2

libgcrypt 1.4.4-5

 

AIX 6.1 and 7.1

1.1.8 + fix

1.7

libcrypto from OpenSSL - (version >= 1.5)

AES256CFB as implemented by OpenSSL - (version >= 0.9.8)

 

Sun SPARC Solaris 10 (Update 6 and above)

1.1.4 + fix

1.6

libgcrypt 1.4.1

 

HP-UX 11V3 (11.31)

1.1.8 + fix

1.7

libgcrypt 1.4.1

 

SLES 11 (x86_64)

1.1.6-25.30

1.6-8.6

libgcrypt 1.4.4-2.2

 

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:

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. If you wish to continue using Blowfish CFB with 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:

[Note] Note

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.

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, the distribution includes three reference implementations of the plugin, provided by the shared libraries libgtmcrypt_gcrypt_AES256CFB.so, libgtmcrypt_openssl_AES256CFB.so and libgtmcrypt_openssl_BLOWFISHCFB.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. To use Blowfish CFB as the default, you should change the symbolic link after installing GT.M. To use AES CFB as the default, but retain Blowfish CFB for databases migrated from V6.0-000, you can set gtm_crypt_plugin when using those databases. 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.

[Note] Note
  • Encrypted database files are compatible between different endian platforms as long as they use the same key and the same cipher.

  • The sample shell scripts in the reference implementation use the standard shell (/bin/sh).

[Caution] 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.