Oracle White Paper
Transparent Data Encryption Best Practices  
easy to remember, since a forgotten wallet password cannot be recovered.  One way to come up 
with a strong yet easy to remember password is to take the first characters of each word in an 
easy-to-remember sentence: “I work from 9 to 5 almost every day of the week” would give 
Iwf9t5aedotw
”, which satisfies the common requirements for good passwords: It contains 
numbers as well as upper- and lower case characters, and it is longer than the recommended 
minimum of 10 characters.  The sentence is very easy to remember, but you don’t have to 
remember the complex password itself at all. 
Split knowledge about the Wallet password 
When Enterprise Manager is used, the wallet password is always masked, so it is not only easy to 
hide from the DBA, but can also be split easily between different custodians:  Person A enters 
the first part of the password before Person B enters the 2nd half of the password, without 
Person B being able to see what Person A typed into the password field. 
In Oracle Database 10gR2, where the wallet password on the SQL*Plus command line is 
displayed in the clear, password splitting is not possible.  For customers to translate the need for 
‘split knowledge about the encryption key’ to ‘split knowledge about the Wallet password’, the 
following script provides a possible work-around: 
Create a user ‘
Sentinel
’ in your database with only ‘
create session
’ and ‘
alter system
’ 
privileges 
Create a Secure External Password Store (SEPS), following the instructions in this document
.  As 
explained in this document, create an entry in 
tnsnames.ora
called ‘
keyholder
’; confirm with 
$ tnsping keyholder
’ that the entry is correct.  Add credentials for the user ‘
sentinel
’ to 
the SEPS:  
$ mkstore –wrl . –createCredential keyholder sentinel <password>  
Try to connect to the database with ‘
$ sqlplus /@keyholder
’ 
This script (‘
set_key.sh
’) creates a new wallet in the defined location (if it does not exist) and 
adds a new TDE master encryption key to a wallet, or re-keys the master encryption key: 
#!/bin/bash 
get_pwd1(){read -s –p “1st
half of password: ” pwd1} 
get_pwd2(){read -s –p “2nd
half of password: ” pwd2} 
set_key(){sqlplus /@keyholder @set_key.sql $pwd1$pwd2} 
get_pwd1 
get_pwd2 
set_key 
The SQL script ‘
set_key.sql
’: 
set termout off; 
alter system set encryption key identified by “&1”; 
Pdf hyperlink - insert, remove PDF links in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Free C# example code is offered for users to edit PDF document hyperlink (url), like inserting and deleting
convert excel to pdf with hyperlinks; convert doc to pdf with hyperlinks
Pdf hyperlink - VB.NET PDF url edit library: insert, remove PDF links in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Help to Insert a Hyperlink to Specified PDF Document Page
add link to pdf file; add a link to a pdf in acrobat
Oracle White Paper
Transparent Data Encryption Best Practices  
set termout on; 
exit 
A similar script can be written to open the wallet, or to change the wallet password using the 
orapki
’ command line tool in 11.1.0.7 or later (see next paragraph).
Oracle recommends performing the wallet creation and master key initialization on the database 
server itself.  If you plan to use a remote machine to perform the operation, enable network 
encryption between the client and database server
so that the communication between both 
machines is secure. 
Changing the Wallet Password 
Changing the password is independent from changing the master key.  A pseudo-random 
number generator generates the master key, while the wallet password is used as the key to 
encrypt the wallet.  Prior to Oracle Database release 11.1.0.7, changing the wallet password 
required using Oracle Wallet Manager.  Before changing the password of an existing wallet, be 
sure you have backed up the wallet.  After changing the password, verify that you can open the 
wallet using the new password.  If you can’t open the wallet with the new password, simply 
restore the backup copy of the wallet and try changing the password again.  Starting with Oracle 
Database release 11.1.0.7, the ‘
orapki
’ utility has been enhanced to enable wallet password 
changes from the command line: 
$ orapki wallet change_pwd -wallet <wallet_location> 
Multiple databases on the same host 
If there are multiple Oracle Databases installed on the same server, they must access their own 
individual TDE wallet.  Sharing the same wallet between independent instances is not supported 
and can potentially lead to the loss of encrypted data. 
If the databases share the same 
ORACLE_HOME
, they also share the same 
sqlnet.ora
file in 
$TNS_ADMIN
 In order to access their individual wallet, the 
DIRECTORY
entry for the 
ENCRYPTION_WALLET_LOCATION
needs to point each database to its own wallet location: 
DIRECTORY = /etc/ORACLE/WALLETS/$ORACLE_UNQNAME
The names of the subdirectories under 
/etc/ORACLE/WALLETS/
reflect the 
ORACLE_UNQNAME
names of the individual databases. 
If the databases do not share the same 
ORACLE_HOME
, they will also have their individual 
sqlnet.ora
files that have to point to the individual subdirectories. 
Before changing the password on an existing wallet, be sure you have backed up the existing wallet.  After changing the 
password, verify that you can open the wallet using the new password. 
How to C#: Basic SDK Concept of XDoc.PDF for .NET
XDoc.PDF for .NET allows C# developers to edit hyperlink of PDF document, including editing PDF url links and quick navigation link in bookmark/outline.
clickable links in pdf from word; add a link to a pdf
VB.NET PDF: Basic SDK Concept of XDoc.PDF
XDoc.PDF for .NET allows VB.NET developers to edit hyperlink of PDF document, including editing PDF url links and quick navigation link in bookmark/outline.
add hyperlink pdf document; add hyperlink in pdf
Oracle White Paper
Transparent Data Encryption Best Practices  
10 
TDE Tablespace Encryption 
An Oracle database consists of at least two logical storage units called tablespaces, which 
collectively store all of the database’s data.  Each tablespace in an Oracle database consists of one 
or more files called datafiles, which are physical structures that conform to the operating system 
in which Oracle Database is running.  Nearly all databases have several additional tablespaces to 
store application specific data. 
With Oracle Database 11g, new tablespaces can be defined as encrypted.  Defining a tablespace 
as encrypted means the physical data files created on the operating system will be encrypted.  
Any tables, indexes and other objects defined in the new tablespace will be encrypted by default 
with no additional storage space requirements.  During data reads, the Oracle database will 
automatically decrypt data before it arrives in database memory (SGA).  Data that is moved out 
of the SGA and written to the file system will be encrypted.  TDE tablespace encryption 
provides optimal performance by enabling existing indexes and foreign keys to continue working 
as they were before encryption was turned on.  Execution plans remain the same and the 
requirement to identify individual columns to encrypt is completely eliminated. 
Applications certified for TDE Tablespace Encryption 
The following Oracle applications have been certified with TDE tablespace encryption in Oracle 
Database 11.1.0.7 and Oracle Database 11g Release 2: 
Oracle E-Business Suite (see 
http://blogs.oracle.com/stevenChan/certifications.html
for current updates) 
Oracle PeopleSoft Enterprise 8.48 and later (Migration script and detailed implementation 
guide
Oracle Siebel CRM 8.0 and later 
Oracle JD Edwards EnterpriseOne 
SAP 6.40_EX2 and later (Oracle Database 11g Release 2 only, SAP note 974876) 
RETEK Retail Sales Audit 13.1.5 
Primavera P6 
Internal benchmark tests and customers reported a performance impact of 4 to 8% in end-user 
response time, and an increase of 1 to 5% in CPU usage. 
Moving Your Application Data to Encrypted Tablespaces 
Oracle Database 11g supports encrypting new tablespaces only.  Application data can be 
migrated from existing, un-encrypted tablespaces to new encrypted tablespaces using these steps: 
VB.NET Create PDF from Word Library to convert docx, doc to PDF in
Ability to get word count of PDF pages. Change Word hyperlink to PDF hyperlink and bookmark. Free online Word to PDF converter without email.
pdf link; add url pdf
VB.NET Create PDF from Excel Library to convert xlsx, xls to PDF
Merge all Excel sheets to one PDF file in VB.NET. Change Excel hyperlink to PDF hyperlink and bookmark. Export PDF from Excel with cell border or no border.
pdf email link; adding links to pdf in preview
Oracle White Paper
Transparent Data Encryption Best Practices  
11 
1)
Backup the database using your standard backup procedures 
2)
Export all application tablespaces with Oracle Data Pump Export (‘
expdp
’), optionally 
compressing the dump file for faster processing and reduced storage 
3)
Create encrypted versions of the clear-text tablespaces: 
a.
Using ‘
dbms_metadata.get_ddl
’, extract the original DDL (data definition 
language) used to create the application tablespaces, and spool them to a SQL script 
b.
Append ‘
ENCRYPTION [using '<algorithm>'] DEFAULT 
STORAGE(ENCRYPT)
’ to each ‘
CREATE TABLESPACE
’ command, without changing 
any of the other parameters. If the ‘
CREATE TABLESPACE
’ statement already has a 
STORAGE
’ clause, then update the existing one instead of appending. 
c.
Drop the original unencrypted application tablespaces, either with: 
SQL> drop tablespace <name> including contents and datafiles;
or: 
SQL> drop tablespace <name> including contents keep datafiles;
if you want to use operating system level commands like ‘
sdelete
’ or ‘
shred
’ to 
securely delete the old clear text datafile. 
d.
Create the encrypted tablespaces by running the edited script 
4)
Import all application tablespaces with Oracle Data Pump Import (‘
impdp
’) 
5)
Verify application is working properly 
This procedure requires downtime, which is not always feasible.  To migrate to encrypted 
tablespaces while the application remains fully available, Oracle recommends using Online Table 
Redefinition, a mature high-availability feature of the Oracle Enterprise Edition.  A ready-to-run 
script, complemented with a detailed implementation guide, is available
 The script can be easily 
modified to reflect your own migration needs. 
Tablespace Re-Key Restrictions in Oracle Database 11gR1 
The first ‘
set key
’ or re-key operation in an Oracle Database 11.1.0.7 (regardless if new 
installation or upgrade from an older release, and regardless if an Oracle Wallet with master 
encryption key(s) for TDE column encryption already exists) creates an additional master 
encryption key for TDE tablespace encryption.  The master encryption key for TDE tablespace 
encryption is created in the Oracle Wallet at the location specified in sqlnet.ora.  Oracle Database 
11gR1 does not support the re-key of the TDE tablespace master key.  If it becomes necessary to 
change the master key associated with encrypted tablespaces, a slightly modified version of the 
script mentioned before can be applied to individual or all application tablespaces. Alternativelly, 
use the Data Pump utility to extract the application data from the encrypted tablespaces, create 
VB.NET PDF Library SDK to view, edit, convert, process PDF file
Please click to see details. PDF Hyperlink Edit. RasterEdge PDF SDK for .NET package offers robust APIs for editing PDF document
add links to pdf file; pdf link to specific page
C# PDF Library SDK to view, edit, convert, process PDF file for C#
Please click to see details. C#.NET: Edit PDF Hyperlink. RasterEdge PDF SDK for .NET package offers robust APIs for editing PDF document
add hyperlink to pdf online; add links to pdf in acrobat
Oracle White Paper
Transparent Data Encryption Best Practices  
12 
new encrypted tablespaces, and then import the data into the new encrypted tablespace using 
Oracle Data Pump Import (
impdp
). 
1)
Backup the database using your standard backup procedures. 
2)
Export the application tablespaces with Oracle Data Pump ‘
expdp
’, optionally compressing, 
and encrypting the dump file with a password (do not use the current master key to encrypt 
the dump file). 
3)
Extract the DDL used to build the encrypted tablespaces (using 
dbms_metadata.get_ddl
’) and spool to a SQL file. 
4)
Drop the original encrypted application tablespaces, ‘
including contents and 
datafiles
’. 
5)
Build new encrypted tablespaces using the script created in step 2., which are now encrypted 
with a new tablespace key. 
6)
Import the application tablespaces with Oracle Data Pump ‘
impdp
’. 
7)
Verify the application is working properly. 
TDE Column Encryption 
TDE column encryption transparently encrypts sensitive data written to application table 
columns.  This can be accomplished by marking sensitive columns as ‘encrypted’ in Enterprise 
Manager Database Control, or by appending the ‘
encrypt
’ key word to the SQL DDL 
statement.  Existing data types remain the same so the encryption is completely transparent to 
the existing application.  Each table with one or more encrypted columns has its own table 
encryption key; these are stored in the data dictionary, encrypted with the master key. 
When data is written to an encrypted column, sensitive values are encrypted immediately before 
they are written to disk.  When an authorized user selects data from the database, the data is 
automatically decrypted and presented in clear text.  As with TDE tablespace encryption, TDE 
column encryption protects against direct access to media by privileged operating system users as 
well as lost or misplaced tapes and disk drives. 
To increase performance when encrypted data is processed, each table has its own table key that 
is used for all encrypted columns in that specific table.  These table keys are decrypted with the 
master key prior to processing encrypted data, and stay decrypted for the duration of the 
transaction. 
Oracle Application certified for TDE Column Encryption 
The following Oracle applications have been certified with TDE column encryption in Oracle 
Database 10gR2 and 11g (10.2.0.5, 11.1.0.7 or 11.2.0.2/3 are recommended): 
C# Create PDF from Word Library to convert docx, doc to PDF in C#.
Able to get word count in PDF pages. Change Word hyperlink to PDF hyperlink and bookmark. Free online Word to PDF converter without email.
pdf reader link; add hyperlink pdf file
.NET PDF SDK - Description of All PDF Processing Control Feastures
Add signature image to PDF file. PDF Hyperlink Edit. Support adding outline; More about PDF Hyperlink Edit ▶. PDF Metadata Edit. Support
adding a link to a pdf in preview; add links in pdf
Oracle White Paper
Transparent Data Encryption Best Practices  
13 
Oracle E-Business Suite 
(see 
http://blogs.oracle.com/stevenChan/certifications.html
for current 
updates) 
Oracle PeopleSoft Enterprise 8.46 and later 
Oracle Siebel CRM 7.7+ 
Oracle Financial Services (iFlex): FlexCube 10.0 
Oracle Retail Applications (Retek): Retail Sales Audit (ReSA): 
o
ReSA 12.0 and 13.0 (in Oracle Database 10gR2 10.2.0.4+) 
o
ReSA 13.1 (in Oracle Database 11gR1 11.1.0.7) 
Oracle Internet Directory 10.1.4.2 
SAP 6.40 and later (SAP note 974876) 
Identifying Sensitive Columns 
Identifying tables and columns that contain sensitive data such as social security numbers and 
credit cards can be difficult, especially in large applications.  One technique that can be useful is 
to search the Oracle data dictionary for column names and data types that are frequently used to 
store such information.  Here’s an example of using SQL to identify columns that might contain 
social security numbers: 
SQL> select column_name, table_name, data_type from user_tab_cols where 
column_name like '%SSN%' or  
column_name like '%SECNUM%' or  
column_name like '%SOCIAL%'; 
The user executing this statement is the primary user or schema that owns the application tables.  
This technique can be used for other types of information as well by simply substituting another 
string such as “PIN” in the SQL text. 
Encrypting indexed columns 
An indexed column can be encrypted if the column is used for equality searches and the index 
type is a B-tree index (normal, not DESCending).  An index over one or more encrypted 
columns can be built only when these columns are encrypted using the ‘
no salt
’ syntax.  If 
encrypted columns are used to build an index, the corresponding columns in the index are 
encrypted as well.  Before the SQL statement is processed, the value in the SQL text that targets 
the encrypted column is encrypted with the table key of the target table; the database checks the 
index, matches the encrypted value, finds the rowid in the index, and presents the corresponding 
row from the base table.  Following this procedure, the performance impact for equality searches 
Oracle White Paper
Transparent Data Encryption Best Practices  
14 
can be substantially minimized.  Note that range scans (‘between’ clauses) cannot use the 
encrypted index.  However, personally identifiable information (PII) is rarely used in range scan 
operations.  The encryption algorithm (default AES192) is defined per table, even if the 
statement can be given at any column definition in the ‘
create table
’ statement. 
Reducing the storage overhead 
TDE column encryption differs from TDE tablespace encryption in the area of storage 
requirements; after encryption, an encrypted value can be between 1 and 52 bytes longer than the 
clear text value.  By default, TDE column encryption adds ‘
salt
’ and an integrity check 
(Message Authentication Code, MAC) to each encrypted value.  Here we explore when you can 
forgo those security features to save storage overhead. 
Basic encryption is deterministic, which means that a given plaintext will always encrypt to the 
same cipher text.  This property is less secure when the uniqueness of the values in a column is 
not given.  For example, when a column contains sensitive patient information about a rare 
medical condition, most patients would enter ‘No’, while only a few would enter ‘Yes’.  All of the 
cipher texts for ‘Yes’ would be identical, as would be those for the negative answers.  Even 
though their responses are encrypted, people that suffer from that rare condition would be easy 
to identify.  To get beyond this limitation, each clear text value is modified with ‘
salt
’, a random 
16-byte string.  The resulting output using identical plaintext inputs generates completely 
different cipher texts.  However, if you can guarantee that all values in a column are unique (for 
example when a ‘
UNIQUE INDEX
’ has been applied to the column), you can set the ‘
NO SALT
’ 
parameter when encrypting a column to reduce storage by 16 bytes for each cell.  Salt is defined 
per column; one table can contain columns that are encrypted with or without salt at the same 
time. 
For further protection, a 20-byte integrity check is appended to each encrypted value to provide 
tamper detection for the cipher text.  Starting with Oracle Databases 10.2.0.4 and 11.1.0.7, the 
NOMAC
’ parameter can be used with TDE column encryption to omit the generation and storage 
of these additional 20 bytes.  ‘
NOMAC
’ is defined on a table level; even though ‘
NOMAC
’ can be 
specified on one or more columns, it applies to all encrypted columns in a table. 
The final type of storage overhead associated with column-level encryption is unavoidable.  Each 
plaintext value is padded out to the next 16 byte if encrypted using AES; it’s padded out to the 
next 8 byte when encrypted using 3DES168:  If a clear text value requires 9 byte of storage, it is 
expanded to 16 bytes; if the clear text value requires 16 byte, it is expanded to 32 bytes (24 for 
3DES168), and so on. 
It is highly recommended to install patch 8421211
for TDE column encryption in 11.1.0.7 to 
greatly improve performance for a certain type of queries and to correct the behavior of TDE 
column encryption when applied to a column which is part of a composite index, where other 
Oracle White Paper
Transparent Data Encryption Best Practices  
15 
columns than the encryption candidate are used for functional indexes.  Please contact Oracle 
Support if a patch is not available for your version/platform combination. 
Encrypting Columns in Gigabyte and Terabyte Tables 
Sometimes, tables have so many rows and the application downtime window is so small, that the 
UPDATE
’ operation necessary to encrypt one or more columns would take too long, even though 
READ
’ access to the table is still possible while it’s being updated. 
Often, these tables that are the foundation of your business, containing Personally Identifiable 
Information (PII) that needs to be protected through encryption, but they are constantly 
updated, and cannot be taken down without interrupting your business. 
For those tables, Oracle provides Online Table Redefinition, offering a transparent method to 
change table characteristics while the source table is fully available.  For detailed steps, consult 
the documentation, but here is a short form: 
1)
Create an interim table that has the desired characteristics you want the source table to have 
after the procedure, for example: One column is encrypted, while all other columns remain 
unchanged. 
2)
Start the redefinition process while the source table is fully available. 
3)
After the final step (where the source table is offline for a short moment; transparent to 
users and applications, with no data loss!), delete the interim table. 
Disabling and re-enabling Transparent Data Encryption 
Usually, when a wallet is deleted, whether or not data has been encrypted, and a new wallet and 
master encryption key are to be created, the error message ‘
ORA-28374: typed master key 
not found in wallet
’ is displayed. 
The following procedure cannot be used to recover or replace a lost wallet, wallet password, or 
TDE master encryption key; it’s provided for administrators who at one point in time created a 
wallet with TDE master encryption key, never encrypted data, and decided to not use TDE and 
deleted the wallet, and then decided to eventually use TDE. 
After installing patch 8682102
, perform log switches to cycle through all redo logs, and then 
create a new wallet and TDE master encryption keys. 
TDE Tablespace Encryption or TDE Column Encryption? 
In Oracle Database 11gR1, security administrators or DBAs can choose between TDE 
tablespace encryption and TDE column encryption; here are some guidelines: 
TDE TABLESPACE ENCRYPTION OR TDE COLUMN ENCRYPTION? 
Oracle White Paper
Transparent Data Encryption Best Practices  
16 
CHOOSE TDE COLUMN EN
CRYPTION IF …:
CHOOSE TDE TABLESPAC
E ENCRYPTION IF …:
Location of sensitive information is known 
Location of sensitive information is unknown 
Less than 5% of all application columns are encryption 
candidates. 
Most of the application data is deemed sensitive, or 
multiple national and international security and privacy 
mandates apply to your industry 
Data type and length is supported by TDE column encryption 
Not all data types that hold sensitive information are 
supported by TDE column encryption 
Encryption candidates are not foreign-key columns 
Encryption candidates are foreign key columns 
Indexes over encryption candidates are normal B-tree indexes  Indexes of encryption candidates are functional indexes 
Application does not perform range scans over encrypted data  Application searches for ranges of sensitive data 
Increase in storage by 1 to 52 bytes per encrypted value 
No storage increase acceptable 
Performance impact depends on percentage of encrypted 
columns; how often the encrypted values are selected or 
updated, the size of encrypted data, and other variables. 
Constant performance impact below 10% 
If you want to benefit from hardware crypto acceleration 
If you want to enjoy the benefits of encryption and 
compression at the same time. 
Clear-Text Copies of Encrypted Data 
During the lifetime of a table, data may become fragmented, re-arranged, sorted, copied and 
moved within the tablespace; this leaves ‘ghost copies’ of your data within the database file.  
When encrypting an existing column, only the most recent ‘valid’ copy is encrypted, leaving 
behind older clear-text versions in ghost copies.  If the data file holding the tablespace is directly 
accessed, bypassing the access controls of the database (for example with an hex - editor), old 
clear text values might be visible for some time, until those blocks are overwritten by the 
database.  To minimize this risk, please follow these recommendations:  
1)
Backup the database using your standard backup procedures. 
2)
Create a new tablespace in a new data file (
CREATE TABLESPACE 
...  ) 
3)
Encrypt sensitive data in the original tables (
ALTER TABLE ...  ENCRYPT
4)
Move all tables (with or without encrypted columns) from the original tablespace into the 
new data file (
ALTER TABLE ...  MOVE ...  
5)
Verify the application is working properly. 
Oracle White Paper
Transparent Data Encryption Best Practices  
17 
6)
Drop the original tablespace (
DROP TABLESPACE
).  Do not use the ‘
and datafiles
’ 
parameter; Oracle recommends to use stronger methods for OS – level operations. 
7)
Use ‘
shred
’ or other commands for your platform to delete the old data file on the OS 
level. 
The last step is recommended to lower the probability of being able to find ghost copies of the 
database file, generated by either the operating system, or storage firmware. 
Attestation 
In order to present proof of encryption, for example upon an auditor’s request, Oracle provides 
views that document the encryption status of your database.  For TDE column encryption, 
please use the view ‘
dba_encrypted_columns
’, which lists the owner, table name, column 
name, encryption algorithm, and salt, for all encrypted columns.  For TDE tablespace 
encryption, the following SQL statement lists all encrypted tablespaces with their encryption 
algorithm and corresponding, encrypted, data files: 
SQL> SELECT t.name “TSName”, e.encryptionalg “Algorithm”, d.file_name 
“File Name” FROM 
v$tablespace t, v$encrypted_tablespaces e, dba_data_files d WHERE 
t.ts# = e.ts# and t.name = d.tablespace_name; 
The next SQL statement lists the table owner, tables within encrypted tablespaces, and the 
encryption algorithm: 
SQL> SELECT a.owner “Owner”, a.table_name “Table Name”, e.encryptionalg 
“Algorithm”, FROM 
dba_tables a, v$encrypted_tablespaces e WHERE 
a.tablespace_name in (select t.name from v$tablespace t, 
v$encrypted_tablespaces e where t.ts# = e.ts#); 
Oracle Data Guard 
Physical Standby 
Oracle Data Guard Physical Standby works with Transparent Data Encryption beginning with 
the first release of Oracle Database 10g Release 2.  The encrypted application data stays 
encrypted while redo log files are transferred from the primary to the secondary databases.  
However, the master key from the primary database needs to be present on the secondary site 
only when the secondary site is in READ ONLY mode or after a failover, but not for applying 
the redo logs.  It is recommended to copy the primary wallet over to the secondary sites, so that 
in a case of a failover, all data is quickly available.  In addition, the Oracle Wallet can optionally 
Documents you may be interested
Documents you may be interested