Data Encryption Keys (DEK) are used by encryption algorithms (typically AES256) to protect data at rest in tablespaces, backups and even datapump exports. Since DEKs are stored with the data, they need to be protected. Master Encryption Keys (MEK) are stored outside the database in local wallets or in an external Keystore, and MEKs are used to encrypt the DEK which provides a separation between the data that is encrypted and an external key.
DEKs are not only found on Tablespaces (TDE), but they are also found in RMAN encrypted backups, Space Efficient Encrypted backups to ZDLRA/Recovery Service and encrypted datapump exports.
The diagram below shows that relationship between MEKs and DEKs.
MEK with a Wallet File
In this first section I am going to talk about how the Oracle Database manages an MEK when using a Wallet file.
Wallet settings
With wallet-based MEKs, the database stores and reads keys from a wallet file on disk (or +ASM or Exascale).
There are 2 parameters in the database (spfile) that help guide the database to the wallet file.
WALLET_ROOT - This replace the "ENCRYPTION_WALLET_LOCATION" parameter that was previous set in the sqlnet.ora file. Having it set at the database level allows multiple databases to independently share the same $ORACLE_HOME. It even allows PDBs to have individual wallet files. When using a wallet file, the WALLET_ROOT points to top directory where the encryption keys will be kept.
TDE_CONFIGURATION - This tells the database what kind of MEK will be used. For wallets you would specify "TDE_CONFIGURATION=FILE". This tells the database to use find the encryption keys in an encryption wallet.
Encryption key location
Within the WALLET_ROOT directory the encryption wallet containing the MEKs, must be stored in a subdirectory named "tde".
Within that directory you will find 2 wallet files
ewallet.p12
- The password-protected wallet (contains keys; required for updates).ewallet.sso
— the auto-login wallet (allowing no password prompt on open); The auto-login wallet can also be created as a “local” autologin wallet bound to a single host.
Database interaction with MEK
Viewing V$ENCRYPTION_WALLET
What you’ll typically see for FILE based wallets:
PDB_NAME WALLET_TYPE STATUS WRL_PARAMETER KEYSTORE
-------------- ----------- ------ ---------------------------- --------
CDB$ROOT AUTOLOGIN OPEN {WALLET_ROOT}/tde NONE
DB23AI_PDB AUTOLOGIN OPEN UNITED
MEK with OKV/OCI KMS
When using an external keystore, the database communicates with the OKV/OCI KMS client libraries installed on the host in order to retrieve the MEKs.
OKV/OCI KMS settings
There are 2 parameters in the database (spfile) that help guide the database to the OKV/OCI KMS installation.
WALLET_ROOT - When using OKV/OCI KMS, the WALLET_ROOT points to top directory where the client install of the OKV/OCI KMS software.
TDE_CONFIGURATION - For OKV/OCI KMS specify "TDE_CONFIGURATION=OKV" or "TDE_CONFIGURATION=HSM". It is possible to combine both wallets and OKV/OCI KMS if there are older keys that still stored a wallet file. In that case you would see "TDE_CONFIGURATION=OKV|FILE" for example, and the database would read older encryption keys from a wallet file along with reading the keys from OKV/OCI MKS.
Encryption key location
Within the WALLET_ROOT directory, the software to communicate with the HSM is typically installed in the "okv" or "hsm" subdirectory. The keys themselves are stored externally, and could be securely cached locally depending on your configuration.
The credential used to access OKV/OCI KMS is typically stored under the /tde
directory in an auto-login wallet. This allows the database to connect to OKV/OCI KMS at startup. The external password store entries (if used) live under /tde_seps
which allows up to manage keys without entering a password.
Database interaction with MEK
OKV/OCI MKS in Practice: What You’ll See
When both FILE and OKV configurations exist (e.g., during migration), you may observe dual rows in V$ENCRYPTION_WALLET
showing the FILE wallet (no active master key) and the active OKV keystore:
PDB_NAME TYPE STATUS WALLET_TYPE WRL_PARAMETER
-------------- ---- ----------------- ----------- ---------------------------
CDB$ROOT FILE OPEN_NO_MASTERKEY AUTOLOGIN {WALLET_ROOT}/tde
CDB$ROOT OKV OPEN OKV
DB23AI_PDB FILE OPEN_NO_MASTERKEY AUTOLOGIN
DB23AI_PDB OKV OPEN OKV
Best Practices & Notes
- Back up only the passworded wallet when using a wallet file. (
ewallet.p12
) and store it securely, separate from database backups. - Use local autologin wallets if you require host binding for additional security.
- When migrating to OKV/OCI KMS, consider a staged approach (
OKV|FILE
) so you can fall back if needed. - Always test wallet/keystore open/close operations and RMAN/Data Pump encryption workflows in lower environments before production.
- Keep client libraries (
liborapkcs.so
and OKV client) patched and consistent across RAC nodes.
Last updated: August 29, 2025
No comments:
Post a Comment