In this blog series, we’ve been building a practical understanding of Oracle Transparent Data Encryption (TDE) from both a security and operational perspective. In the first blog, we introduced what TDE is and why it plays such a critical role in protecting data at rest. In the second, we explored the often-misunderstood licensing implications that influence where and how TDE can be used. The third blog focused on the added complexity TDE introduces in hybrid cloud architectures, particularly when encryption capabilities differ between environments.
Blog
Oracle Transparent Data Encryption (TDE) Wallet Setup
This fourth blog in our TDE series shifts the focus to implementation, specifically the setup and management of TDE Wallets (keystores). Whether you're implementing TDE for the first time or upgrading to Oracle 26ai, understanding wallet management is essential to avoid real-world issues and maintain both security and database continuity.
Blog 1 - What makes hybrid environments hard
Blog 2 - What is Oracle TDE
Blog 3 - TDE licensing - when you're allowed to use it
This blog - Best practice TDE wallet creation & management
1. Understanding TDE Wallets and Keystores
A TDE wallet (also called a keystore) is a password-protected container that stores the master encryption keys used by TDE. These master keys encrypt and decrypt the table encryption keys and tablespace encryption keys that actually protect your data.
Types of TDE Wallets
Oracle Database supports three primary types of TDE wallets, each with different security and usability characteristics:
1. Password-Protected Wallet (ewallet.p12)
• File name: ewallet.p12 (PKCS#12 standard)
• Requires manual password entry to open the wallet
• Must be explicitly opened after each database startup
• Highest security option as it prevents automatic access
• Required for master key operations (rotation, rekeying)
2. Auto-Login Wallet (cwallet.sso)
• File name: cwallet.sso (Single Sign-On)
• Opens automatically on database startup without a password
• Can be used on multiple machines
• Created from a password-protected wallet
• Important: You must retain the ewallet.p12 file for key management operations
3. Local Auto-Login Wallet
• Similar to auto-login but with additional machine binding
• Can only be opened on the machine where it was created
• Uses host-specific factors for additional security
• Recommended for production environments requiring both convenience and security
2. Step-by-Step TDE Wallet Setup
Setting up TDE involves several key steps. Here's a comprehensive guide to configure TDE in your Oracle Database environment.
Step 1: Configure Initialisation Parameters
Before creating any keystores, you must configure the WALLET_ROOT and TDE_CONFIGURATION parameters:
-- Set wallet root directory
ALTER SYSTEM SET WALLET_ROOT='/u01/app/oracle/wallet' SCOPE=SPFILE;
-- Configure TDE to use file-based keystore
ALTER SYSTEM SET TDE_CONFIGURATION='KEYSTORE_CONFIGURATION=FILE' SCOPE=SPFILE;
-- Restart the database for changes to take effect
Important: The TDE wallet must be stored in a subdirectory named 'tde' under WALLET_ROOT. Oracle Database will automatically create this directory structure when you create the keystore.
Step 2: Create the Password-Protected Keystore
-- Create the TDE keystore directory (if not automatically created)
!mkdir -p /u01/app/oracle/wallet/tde
-- Create the password-protected keystore
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY 'YourSecurePassword';
Critical: Never forget your wallet password! Without it, you cannot perform key management operations or recover your data. Store the password securely in your organisation's password vault.
Step 3: Open the Keystore
-- Open the keystore for all containers (CDB and all PDBs)
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY 'YourSecurePassword' CONTAINER=ALL;
Step 4: Set the Master Encryption Key
-- Create the master encryption key with backup
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY 'YourSecurePassword' WITH BACKUP CONTAINER=ALL;
Step 5: Create Auto-Login Wallet (Optional)
For production environments where automatic wallet opening is desired, create an auto-login wallet:
-- Create standard auto-login wallet
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY 'YourSecurePassword';
-- OR create a local auto-login wallet (recommended for better security)
ADMINISTER KEY MANAGEMENT CREATE LOCAL AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY 'YourSecurePassword';
Step 6: Verify Wallet Status
-- Check wallet status
SELECT * FROM V$ENCRYPTION_WALLET;
3. Major Changes in Oracle AI Database 26ai
Oracle AI Database 26ai introduces several significant changes to TDE wallet management and encryption capabilities. Understanding these changes is crucial for planning upgrades and ensuring security compliance.
Deprecated and Desupported Parameters
ENCRYPTION_WALLET_LOCATION Desupported
• The ENCRYPTION_WALLET_LOCATION parameter is completely desupported in 26ai
• You must use WALLET_ROOT structure (introduced in Oracle Database 18c)
• Critical: If TDE is enabled but WALLET_ROOT is not configured, you will be blocked from upgrading to 26ai
WALLET_LOCATION Deprecated (Server Only)
• WALLET_LOCATION is deprecated for Oracle Database server use
• It remains supported for client and listener configurations
Wallet Management Tool Changes
Oracle Wallet Manager (OWM) Desupported
• The GUI-based Oracle Wallet Manager is no longer available
• Oracle recommends using the orapki command-line tool instead
mkstore Deprecated
• The mkstore utility is deprecated in Oracle 26ai
• Use orapki for wallet and certificate management
• Note: For TDE keystore management, continue using ADMINISTER KEY MANAGEMENT statements
Enhanced Encryption Algorithms and Modes
Default Algorithm Changed to AES256
• Previous default for column encryption: AES192
• Previous default for tablespace encryption: AES128
• New default for both: AES256 (stronger security)
New Encryption Modes
• Column encryption: Now uses Galois/Counter Mode (GCM) instead of Cipher Block Chaining (CBC)
• Tablespace encryption: Now uses tweakable block ciphertext stealing (XTS) instead of Cipher Feedback (CFB)
• XTS provides improved security and better performance, especially with parallel processing
• RMAN integrity checks now use SHA512 instead of SHA1
Deprecated Algorithms
• GOST and SEED algorithms are deprecated
• Decryption libraries remain available for existing data
• New encryption keys cannot use these algorithms
Oracle Data Guard Enhancements
New TABLESPACE_ENCRYPTION Parameter (19.16)
• Controls automatic encryption of tablespaces in primary and standby databases
• Enables hybrid cloud disaster recovery where the cloud database is encrypted, but the on-premises database is not
DB_RECOVERY_AUTO_REKEY Support
• Now available for Oracle Data Guard environments (26ai)
• Controls whether the standby database automatically rekeys tablespaces during recovery
4. TDE Wallet Best Practices
Implementing TDE correctly means following established best practices to ensure both security, operational efficiency and most importantly, database continuity. Here are a few best practices I would recommend to you:
Password Management
• Never store wallet passwords in scripts or configuration files
• Use Secure External Password Store (SEPS) for automated operations
• Maintain a password-protected wallet even when using auto-login
• Document password recovery procedures in your disaster recovery plan
Wallet File Protection
• Set restrictive file permissions (600 or 700) on wallet directories
• Store wallets on encrypted file systems when possible
• Never share wallet files between different CDBs
• Implement regular wallet backups with secure off-site storage
Key Management
• Always use WITH BACKUP clause when rekeying master keys
• Establish a regular key rotation schedule (annually or semi-annually)
• Retain old key backups for long-term data recovery requirements
• Consider Oracle Key Vault for enterprise-wide key management
Production Environment Recommendations
• Use local auto-login wallets for better security in production
• Configure WALLET_ROOT in separate locations for each database
• Test wallet operations in disaster recovery scenarios regularly
• Monitor V$ENCRYPTION_WALLET regularly to ensure wallets remain open
Upgrade Preparation for Oracle 26ai
• Verify WALLET_ROOT is configured before upgrading
• Migrate from ENCRYPTION_WALLET_LOCATION to WALLET_ROOT structure
• Plan to migrate from mkstore to orapki utilities
• Test with new AES256/GCM and XTS encryption modes
• Review and migrate any GOST or SEED-encrypted data before upgrading
Conclusion
TDE wallet management is a foundational component of Oracle Database security, but it also has direct implications for availability, recovery, and operational resilience. As Oracle continues to evolve TDE with Oracle AI Database 26ai, introducing stronger encryption defaults, new modes, and deprecating legacy tools and parameters, organisations must ensure their wallet configurations are aligned with these changes.
The move to the WALLET_ROOT structure, the deprecation of utilities such as Oracle Wallet Manager and mkstore, and the adoption of AES256 with modern encryption modes reflect Oracle’s focus on strengthening database security. However, these changes also raise the importance of disciplined wallet management - including proper configuration, secure management practices, and thorough testing.
Remember that TDE is only as secure as your wallet management practices. Secure backups of your wallet files, careful password policies, the appropriate use of local auto-login wallets in production, and regular testing, including Disaster Recovery testing, are essential to avoid situations where your encrypted databases become unavailable at the moment you need them most. For enterprise environments, Oracle Key Vault can be considered for centralised key management and enhanced security.
By following the practices outlined in this blog, teams can implement and manage TDE wallets in a way that supports both strong security and reliable database continuity, while fully leveraging the enhancements available in Oracle AI Database 26ai.
Subscribe to our monthly blog updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of DBVisit's Privacy Policy
See for yourself how our continuous database protection can help keep your world in motion.
We work with partners around the world to give you the best advice and world-class local support.
Find a local Partner
Enter your details below
With Dbvisit's StandbyMP software, Gold Standard Disaster Recovery doesn't have to be difficult or expensive. Get an instant quote now.