Monday Sep 21, 2015

Presenting at ISACA on October 8th

Hello Everyone!

This is Saikat again, Product Manager, Oracle Database Security team. I will be presenting encryption and key management at ISACA on October 8th. This session will cover encryption and key management challenges, best practices as well as what's offered by Oracle in this space.

Please come and join me at the webinar "Encrypting is the Easy Part; Managing Those Keys is Difficult" to learn about encryption and key management challenges. . Check out the details at ISACA . Feel free to forward this link to other interested parties.

Look forward to seeing you at the upcoming ISACA webinar

Thanks, Saikat

Oracle OpenWorld 2015 Session on Oracle Key Vault

Hello Everyone!

This is Saikat again, Product Manager, Oracle Database Security team. I will be presenting Oracle Key Vault at this year's Oracle OpenWorld on October 29th. This session will cover Oracle Key Vault overview, best practices as well as what's new in Key Vault.

Please come and join me at the session "Managing Advanced Security Database Encryption Keys with Oracle Key Vault [CON8562]" to learn about Oracle Key Vault, the benefits it offers, the pain points it addresses. Session location and timing: October 29, 10:45 am - 11:30 am | Moscone South—254. Also check out other database security sessions database security focus and let me know if you have any feedback. Feel free to forward this link to other interested parties.

Look forward to seeing you at the Oracle OpenWorld this year

Thanks, Saikat

Thursday Mar 05, 2015

Oracle Key Vault Training-On-Demand in Oracle University Available Now!

Hello Everyone!

This is Saikat again, Product Manager, Oracle Database Security team. Oracle University has released a training on demand for Oracle Key Vault. It is available now.

Please check out the training on demand and let me know if you have any feedback. Feel free to forward this link to interested parties.

Look forward to hearing from you,

Thanks, Saikat

Monday Dec 08, 2014

Video of Oracle Key Vault OpenWorld 2014 Presentation

Hello Everyone!

This is Saikat again, Product Manager, Oracle Database Security team. We have recorded a video of my Oracle OpenWorld 2014 Oracle Key Vault presentation. The recording has been recently published from Oracle University. It is available for anyone to watch as part of OU Streams (including non-paying subscribers).

Please check out the recording and let me know if you have any feedback. Feel free to forward this link to interested parties.

Look forward to hearing from you,

Thanks, Saikat

Wednesday Oct 15, 2014

Oracle Key Vault In the News!

Hello again, this is Saikat Saha, product manager for Oracle Key Vault.

As you may be aware, we launched Oracle Key Vault on August 7th. We have received overwhelming response from field so far.

Oracle Key Vault had significant presence at the Oracle OpenWorld 2014 in San Francisco, California. I had a well-attended session Introducing Oracle Key Vault: Centralized Keys, Wallets and Java Keystores. In addition, we ran two hands-on-labs dedicated to Oracle Key Vault where participants were really engaged. And Oracle Key Vault received favorable mentions at various other OpenWorld 2014 events including Andy Mendelson's session and Tom Kyte's session.

Oracle Key Vault was recently covered in a number of news articles:

  1. Oracle issues a virtual strongbox for enterprise encryption keys (PCWorld)
  2. Oracle Introduces Key Vault Software Appliance to Manage and Safeguard Encryption Keys (Database Trends and Applications)
  3. Oracle Key Vault helps customers manage encryption keys (GCN)

Please visit the Oracle Key Vault page on Oracle Technology Network to see further recent updates here.

Happy Reading!

Thursday Aug 07, 2014

Centrally Manage Oracle Database Encryption Master Keys, Oracle Wallets, Java KeyStores and Other Credential Files

Hello, this is Saikat Saha, product manager for Oracle Key Vault here at Oracle Corp. Oracle is excited to introduce Oracle Key Vault, a new centralized solution for managing encryption keys across the enterprise.

Oracle Key Vault supports several common key management scenarios, while at the same time offering unique optimizations for Oracle. It can manage things like symmetric keys, scripted passwords and certificates that are used by encrypted servers including Oracle Databases, Oracle Middleware, and other systems. Because key material often is found in local files such as Java Keystores, Oracle Wallets, and miscellaneous credential files, Oracle Key Vault also provides special support for managing key storage files. And, as we will describe in future blog posts, it can integrate directly with Oracle Advanced Security Transparent Data Encryption (TDE) – a widely used solution for transparently encrypting data-at-rest within Oracle Databases. The Oracle Key Vault appliance itself is based on the industry standard for key management: the OASIS Key Management Interoperability Protocol (KMIP).

To learn more about Oracle Key Vault, please visit the product pages on and Oracle Technology Network

Monday Apr 21, 2014

Centralized Management of TDE Oracle Wallets on a Separate Machine

Note: Below is a re-posting of the February 19th, 2014 article about centrally managing TDE wallets on a separate machine. This post originally appeared on the Oracle Advanced Security blog, and we are moving it here to the key management blog for the convenience of our readers.

* * * * * * * * * * * * * * * *

We have been getting questions about whether it is possible to store the Oracle Wallet used by TDE on a location that is physically separate from the database host machine. Because Oracle Wallets are just files and because the database’s touch of the wallet file is fairly "light-weight", you certainly can store the wallet elsewhere – and there are various approaches for doing this. Note that the Oracle Database accesses to the TDE wallet file infrequently. For normal day-to-day database operations, the wallet typically will be in an open state with the TDE master keys (current and historical) loaded by the database and no direct reads/writes to the underlying file.

I want to point out before getting too deep into the weeds that I view physical separation of the wallet file from the database host machine as optional. Your particular auditor or assessor may disagree with this. My rationale is that you can lock-down access to the wallet file quite tightly when it is on the same machine as the database by leveraging proven and effective file security mechanisms that have been used widely for a number of years. To be specific, you can utilize native operating system and file system permissions to lock down the wallet storage location, and on certain operating systems and file systems, you also can set the "immutable bit", which prevents even the OS root user from accidentally altering/deleting the wallet. Moreover, the standard password-based wallet itself is encrypted using a password derived encryption key according to the PKCS12 and PKCS5 standards, so you get another layer of security by restricting knowledge of the wallet password to a few trusted users. You can even split-up knowledge of the wallet password, dividing it among multiple users. Net net, the Oracle Wallet is always separate from the TDE encrypted data, and it is possible to keep the wallet quite secure when it is stored on the same physical machine as the database.

(The default storage location that I usually recommend for the TDE wallet is a path outside of $ORACLE_BASE on the database host. For example, something like /etc/ORACLE/WALLETS/<$ORACLE_SID> on Linux.)

One other important point here: if you are like most IT organizations, then storage volumes accessible to the database host machine often are located on physically separate hardware already – namely, dedicated SAN and Enterprise NAS storage hardware. When your database host mounts a storage volume provided by SAN/NAS and that volume has a standard file system, then you can easily store the wallet file there, thus achieving the desired physical separation.

If these points are not enough to satisfy your particular auditor or assessor, and they simply are demanding that storage of the TDE master key reside on a specialized key management device or on a secure network directory, then rest assured that you can do this too. I am not going to dwell on specialized key management devices in this blog post (more to come on that topic later), but I would like to describe a few recommendations for storing the wallet on a network directory should you elect to go down this path.

The following slide summarizes storing the wallet on a network directory:

I setup this configuration a few months back in a virtual environment, and it worked great. Here are a couple of recommendations for you based on that experience:

  • To secure the connection to the network directory, I tunneled SMB over a mutually authenticated and encrypted SSH connection using an RSA key pair. To further harden the share, you should close non-essential ports on the file server using software and/or hardware firewall and take other standard security precautions. Note that I used SMB for the share due to the tie-ins with Kerberos, Active Directory and LDAP, but there is no reason you could not employ NFS instead – just make sure to use a recent secure version of NFS and setup an authenticated and encrypted connection.
  • For TDE running on Oracle RAC nodes, I recommend that you setup the subdirectories inside of the network directory as /<$ORACLE_SID OF THE DATABASE>/<HOSTNAME OF THE RAC NODE>. Then, each <HOSTNAME...> subdirectory has an identical copy of the wallet file for the <$ORACLE_SID...> database. Note that you should never attempt to share a single TDE wallet across multiple running Oracle Databases (it is always one wallet per database), and for RAC, you need to have a copy of that wallet accessible to each node (exceptions: you can have per-database wallets that are shared by all RAC nodes if you are using Oracle ACFS or if you are on Oracle Database 12c, which supports wallet storage directly in Oracle ASM).

Remember that if you are storing the TDE wallets on a network directory, then availability of the TDE master key and availability of all your TDE encrypted data will be dependent on availability of the network. In certain environments where the network is not always up, that could be a critical dependency for you to consider, and in other environments it could be a non-issue. Something to keep in mind.

Okay, time to wrap-up…

What you read above was a quick tour of storing TDE wallets on a separate machine. It provided a few insights and recommendations. There certainly are other aspects of this topic and other approaches where I am not getting into great detail, but this material gives you one good centralized wallet management pattern to follow. I hope it helps, and please stay tuned for further posts coming soon.

Thursday Apr 17, 2014

Oracle RAC: Rotating the TDE Master Key and Oracle Wallet Password with a Wallet Copy on Each Node

Here at Oracle, we have received questions regarding TDE Master Key rotation and Oracle Wallet password rotation in RAC environments. In this blog post, I will explain one of several possible ways to achieve this.


On an Oracle RAC cluster running a TDE encrypted database, rotate the master key and the wallet password. Repeat the rotation once or twice per year based on your corporate policy.

This is one of several possible "blueprints" for doing TDE master key and wallet password rotation on Oracle RAC environments. There are certainly other ways to do it depending on your RAC configuration, storage configuration, database versions, etc. The blueprint described below is broadly applicable given the RAC environments that many customers are running now.

Oracle end-user documentation makes additional recommendations for RAC and TDE. Note that alternatives described in the end-user documentation are useful for certain environments.


Let me first describe what a typical RAC+TDE environment would look like.


  • Oracle RAC system running on ASM, with no ACFS installed
  • Databases

  • The database is Oracle Database Enterprise Edition 10gR2, 11g or 11gR2
  • In the example that follows, we will be working with a database named rac-hr, which has a rac-hr1 instance running on node 1 and a rac-hr2 instance running on node 2
  • Encryption

  • The database is encrypted only using TDE (tablespace or column), nothing else
  • TDE is using a standard symmetric key for the TDE master key, not a certificate (legacy)
  • For older database releases 11g and 10gR2, separate column encryption master key and tablespace encryption master key both must be rotated
    -- On 10gR2, only column encryption is available, so only the column encryption master key can be rotated
    -- On 11g, the command to rotate master key will execute successfully on the column encryption master key but will skip rotation for the tablespace encryption master key (note: master key rotation is not supported specifically for tablespace on 11g)
    -- On 11gR2, there is a unified master encryption key that serves both column encryption and tablespace encryption. It will be rotated
  • Configuration Files

  • Each RAC node has local sqlnet.ora files. There is one sqlnet.ora file for each encrypted database running on the node. The directory layout for storage of the sqlnet.ora files is the same on each node
    -- Example: /u01/app/oracle/product/11.2/rac-hr/network/admin/sqlnet.ora
  • Inside of sqlnet.ora for a given database, the ENCRYPTION_WALLET_LOCATION setting points to a storage location for the wallet associated with that database. It is a unique and fully qualified location (path / subdirectory) on the node’s local file system. This setup avoids the danger of multiple databases attempting to share the same wallet file. The directory layout for storage of wallet files is the same on each RAC node
  • You must verify permissions on full directory paths and wallet files themselves to make sure each database can successfully access its wallet
    -- Example: On Linux, create the wallet subdirectory as follows –
    $> cd /etc
    $> mkdir –pv ORACLE/WALLETS/rac-hr
    $> chown –R oracle:oinstall ORACLE
    $> chmod –R 700 ORACLE
  • RAC srvctl commands are used to startup the database. First, you start the database using srvctl start, and then you set the TNS_ADMIN environment variable using srvctl setenv. This informs the database where to look for its sqlnet.ora file across all of the nodes (i.e. recall that the directory layout is the same everywhere)
    -- Example: $> srvctl setenv database –d rac-hr –t TNS_ADMIN=/u01/app/oracle/product/11.2/rac-hr/network/admin
  • Wallet Files

  • Copies of both P12 and SSO are on each RAC node
  • The SSO used is a *local* auto-login wallet
  • TDE Wallets are used only for TDE (no storage of network encryption certificates or SEPS passwords)
  • An additional copy of the current P12 is stored and appropriately tagged/labeled within a separate backup archive
    -- This can be any file archive, however for better security, it should be a separate archive location from backups of the TDE encrypted data. To tag/label the P12 backup, use description fields provided by your backup software or simply change the file name. For example, you could name the P12 file backup "<<description and timestamp>>.p12". If you ever need to restore the P12 file from archive, make sure to change the name back to "ewallet.p12"

    In Oracle RAC environments, TDE operations such as wallet open/close are synchronized automatically across the cluster. However, when you create a new TDE master key and write it into the wallet or you rotate the wallet password, although these operations are executed successfully on the local RAC node (and corresponding changes are written to the local copy of the wallet), they do not fully synchronize across the cluster. The updated wallet must be copied manually from the RAC node where the rotation operations were performed to the other nodes.

    These key and password rotation operations typically are infrequent and often part of larger planned maintenance activities, so the burden of performing additional copy steps is low. But remembering to do the file copy is critical. If the updated wallet is not copied over to other RAC nodes, then when they attempt to service queries on TDE encrypted data, they may fail with errors (cannot unwrap data encryption keys with new master key). Moreover, the next time other nodes attempt to open the wallet using a password (where the wallet has been set to a new password), again they will fail with errors.

    Procedure Characteristics

  • Rotates both the TDE master key and the Oracle Wallet password
  • Rotates on a single database, but the procedure easily can be adapted/repeated to rotate multiple databases running on the cluster
  • Assumes that the cluster is using *local* auto-login wallet for benefits including unattended database startup and additional security
  • Procedure can be done with near-zero downtime for databases that are running on the cluster
  • Procedure can be done with near-zero chance of running queries returning errors during rotation
  • Note that the procedure involves temporarily bringing the cluster down to a single node, which means it should be performed during a time window when the cluster is lightly used (to not overwhelm the single node). Alternatively, you can perform the procedure during a planned/scheduled maintenance window when no queries are going to the cluster at all

    1. STARTING STATE: Encrypted database is running, with a live instance on each node

    2. Backup the current P12 to archive

    3. Identify one RAC node that will be the lead node

    4. Use orapki wallet display -wallet to see master key list and validate the password

    5. Bring all nodes down except for the lead node
  • Bringing down means to stop the database instance (the instance of the TDE encrypted database that requires rotation) running on the node
  • Example: $> srvctl stop instance -d rac-hr -i rac-hr2

  • 6. On the lead node, rotate the TDE master key using sql command
  • This updates the running database and immediately writes a change into the P12 and SSO files
  • Example: sql> alter system set encryption key identified by "password"

  • 7. Use orapki wallet display -wallet to see that a new master key has been added

    8. Backup the P12 to archive

    9. Close the wallet
  • This closes the updated P12, which is left open by the rotation command. Need to make sure the P12 is closed so that the updated SSO can open. After closing P12, when a query comes in, the updated SSO will open automatically
  • Example: sql> alter system set encryption wallet close identified by “password”

  • 10. Run a simple query that touches TDE encrypted data
  • This makes sure that the updated SSO is in an open state (if it is not already open because a query has immediately come to the node that opened it)
  • It also serves as a checkpoint to make sure we are successful up to this point and the node still can query TDE encrypted data fine

  • 11. On the lead node, rotate the wallet password using orapki utility
  • This updates the running database and immediately writes a change into the P12 and SSO files
  • Example: $> orapki wallet change_pwd -wallet /etc/ORACLE/WALLETS/rac-hr

  • 12. Use orapki wallet display -wallet to validate the new password

    13. Backup the P12 to archive

    14. Close the wallet
  • This closes the SSO, which is left open by the previous query on TDE encrypted data. Need to make sure the older wallet is flushed from memory and the newer SSO can open. After closing older SSO, when a query comes in, the newer SSO will be opened automatically
  • Example: sql> alter system set encryption wallet close
  • Do not need the clause identified by “password” because it was an SSO that was open and no password required

  • 15. Run a simple query that touches TDE encrypted data
  • Ensures that updated SSO can be opened, also serves as checkpoint

  • 16. On the other nodes, delete their local copies of P12 and SSO

    17. Copy the updated P12 from the lead node to other nodes

    18. Go to other nodes one-at-a-time
  • Regenerate the *local* auto-login wallet (SSO)
  • Example: orapki wallet create -wallet /etc/ORACLE/WALLETS/rac-hr -auto_login_local
  • Verify permissions for full path and wallet files themselves. Make sure wallet files can be accessed by the database

  • 19. Bring other nodes back up
  • Example: $> srvctl start instance -d rac-hr -i rac-hr2

  • 20. After all nodes are back up, from the lead node, close wallet one last time and run a simple query on TDE encrypted data
  • Ensures that updated SSO can be opened by nodes, also serves as checkpoint

  • 21. ENDING STATE: Encrypted database is running, with a live instance on each node. Master key and wallet password have been rotated

    Hope you find this blog post helpful. Please feel free to leave your comments and suggestions.

    Wednesday Mar 12, 2014

    Welcome to the Key Management for Oracle Blog!

    Hello, my name is Saikat Saha. I am a product manager for Oracle Advanced Security here at Oracle Corp. While my emphasis is on key management for servers in general, I am specifically involved in database security and key management for Oracle Advanced Security Transparent Data Encryption (TDE) including Oracle Wallet.

    I extend a warm welcome to new readers and hope that you will find this blog informative and useful. I will endeavor to post useful information covering key management for Oracle and related topics in this blog. Please feel free to leave your comments. You also can make requests for new blog postings that may be of interest on this topic. I look forward to hearing from you.

    To learn more about Oracle Advanced Security, please read the blog posts at as well.


    Blog covering key management for Oracle.


    « May 2016