Transparent Data Encryption (TDE) provides data privacy while the data is at rest in your OpenEdge database, regardless of the location of the database or who has a copy of it.

Controlling access to private data while at rest, stored on disk inside your database, is the core of OpenEdge Transparent Data Encryption. OpenEdge combines cipher algorithms, encryption key lengths, secure storage of encryption keys, and user access controls to your encryption keys to ensure that your data encryption cannot be reversed by anyone other than those who are granted access.

Data at rest means data that is housed physically on computer data storage in any digital form (e.g. cloud storage, file hosting services, databases, data warehouses, spreadsheets, archives, tapes, off-site or cloud backups, mobile devices etc.). Data at rest includes both structured and unstructured data.

Each encrypted database has a single, unique Database Master Key (DMK). The DMK is created and managed by your Database Administrator and stored in your database key store, which is separate from the database. Your key store is an independent and secure entity that provides secure storage of data encryption keys and controls access in the form of user accounts. To facilitate this, encryption for your database objects is managed through encryption policies. You define which database objects are encrypted and the encryption cipher for the object. Policies are stored in your database in a designated Encryption Policy Area. Object policies use virtual data encryption keys derived from your DMK and a cipher that you indicate. The encryption key for each encrypted database object is unique. Database blocks are decrypted when loaded into memory by authorized Progress executable programs. The entire block is encrypted or decrypted, not individual entries within each block. The encryption and decryption is transparent to the connected Progress or SQL92 client. However, the data pulled into shared memory in the buffer pool is not encrypted.

Installing Transparent Data Encryption (TDE)

To enable TDE on an OpenEdge database, the Transparent Data Encryption license must be installed in conjunction with an Enterprise Database license.

What is encryptable

  • Type I Areas: The entire Type I area must be encrypted.
  • Tables, Indexes, LOBs in Type II atorage areas
  • Before Image (BI) files: encrypted by default.
  • After Image (AI) files: encrypted by default.
  • Backup files created with probkup: always encrypted.
  • Binary Dump files: not encrypted by default.
  • Audit Archive: not encrypted by default.

Type II Areas cannot be encrypted at the Area level. Objects (tables, indexes, lobs) are encrypted separately within a Type II storage area. Type II storage areas allow each object to be encrypted or not encrypted as required. Setting up TDE requires some consideration of which tables, indexes, or LOBS (binary or character large objects) should be encrypted. Encryption requires extra CPU processing for encryption and decryption. As such, the entire database be encrypted should not be encrypted, only objects with sensitive information. For more information about encrypting see, Transparent Data Encryption

Enable the OpenEdge database for TDE

To enable an OpenEdge database for Transparent Data Encryption:
  1. Add an encryption policy storage area to the database
  2. Enable the database for encryption
  3. Configure encryption policies
  4. Encrypt existing un-encrypted data
For more information about enabling Transparent Data Encryption, see the following articles:

Passphrase requirements

When enabling the database for TDE, a passphrase must be provided for the user. As with most encryption related operations, a secure password must be chosen, this is known as a passphrase.

When you choose a passphrase for Transparent Data Encryption you must adhere to these constraints:
  • May contain any of the following characters : [a-zA-Z0-9]!@#$%^&*()_+-{}[]|\,./<>?;:<space>
  • A minimum of 8 characters
  • A maximum 1024 characters / 2048 characters since OpenEdge 11
  • Must have at least one numeric character: 0-9
  • Must have at least two alphabetical characters: a-z A-Z
  • Must have at least one special character: . ? ! , ; : - () {} [] *
  • Must have at least one upper case letter: A-Z
  • Must have mixed upper and lower case characters with no consecutive repeating characters

Examples of a valid passphrases are: Admin!234, User!567

When the passphrase does not meet minimum complexity enabling encryption fails. For more information on failing passphrases, see Setting TDE Passphrase generates error (15014).

Databases enabled for TDE must provide the passphrase when starting up the database. When the TDE enabled database is started by a script or service then the database can be configured to not require a passphrase to start:
Guidelines for TDE passphrases:
  1. Each production database passphrases should be distinct from those of other databases and not follow a pattern.
  2. The production database should define both an admin and user passphrase. These passphrases should only be known to the production Database Administrator and the user when manual start is configured.
  3. Use the user passphrase to start production database servers.
    Note: If the autostart feature is used, the 'user ' passphrase blocks non-Database Administrators from maintaining the TDE feature from an absent Database Administrator terminal.
  4. Database Administrators are required to enter the 'admin' passphrase to execute TDE administration commands.
  5. Auditing should be enabled to track the TDE administration actions even when there is no requirement to audit anything else.
  6. Define ABL security administrators and SQL Database Administrators, distinct from TDE Administrators. After TDE is started, a no blank user-id connection for each database or authentication should be considered.
  7. Auditors generally read and scan for information, therefore they can view the current configuration in user persona and cannot change the TDE configuration.
  8. Ensure that the Database Administrator has the keystore admin passphrase and that a process exists for a backup Database Administrator personae in case of emergency.
  9. Ensure a viable production database keystore file backup and restore process that can compensate for emergency restoration to an earlier .ks file that has an old set of passphrases.
  10. Do not use the -newinstance option without your backup and restore processes assuring an exact pairing of database backup version and .ks keystore file version is maintained. This is done in order to de-couple the keystore from the original database and make it bind to the new database GUID with PROUTIL epolicy manage keystore rebind. If a prorest command is issued without the -newinstance parameter, the original database GUID is retained together with the appropriate .ks file and can be accessed without having to rebind.
  11. For additional security, periodically alter the passphrase, particularly on a restored database. This can be done with one or both of the following commands:

    proutil db-name -C epolicy manage keystore userphrase -Passphrase

    proutil db-name -C epolicy manage keystore adminphrase -Passphrase

Cipher and cipher strength used for encryption:

After determining what objects should be encrypted and the passphrase used, another important consideration is the cipher and strength of cipher used for the encryption. The stronger the cipher is the more secure the data is, but the trade off is that this increases the CPU overhead it takes to encrypt and decrypt data. Encryption of data is managed through encryption policies. When a policy is created, you specify what database object (table, index, LOB, or Type I area) is encrypted and the strength of the encryption cipher for the object. If you did not specify a cipher, the default AES_CBC_128, is used. It is important to note that creating a policy does not encrypt existing data; it only indicates that all future writes are encrypted. Fore more information on ciphers available for TDE and how to change the, see What Ciphers available for TDE and how to change them on objects or areas?

Keystore maintenance

After enabling and configuring TDE for a database, there is an extra file that is associated with the database that must backed up or archived for security and restoration purposes. That file is the keystore file (data-base-name.ks).

The goal of Transparent Data Encryption is to encrypt selected database objects. To be successful, the encryption must meet certain industry security practice expectations with regards to encryption key storage, access-controls, and administration. In a practical sense, encryption is only as good as the security of the encryption key storage and its access controls. A keystore implementation is successful when an intruder is unable to coerce it into yielding the stored encryption key values and therefore must resort to a brute-force attack on the encrypted data.

A secure keystore is usually its own entity and provides its own user authentication and authorization. Most low-level keystores use simple passphrase access control; mid-level keystores enforce strong passphrase access controls; high-level keystores use stronger methods of access control such as LDAP, Kerberos, biometrics, or digital certificates. Proper care of your OpenEdge keystore is vital to maintaining access to your encryption-enabled database.

Proper maintenance and care for your keystore involves four tasks:
  1. Backing up your keystore
  2. Modifying passphrases
  3. Rebinding an existing keystore file to a new database GUID
  4. Keystore reconstruction
For more information on keystore maintenance see the following articles:

Common TDE maintenance operations

Management of TDE passphrases:
Restoring and Copying TDE Databases:
Disabling TDE:

Transparent Data Encryption FAQ

The following articles describe frequently asked questions about TDE: