Why Does the TDE Wallet's Tablespace (TS) Encryption Key Look Different Than The Tablespace Master Key In 12c Database Queries? (Doc ID 2489623.1)

 

APPLIES TO:

Advanced Networking Option - Version 12.1.0.2 and later
Information in this document applies to any platform.

SYMPTOMS

A TDE wallet being used by a 12c database, being the original TDE wallet for the database, seems to be "inconsistent" with the TDE metadata stored in the database.

Specifically, the tablespace (TS) encryption key is similar, but not identical.

The wallet looks like the following example:

$ mkstore -wrl . -list

Enter wallet password:
Oracle Secret Store entries:
ORACLE.SECURITY.DB.ENCRYPTION.AYaiJAv4/08hv01lAzyiTUsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ORACLE.SECURITY.DB.ENCRYPTION.MASTERKEY
ORACLE.SECURITY.TS.ENCRYPTION.BTxiCnXBLj2N6bB6HQO3A/ACAwAAAAAAAAAAAAAAAAAAAAAAAAAA

The column keys in ENC$ are in agreement with the value for ORACLE.SECURITY.DB.ENCRYPTION...

+-----------------------------------------------------------+
Master key used to encrypt the columns
+-----------------------------------------------------------+

MKEYID
----------------------------------------------------------------
AYaiJAv4/08hv01lAzyiTUsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AYaiJAv4/08hv01lAzyiTUsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AYaiJAv4/08hv01lAzyiTUsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AYaiJAv4/08hv01lAzyiTUsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AYaiJAv4/08hv01lAzyiTUsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

 ...but the tablespace key shown in database queries is not 100% identical to that seen in the wallet (under ORACLE.SECURITY.TS.ENCRYPTION):

+-----------------------------------------------------------+
Master key associated with the tablespaces
+-----------------------------------------------------------+

NAME MASTERKEYID_BASE64
---------------------------------------- ------------------------------------------------------------
SYSTEM ATxiCnXBLj2N6bB6HQO3A/A=
TEMP ATxiCnXBLj2N6bB6HQO3A/A=

(same for other user-owned encrypted tablespaces)

In this example:

• ORACLE.SECURITY.TS.ENCRYPTION looks like:  BTxiCnXBLj2N6bB6HQO3A/ACAwAAAAAAAAAAAAAAAAAAAAAAAAAA
• Whereas the tablespace master key looks like:  ATxiCnXBLj2N6bB6HQO3A/AAAAAAAAAAAAAAAAAAAAAAAAAAA

What could cause this apparent discrepancy or "mismatch"?

 

CHANGES

The database was originally 11gR1 (11.1), then later upgraded to 11gR2 (11.2), and finally 12c (12.1).  

TDE was originally implemented on 11gR1, and the wallet has not been updated since.

CAUSE

The discrepancy can be attributed to the use of a 11gR1-style wallet with 12c binaries, as a result of neglecting to rekey the database (which also updates the TDE wallet) after each upgrade of the database.  

There are notable differences in TDE keys and wallets between 11gR1 and 11gR2 (let alone 11gR1 and 12c!), and rekeying the database should be considered a post-upgrade step.
 

SOLUTION

After upgrading from 11gR1 to 11gR2, one needs to rekey the database, so the DB will start using the Unified Master Key which was introduced in 11gR2.

The same applies to going from 11gR1 to 12c. 

It is better to have a 12c-style keystore (wallet) -- i.e. one created with 12c binaries -- on 12c databases, and to use ADMINISTER KEY MANAGMEMENT on 12c (instead of the old ALTER SYSTEM command set).

To accomplish this on 12c, one should merge the 11gR1 or 11gR2 wallet into a new 12c keystore (again using 12c binaries; merging is not possible on 11g).

 

The following example is applicable to a RAC environment which is currently using an older 11gR1 TDE wallet:

All Nodes

1)  Ensure environment variables are set correctly in the OS session, and also in srvctl getenv.  

2)  Change directory to the TDE wallet location.

3)  If an auto-login wallet (cwallet.sso) exists, rename it.  This is necessary because without a specific patch, the auto-login wallet will prevent one from manipulating the password-based wallet.  See also:  "TDE Wallet Problem in 12c: Cannot do a Set Key operation when an auto-login wallet is present" (Doc ID 1944507.1)

Node 1 Only

4)  Create a new, empty directory to hold the 12c keystore (temporarily).

5)  Log into sqlplus.

6)  Close the auto-login keystore (wallet):

     ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE;

7)  Verify the wallet status change in V$ and GV$ENCRYPTION_WALLET.  The wallet must no longer be OPEN.

8)  Open the password-based keystore (wallet):

     ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "<current_wallet_password>";

    (Reverify the wallet status as in step 7.)

9)  Create an empty password-based keystore in the directory created in step 4, using the 12c binaries.  Example:

   ADMINISTER KEY MANAGEMENT
     CREATE KEYSTORE '<path_to_new_12c_directory_from_step_4>'
     IDENTIFIED BY <new_keystore_password>;

     Check if the new ewallet.p12 was created in your temporary directory.

10)  Merge the 11g wallet (to which the DB is currently pointing) into the new file you just created.  Example:

     ADMINISTER KEY MANAGEMENT MERGE KEYSTORE '<path_to_11g_wallet>' IDENTIFIED BY <11g_wallet_password>
     INTO EXISTING KEYSTORE '<path_to_new_12c_directory_from_step_4>' IDENTIFIED BY <new_keystore_password>
     WITH BACKUP;

NOTE:  If you get an error or warning here, contact Oracle Support.  Otherwise, continue.

11)  Make sure the files contain the same information:

     $ orapki wallet display -wallet <path_to_11g_wallet>
     $ orapki wallet display -wallet <path_to_new_12c_directory_from_step_4>

If both files contain the same keys, proceed:

12)  Close the old password-based wallet.

       ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY <11g_wallet_password>;

All Nodes

13)  In the database's current TDE wallet directory, rename the old 11g wallet.  Example: mv ewallet.p12 ewallet.p12.11g 

14)  Copy the new 12c keystore file (ewallet.p12) into the current TDE wallet directory.  Since it exists only on Node 1, copy the file to the other nodes as well.

IMPORTANT:  Do NOT create an auto-login keystore yet!

Node 1 Only

15)  Open the new password-based keystore:

       ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY <new_keystore_password>;

16)  Check wallet status using the V$/GV$ views.  If OPEN on both nodes, and the correct wallet directory is shown, rekey the database.  (Do NOT rekey the database if this is not the case!)

       ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY <new_keystore_password> WITH BACKUP;

NOTE:  This will ONLY update the ewallet.p12 file on Node 1, so a few more steps must be taken.

17)  Propagate the updated 12c keystore file to the remaining nodes. 
       (This is a necessary habit to get into, as this step, and those to come next, should be executed every time a rekey is performed.)

18)  Close and reopen the keystore (can be done on any node, but staying on Node 1 is fine).

     ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY <new_keystore_password>;
     ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY <new_keystore_password>;

20)  Check the alert logs to see if everything is OK.

21)  [Optional]  Run orapki on the newly-updated ewallet.p12 to see how the wallet has changed.

22)  [Optional]  Rerun the queries you ran originally to cross-check.

23)  Create an auto-login keystore if desired, using ADMINISTER KEY MANAGEMENT.  This can be done on each node.

24)  Back up the database.

REFERENCES

NOTE:2254960.1 - How to Merge a TDE Wallet From 11gR2 Into a New 12c Database Keystore?
NOTE:1944507.1 - TDE Wallet Problem in 12c: Cannot do a Set Key operation when an auto-login wallet is present