5 General Considerations of Using Transparent Data Encryption

When you use Transparent Data Encryption, you should consider factors such as security, performance, and storage overheads.

Compression and Data Deduplication of Encrypted Data

With tablespace encryption, Oracle Database compresses tables and indexes before encrypting the tablespace.

This ensures that you receive the maximum space and performance benefits from compression, while also receiving the security of encryption at rest. In the CREATE TABLESPACE SQL statement, include both the COMPRESS and ENCRYPT clauses.

With column encryption, Oracle Database compresses the data after it encrypts the column. This means that compression will have minimal effectiveness on encrypted columns. There is one notable exception: if the column is a SecureFiles LOB, and the encryption is implemented with SecureFiles LOB Encryption, and the compression (and possibly deduplication) are implemented with SecureFiles LOB Compression & Deduplication, then compression is performed before encryption. Similar to the CREATE TABLESPACE statement for tablespace encryption, include both the COMPRESS and ENCRYPT clauses.

See Also:

Security Considerations for Transparent Data Encryption

As with all Oracle Database features, you should consider security when you create TDE policies.

Transparent Data Encryption General Security Advice

Security considerations for Transparent Data Encryption (TDE) operate within the broader area of total system security.

Follow these general guidelines:

  • Identify the degrees of sensitivity of data in your database, the protection that they need, and the levels of risk to be addressed. For example, highly sensitive data requiring stronger protection can be encrypted with the AES256 algorithm. A database that is not as sensitive can be protected with no salt or the nomac option to enable performance benefits.

  • Evaluate the costs and benefits that are acceptable to data and keystore protection. Protection of keys determines the type of keystore to be used: auto-login software keystores, password-based software keystores, or hardware keystores.

  • Consider having separate security administrators for TDE and for the database.

  • Consider having a separate and exclusive keystore for TDE.

  • Implement protected back-up procedures for your encrypted data.

Transparent Data Encryption Column Encryption-Specific Advice

Additional security considerations apply to normal database and network operations when using TDE.

Encrypted column data stays encrypted in the data files, undo logs, redo logs, and the buffer cache of the system global area (SGA). However, data is decrypted during expression evaluation, making it possible for decrypted data to appear in the swap file on the disk. Privileged operating system users can potentially view this data.

Column values encrypted using TDE are stored in the data files in encrypted form. However, these data files may still contain some plaintext fragments, called ghost copies, left over by past data operations on the table. This is similar to finding data on the disk after a file was deleted by the operating system.

Managing Security for Plaintext Fragments

You should remove old plaintext fragments that can appear over time.

Old plaintext fragments may be present for some time until the database overwrites the blocks containing such values. If privileged operating system users bypass the access controls of the database, then they might be able to directly access these values in the data file holding the tablespace.

To minimize this risk:

  1. Create a new tablespace in a new data file.

    You can use the CREATE TABLESPACE statement to create this tablespace.

  2. Move the table containing encrypted columns to the new tablespace. You can use the ALTER TABLE.....MOVE statement.

    Repeat this step for all of the objects in the original tablespace.

  3. Drop the original tablespace.

    You can use the DROP TABLESPACE tablespace INCLUDING CONTENTS KEEP DATAFILES statement. Oracle recommends that you securely delete data files using platform-specific utilities.

  4. Use platform-specific and file system-specific utilities to securely delete the old data file. Examples of such utilities include shred (on Linux) and sdelete (on Windows).

Performance and Storage Overhead of Transparent Data Encryption

The performance of Transparent Data Encryption can vary.

Performance Overhead of Transparent Data Encryption

Transparent Data Encryption tablespace encryption has small associated performance overhead.

The actual performance impact on applications can vary. TDE column encryption affects performance only when data is retrieved from or inserted into an encrypted column. No reduction in performance occurs for operations involving unencrypted columns, even if these columns are in a table containing encrypted columns. Accessing data in encrypted columns involves small performance overhead, and the exact overhead you observe can vary.

The total performance overhead depends on the number of encrypted columns and their frequency of access. The columns most appropriate for encryption are those containing the most sensitive data.

Enabling encryption on an existing table results in a full table update like any other ALTER TABLE operation that modifies table characteristics. Keep in mind the potential performance and redo log impact on the database server before enabling encryption on a large existing table.

A table can temporarily become inaccessible for write operations while encryption is being enabled, TDE table keys are being rekeyed, or the encryption algorithm is being changed. You can use online table redefinition to ensure that the table is available for write operations during such procedures.

If you enable TDE column encryption on a very large table, then you may need to increase the redo log size to accommodate the operation.

Encrypting an indexed column takes more time than encrypting a column without indexes. If you must encrypt a column that has an index built on it, you can try dropping the index, encrypting the column with NO SALT, and then re-creating the index.

If you index an encrypted column, then the index is created on the encrypted values. When you query for a value in the encrypted column, Oracle Database transparently encrypts the value used in the SQL query. It then performs an index lookup using the encrypted value.

Note:

If you must perform range scans over indexed, encrypted columns, then use TDE tablespace encryption in place of TDE column encryption.

Storage Overhead of Transparent Data Encryption

TDE tablespace encryption has no storage overhead, but TDE column encryption has some associated storage overhead.

Encrypted column data must have more storage space than plaintext data. In addition, TDE pads out encrypted values to multiples of 16 bytes. This means that if a credit card number requires nine bytes for storage, then an encrypted credit card value will require an additional seven bytes.

Each encrypted value is also associated with a 20-byte integrity check. This does not apply if you have encrypted columns using the NOMAC parameter. If data was encrypted with salt, then each encrypted value requires an additional 16 bytes of storage.

The maximum storage overhead for each encrypted value is from one to 52 bytes.

Modifying Your Applications for Use with Transparent Data Encryption

You can modify your applications to use Transparent Data Encryption.

  1. Configure the software or hardware keystore for TDE, and then set the master encryption key.

    See the following sections for more information:

  2. Verify that the master encryption key was created by querying the KEY_ID column of the V$ENCRYPTION_KEYS view.

  3. Identify the sensitive columns (such as those containing credit card data) that require Transparent Data Encryption protection.

  4. Decide whether to use TDE column encryption or TDE tablespace encryption.

    See the following sections for more information:

  5. Open the keystore.

    See the following sections for more information:

  6. Encrypt the columns or tablespaces.

    See the following sections for more information:

How ALTER SYSTEM and orapki Map to ADMINISTER KEY MANAGEMENT

Many of the clauses from the ALTER SYSTEM statement correspond to the ADMINISTER KEY MANAGEMENT statement.

Table 5-1 compares the Transparent Data Encryption usage of the ALTER SYSTEM statement and the orapki utility from previous releases with the ADMINISTER KEY MANAGEMENT statement.

Table 5-1 How ALTER SYSTEM and orapki Map to ADMINISTER KEY MANAGEMENT

Behavior                       ALTER SYSTEM or orapki                ADMINISTER KEY MANAGEMENT                       

Creating a keystore

For software keystores (called wallets in previous releases):

ALTER SYSTEM SET ENCRYPTION KEY
["certificate_ID"] IDENTIFIED
BY keystore_password;

For hardware keystores, the keystore is available after you configure the hardware security module.

For software keystores:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
'keystore_location' 
IDENTIFIED BY software_keystore_password

For hardware keystores, the keystore is available after you configure the hardware security module.

Creating an auto-login keystore

orapki wallet create -wallet
wallet_location 
-auto_login [-pwd password]

For software keystores:

ADMINISTER KEY MANAGEMENT CREATE [LOCAL]
AUTO_LOGIN KEYSTORE FROM KEYSTORE
'keystore_location' 
IDENTIFIED BY software_keystore_password;

This type of keystore applies to software keystores only.

Opening a keystore

ALTER SYSTEM SET ENCRYPTION
WALLET OPEN IDENTIFIED BY
password;
ADMINISTER KEY MANAGEMENT SET KEYSTORE 
OPEN IDENTIFIED BY keystore_password
[CONTAINER = ALL | CURRENT];

Closing a keystore

ALTER SYSTEM SET ENCRYPTION
WALLET CLOSE IDENTIFIED BY
password;

For both software and hardware keystores:

ADMINISTER KEY MANAGEMENT SET KEYSTORE 
CLOSE IDENTIFIED BY keystore_password
[CONTAINER = ALL | CURRENT];

Migrating from a hardware keystore to a software keystore

Not available

ADMINISTER KEY MANAGEMENT SET ENCRYPTION
KEY IDENTIFIED BY
software_keystore_password 
REVERSE MIGRATE USING "user_id:password"
[WITH BACKUP [USING 'backup_identifier']];

Migrating from a software keystore to a hardware keystore

ALTER SYSTEM SET ENCRYPTION KEY
IDENTIFIED BY
"user_id:password" MIGRATE
USING wallet_password;
ADMINISTER KEY MANAGEMENT SET ENCRYPTION
KEY IDENTIFIED BY "user_id:password"
MIGRATE USING software_keystore_password;

Changing a keystore password

orapki wallet change_pwd
-wallet wallet_location
[-oldpwd password ] 
[-newpwd password]

For password-based software keystores:

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE
PASSWORD IDENTIFIED BY
software_keystore_old_password 
SET software_keystore_new_password
[WITH BACKUP [USING 'backup_identifier']];

For hardware keystores, you close the keystore, change it in the hardware security module interface, and then reopen the keystore.

Backing up a password-based software keystore

Not available

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE
[USING 'backup_identifier'] IDENTIFIED BY
software_keystore_password 
[TO 'keystore_location'];

Merging two software keystores into a third new keystore

Not available

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE
'keystore1_location' [IDENTIFIED BY
software_keystore1_password] 
AND KEYSTORE 'keystore2_location'
[IDENTIFIED BY software_keystore2_password]
INTO NEW KEYSTORE 'keystore3_location'
IDENTIFIED BY software_keystore3_password;

Merging one software keystore into another existing keystore

Not available

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE
'keystore1_location' [IDENTIFIED BY
software_keystore1_password] 
INTO EXISTNG KEYSTORE 'keystore2_location'
IDENTIFIED BY software_keystore2_password
[WITH BACKUP [USING 'backup_identifier']];

Setting or rotating the master encryption key

For software wallets:

ALTER SYSTEM SET ENCRYPTION KEY
["certificate_ID"] IDENTIFIED
BY keystore_password;

For hardware security modules:

ALTER SYSTEM SET ENCRYPTION KEY
IDENTIFIED BY "user_id:password"

Note: The ALTER SYSTEM SET ENCRYPTION KEY statement does not update the V$ENCRYPTION_KEYS dynamic view after you rotate the encryption key.

ADMINISTER KEY MANAGEMENT 
SET ENCRYPTION KEY [USING TAG 'tag']
IDENTIFIED BY keystore_password 
WITH BACKUP [USING 'backup_identifier'] 
[CONTAINER = ALL | CURRENT];

After you rotate the encryption key, the V$ENCRYPTION_KEYS dynamic view is updated.

Creating a master encryption key for later user

Not available

ADMINISTER KEY MANAGEMENT CREATE KEY 
[USING TAG 'tag'] 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier']]
[CONTAINER = (ALL|CURRENT)];

Activating a master encryption key

Not available

ADMINISTER KEY MANAGEMENT USE KEY
'key_identifier' [USING TAG 'tag'] 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier']];

Creating custom tags for master encryption keys

Not available

ADMINISTER KEY MANAGEMENT SET TAG 'tag' 
FOR 'master_key_identifier' 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier']];

Exporting a master encryption key

Not available

ADMINISTER KEY MANAGEMENT 
EXPORT [ENCRYPTION] KEYS 
WITH SECRET "export_secret" 
TO 'file_path' 
IDENTIFIED BY software_keystore_password
[WITH IDENTIFIER IN 
'key_id1', 'key_id2', 'key_idn' | 
(SQL_query)]

Importing a master encryption key

Not available

ADMINISTER KEY MANAGEMENT 
IMPORT [ENCRYPTION] KEYS 
WITH SECRET "import_secret" |  
FROM 'file_name' 
IDENTIFIED BY software_keystore_password
[WITH BACKUP [USING 'backup_identifier']];

Storing Oracle Database secrets in a keystore

Not available

For software keystores:

ADMINISTER KEY MANAGEMENT
ADD SECRET|UPDATE SECRET|DELETE SECRET
"secret" FOR CLIENT 'client_identifier' 
[USING TAG'tag'] 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier'];

For hardware keystores:

ADMINISTER KEY MANAGEMENT
ADD SECRET|UPDATE SECRET|DELETE SECRET
"secret" FOR CLIENT 'client_identifier' 
[USING TAG 'tag'] 
IDENTIFIED BY "user_id:password" 
[WITH BACKUP [USING 'backup_identifier'];

Using Transparent Data Encryption with PKI Encryption

PKI encryption is deprecated, but if you are still using it, then there are several issues you must consider.

Note:

The use of PKI encryption with Transparent Data Encryption is deprecated. To configure Transparent Data Encryption, use the ADMINISTER KEY MANAGEMENT SQL statement.

Software Master Encryption Key Use with PKI Key Pairs

A master encryption key can be an existing key pair from a PKI certificate designated for encryption.

Note the following:

  • If you have already deployed PKI in your organization, then you can use PKI services such as key escrow and recovery. However, encryption using current PKI algorithms requires significantly more system resources than symmetric key encryption. Using a PKI key pair as a master encryption key may result in greater performance degradation when accessing encrypted columns in the database.

  • For PKI-based keys, certificate revocation lists are not enforced because enforcing certificate revocation may lead to losing access to all of the encrypted information in the database. However, you cannot use the same certificate to create the master encryption key again.

TDE Tablespace and Hardware Keystores with PKI Encryption

PKI encryption is a cryptographic system that uses two keys, a public key and a private key, to encrypt data.

You cannot use PKI-based encryption with TDE tablespace encryption or with hardware keystores.

Backup and Recovery of a PKI Key Pair

For software keystores, Transparent Data Encryption supports the use of PKI asymmetric key pairs as master encryption keys for column encryption.

This enables the database to use existing key backup, escrow, and recovery facilities from leading certificate authority vendors.

In current key escrow or recovery systems, the certificate authority with key recovery capabilities typically stores a version of the private key, or a piece of information that helps recover the private key. If the private key is lost, then you can recover the original key and certificate by contacting the certificate authority and initiating a key recovery process.

Typically, the key recovery process is automated and requires the user to present certain authenticating credentials to the certificate authority. TDE puts no restrictions on the key recovery process other than that the recovered key and its associated certificate be a PKCS#12 file that can be imported into an keystore. This requirement is consistent with the key recovery mechanisms of leading certificate authorities.

After obtaining the PKCS#12 file with the original certificate and private key, you must create an empty keystore in the same location as the previous keystore. You can then import the PKCS#12 file into the new keystore by using the same utility. Choose a strong password to protect the keystore.

After you use the ADMINISTER KEY MANAGEMENT statements to create the keystore and import the correct encryption keys, log in to the database and run the following ALTER SYSTEM statement at the SQL prompt to complete the recovery process:

ALTER SYSTEM SET ENCRYPTION KEY "cert_id" IDENTIFIED BY keystore_password;

In this specification:

  • cert_id is the certificate ID of the certificate to be used as the master encryption key.

  • keystore_password is a password that you create.

Note:

You must use the ALTER SYSTEM statement to regenerate encryption keys for PKI key pairs only. This restriction does not apply to non-PKI encryption keys.

Data Loads from External Files to Tables with Encrypted Columns

You can use SQL*Loader to perform data loads from files to tables that have encrypted columns.

Be aware that with SQL*Loader, you cannot include the ENCRYPT clause in the column definition of an external table of the type ORACLE_LOADER, but you can include it in the column definitions of external tables of type ORACLE_DATAPUMP.

  • External tables of type ORACLE_LOADER

    The reason that you cannot include the ENCRYPT clause in the column definitions of external tables of the type ORACLE_LOADER is because the contents of an external table with the ORACLE_LOADER type must come from a user-specified plaintext "backing file," and such plaintext files cannot contain any TDE encrypted data.

    If you use the ENCRYPT clause in the definition of an external table of type ORACLE_LOADER, then when you query the TDE-encrypted column in this external table, the query fails. This is because TDE expects the external data to have been encrypted, and automatically tries to decrypt it on load. This action fails because the "backing file" only contains plaintext.

  • External tables of type ORACLE_DATAPUMP

    You can use TDE column encryption with external tables of type ORACLE_DATAPUMP. This is because for external tables of ORACLE_DATAPUMP type, the "backing file" is always created by Oracle Database(during an unload operation) and thus does have support for being populated with encrypted data.

Transparent Data Encryption and Database Close Operations

You should ensure that the software or hardware keystore is open before you close the database.

The master keys may be required during the database close operation. The database close operation automatically closes the software or hardware keystore.