11 Frequently Asked Questions About Transparent Data Encryption

Users frequently have questions about transparency and performance issues with Transparent Data Encryption.

Parent topic: Using Transparent Data Encryption

11.1 Transparency Questions About Transparent Data Encryption

Transparent Data encryption handles transparency in data in a variety of ways.

Security auditors occasionally ask detailed questions about the encryption used by Transparent Data Encryption (TDE). They request information about TDE keys, algorithms, lengths, and keystores and then directly compare to requirements of regulations such as PCI-DSS. This topic contains important details about TDE encryption and key management. This information is current as of Oracle Database 12c (12.1.0.2). It is intended to help TDE customers respond to auditor questions quickly and accurately.

  1. Is Transparent Data Encryption compatible with my application software?

    Transparent Data Encryption is compatible with applications by default because it does not alter the inbound SQL statements or the outbound SQL query results. Oracle executes internal testing and validation of certain Oracle and third-party application software to capture helpful deployment tips or scripts, and to evaluate performance profiles.

    Be aware of the difference between Transparent Data Encryption and the DBMS_CRYPTO PL/SQL package. This package is intended for different customer use cases. It is an API and toolkit solution and as such, it is non-transparent.

  2. Is Transparent Data Encryption compatible with other Oracle Database tools and technologies that I am using?

    One of the chief benefits of Transparent Data Encryption is its integration with frequently used Oracle Database tools and technologies such as high-availability clusters, storage compression, backup compression, data movement, database backup and restore, and database replication. Specific Oracle technologies that are integrated directly with Transparent Data Encryption include Oracle Real Application Clusters (Oracle RAC), Oracle Recovery Manager (RMAN), Oracle Data Guard, Advanced Compression, Oracle Data Pump, and Oracle GoldenGate, among others. Transparent Data Encryption also has special points of integration with Oracle Exadata that fully use unique features of Oracle-engineered systems.

    Transparent Data Encryption also works easily with security features of the Oracle Database. With Transparent Data Encryption, privilege grants, roles, Oracle Database Vault realms, Virtual Private Database policies, and Oracle Label Security labels remain in effect. You can use these and other security features in tandem with Transparent Data Encryption encryption.

  3. Are there any known Transparent Data Encryption limitations or incompatibilities?

    • TDE column encryption: TDE column encryption encrypts and decrypts data transparently when data passes through the SQL layer. Some features of Oracle will bypass the SQL layer, and hence cannot benefit from TDE column encryption. The following are known database features that TDE column encryption does not support, and their relevant software version numbers:

      • Materialized View Logs (not supported prior to Oracle Database 11g release 2)

      • Synchronous and asynchronous change data capture for data warehousing (CDC)

      • Transportable Tablespaces

      • LOBs

      Note that Secure Files were introduced in Oracle Database 11g release 1, so it is not supported with TDE column encryption prior to that release

    • TDE tablespace encryption: TDE tablespace encryption encrypts all content that is stored in the tablespace at the block level in storage, and it generally does not conflict with other database features. TDE tablespace encryption does not have any of the limitations that TDE column encryption has. However, you can use full transportable tablespaces (TTS) with Oracle Data Pump compression and encryption when going from a TDE-encrypted source to a TDE-encrypted destination. You must have an Oracle Database release 12c or later database instance available so that you can use its key export or keystore (wallet) merge capabilities to get the correct master encryption key to the destination database host without having to overwrite the original Oracle wallet file. This process is subject to the standard TTS limitations, and you must remember to check for compatible endianness.

  4. What types of keys and algorithms does TDE use?

    TDE uses a two-tier key architecture:
    • Data Encryption Keys (DEKs): Used to encrypt individual columns or tablespaces. Supported algorithms: AES128, AES192, AES256, 3DES168 (deprecated), ARIA (128, 192, 256), GOST256, and SEED128. The default for column encryption is AES192 (CBC mode). The default for tablespace encryption is AES128 (CFB mode). Oracle recommends AES256 for both.
    • Master Encryption Keys (MEKs): Used to encrypt the DEKs. Stored in the TDE keystore (wallet or external key manager). The default algorithm is AES256 in CBC mode. Additional algorithms (ARIA256, SEED128, GOST256) are available depending on the cryptographic provider.

    When using the next-generation provider in FIPS 140-3 mode, 3DES168 is desupported for DEKs. When using the next-generation provider in any mode, ARIA and SEED are not supported for MEKs. In FIPS mode (both FIPS 140-2 and FIPS 140-3), only AES128, AES192, and AES256 are available for TDE operations. Oracle recommends AES256 for both DEKs and MEKs, as it provides the broadest provider compatibility and all modes of symmetric encryption using AES256 are considered quantum resistant.

  5. Does the choice of cryptographic provider affect my existing TDE-encrypted data?

    Existing encrypted data remains accessible as long as the encryption algorithm used is supported by the active cryptographic provider and FIPS mode. If you switch to the next-generation provider in FIPS 140-3 mode, any data encrypted with 3DES168 may become inaccessible. Re-encrypt such data with an AES algorithm before switching providers.

    Similarly, if your TDE master encryption key uses ARIA256 or SEED128, you must rekey to AES256 before switching to the next-generation provider. Rekeying the master key does not require re-encrypting the data; only the DEK wrappers are re-encrypted with the new MEK.

  6. How do I check and upgrade my TDE wallet encryption?
    To check what encryption algorithm your wallet uses:
    openssl pkcs12 -info -in ./ewallet.p12 -nodes
    Wallets created before Oracle Database 19.22 may use 3DES encryption. To convert to AES-256:
    orapki wallet convert -wallet wallet_location -compat_v12

    The converted wallet is compatible with both the legacy provider and the next-generation provider.

  7. How are Oracle keystores containing master encryption keys protected?

    There are three different types of keystore to consider when you use an Oracle wallet as the keystore for master encryption keys: password-based, auto-login, and local auto-login. All of these keystore externalize master encryption keys, so they are separate from TDE-encrypted data. Oracle recommends that you place wallet files in local or network directories that are protected by tight file permissions and other security measures.

    The password-based wallet is an encrypted key storage file (ewallet.p12) that follows the PKCS #12 standard. It is encrypted by a password-derived key according to the PKCS #5 standard. A human user must enter a command containing the password for the database to open the wallet, decrypt its contents, and gain access to keys. The password-based wallet is the default keystore for TDE master keys. In the past, it was encrypted using the 3DES168 encryption algorithm and CBC operating mode. The orapki command convert wallet enables you to convert password-based wallets to AES256 and CBC operating mode. Oracle Database Security Guide provides details about using orapki to convert wallets.

    Auto-login wallets (cwallet.sso) optionally are derived from standard password-based wallets for special cases where automatic startup of the database is required with no human interaction to enter a wallet password. When using auto-login wallet, the master password-based wallet must be preserved because it is needed to rekey the master encryption key. In addition to the best practice of storing auto-login wallet in a local or network directory that is protected by tight file permissions, the file contents are scrambled by the database using a proprietary method for added security. A slight variation on the auto-login wallet called local auto-login wallet has similar behavior. One notable difference with local auto-login wallet is that its contents are scrambled using additional factors taken from the host machine where the file was created. This renders the local auto-login wallet unusable on other host machines. Details of the host factors and scrambling technique are proprietary.

  8. Do I need to convert my wallet before switching to the next-generation provider?

    If your TDE keystore file (ewallet.p12) uses 3DES encryption for the PKCS#12 container and you plan to use the next-generation provider in FIPS 140-3 mode, you must convert the wallet encryption to AES-256 before enabling FIPS 140-3.

    Wallets created before Oracle Database 19.22 are likely encrypted with 3DES. Wallets created from 19.22 onward use AES-256 by default.

    To check your wallet encryption:
    openssl pkcs12 -info -in ./ewallet.p12 -nodes
    To convert the wallet:
    orapki wallet convert -wallet wallet_location -compat_v12

    This converts the container encryption from 3DES to AES-256 without affecting the keys or certificates inside the wallet. The converted wallet is compatible with both the legacy provider and the next-generation provider.

    If you are using the next-generation provider in non-FIPS mode, wallet conversion is recommended but not strictly required.

    The wallet passphrase can be up to 128 bytes.

  9. What is Oracle Key Vault and how does it manage TDE master keys?

    Oracle Key Vault centrally manages TDE master keys, Oracle wallets, Java keystores, and more. It helps you to take control of proliferating keys and key storage files. It includes optimizations specifically for TDE and other components of the Oracle stack. For more information about using Oracle Key Vault with TDE, see the product pages on Oracle Technology Network and Oracle Key Vault Administrator's Guide .

Parent topic: Frequently Asked Questions About Transparent Data Encryption

11.2 Performance Questions About Transparent Data Encryption

There are several performance issues to consider when using Transparent Data Encryption.

  1. What is the typical performance overhead from Transparent Data Encryption?

    There are many different variables involved in the creation of an accurate Transparent Data Encryption performance test. The results can vary depending on the test environment, test case or workload, measurement metrics or methods, and so on. Oracle cannot guarantee a specific performance overhead percentage that can apply in all possible scenarios. In practice, the performance tests by many Transparent Data Encryption customers are often in the low single digits as a percentage, but that is not universally the case.

    If possible, use Oracle Real Application Testing (Oracle RAT) to capture a real production workload and then replay it against Transparent Data Encryption to get a true indication of the performance overhead that the you can expect within your environment.

  2. How can I tune for optimal Transparent Data Encryption performance?

    • TDE column encryption:

      • Limit the crypto processing by only encrypting the subset of columns that are strictly required to be protected. In addition, turn off the optional integrity checking feature.

      • After you apply column encryption, rebuild the column indexes.

    • TDE tablespace encryption: TDE tablespace encryption improves performance by caching unencrypted data in memory in the SGA buffer cache. This feature reduces the number of crypto operations that must be performed when users run SELECT queries, which draw from the SGA instead of drawing from disk. (Drawing from disk forces the database to perform decrypt operations.) Ensure that the size of the SGA buffer cache is large enough to take full advantage of this performance optimization.

      Another major performance boost comes from using hardware and software that supports CPU-based cryptographic acceleration available in Intel AES-NI and Oracle SPARC T4/T5. To take advantage of this feature, you must be running a recent version of the database, have a recent version of the operating system installed, and be using hardware that includes crypto acceleration circuitry within its CPUs/cores.

      Database compression further speeds up Transparent Data Encryption performance because the crypto processing occurs on data that already is compressed, resulting in less total data to encrypt and decrypt.

    • In general:

      • Ensure that you have applied the latest patches, which you can download from My Oracle Support at

        https://support.oracle.com/portal/

      • When you specify an encryption algorithm, remember that AES is slightly faster than 3DES. Use AES128 where possible. Be aware that the performance benefit is small.

      • Use Exadata (described in Oracle Database Testing Guide), which includes additional performance benefits.

  3. Are there specific issues that may slow down TDE performance, and if so, how do I avoid them?

    TDE tablespace performance is slower if the database cannot use CPU-based hardware acceleration on the host machine due to factors such as older hardware, an older database version, or an older operating system.

    Note the following with regard to specific database workloads:

    • Encrypting the whole data set at once (for example, while doing “Bulk Data Load" into an Oracle data warehouse): Lower crypto performance has been observed during bulk load of new data into the database or data warehouse. New data cannot be cached in SGA, so TDE tablespace encryption performance optimizations are bypassed. Hence, Transparent Data Encryption has no bonus performance benefits in this type of operation.

      Follow these guidelines:

      • Ensure that the database is running on servers with CPU-based cryptographic acceleration. This accelerates not only decrypt operations, but also encrypt operations as well (for loading new data). Take the crypto processing out of band by pre-encrypting the data set and then using Transportable Tablespaces (TTS) to load into the database. Try to parallelize this procedure where possible. This requires the database instance to copy the required TDE key to the keystore on the destination database. The procedure may not be feasible when there is a fixed time window for encryption and loading, and these must be done serially.

      • Consider using TDE column encryption. Encrypt only the handful of sensitive regulated columns instead of encrypting an entire tablespace.

    • Decrypting an entire data set at once (for example, while performing a full table scan by reading directly from disk, with no reading from SGA):

      Lower crypto performance is observed when running full table scan queries where data is read directly from storage. Certain performance optimizations of TDE tablespace encryption are bypassed (no caching). Hence, Transparent Data Encryption has no bonus performance benefits in this type of operation.

      Follow these guidelines:

      • Ensure that the database is running on servers with CPU-based cryptographic acceleration.

      • Retest the full table scan queries with a larger SGA size to measure performance when data is read from cache. Try setting the Oracle event number 10949 to disable direct path read.

      • Partition the database so that less data is scanned by full table scan operations. Production databases often use partitioning for this kind of scenario (that is, to limit the total amount of data scanned).

      • Consider using TDE column encryption. Encrypt only the handful of sensitive regulated columns instead of encrypting an entire tablespace.

Related Topics

Parent topic: Frequently Asked Questions About Transparent Data Encryption